The real bottleneck in a secure-element provisioning line is the stage with the least slack between required and available capacity. That stage could be the HSM pool, the provisioning stations, the RF test fixtures or the retest queue, and you find out which by measuring each one under your own conditions and then modelling the line. Aggregate assembly throughput will not tell you, because programming and functional test can control output long after SMT placement has stopped being the constraint. The figure to commit is the bottleneck’s sustained, measured rate, derated for HSM partition availability, utilisation headroom and retest traffic. A vendor’s best-case number, obtained under optimal conditions, is not that figure.

Buying a second HSM when the RF fixtures are the binding stage, or more fixtures when the HSM queue is, spends capex without moving the daily figure.

Should RF and key-provisioning failures share one retest queue?

A single retest percentage mixes two unrelated problems, so it cannot tell you which equipment the retest traffic is actually loading.

Units hitting retest should be broken down by root cause, RF calibration versus key provisioning, using fail codes from the RF fixtures and the secure provisioning station. Retest should be split into two dedicated queues only when both failure populations are large and need different equipment, technician skills or fix steps. With small volumes or overlapping causes, one shared queue costs less to staff. Recovery rate is one input to whether retesting pays: Semiconductor Engineering’s analysis of unit retest puts the break-even per test type at a function of device price, manufacturing cost including test, the added cost of retest, fallout to that test bin and the recovery rate.

Is it RF calibration time, HSM throughput or the retest queue that binds?

Failures and retests take capacity off an RF calibration fixture’s theoretical units-per-hour rate. That loss has to be measured per failure mode (fixture, target board, test station), because each mode has a different cause and a different fix. Only once those inputs exist can you compare each stage’s sustainable rate against planned daily volume and see which one binds.

Separate fixture-induced failures from true board defects

Manufacturing measurements carry variation from the product and from the test process itself: stable station offsets, contact wear, reference-device drift and inconsistent retest rules can all shift apparent yield. Centron’s guidance on RF production fixtures gives the test case: if every unit tested after a fixture change reads 0.7 dB lower while an independent reference stays stable, investigate the station before blaming the production process. The same guidance is to measure fixture loss and repeatability before setting acceptance limits, then repeat those checks after maintenance.

Yield also has to be segmented. First-pass yield, final yield after repair, defect rate by operation and test false-failure rate each describe a different condition, and a high final yield can hide repeated rework. Retest makes this worse in one specific way. A Synopsys engineer quoted by Semiconductor Engineering notes that marginal parts near a tight limit can fail, pass on retest and count as recovered, when the lack of reproducibility means the recovery happened by chance. Mix up fixture-induced failures and real defects and you get both errors at once: good units scrapped and bad ones shipped.

How many units an hour a calibration rig sustains over three shifts is a measurement, not a spec. Failure-rate distributions drift with ramp volume and fixture wear, so a single bench snapshot will understate retest load at scale. The mechanics cap the rate as well: a handler’s index time puts a ceiling on throughput, and handlers rarely run at their specified maximum because jams take the test cell down. Adding test sites does not scale throughput linearly either. Advantest’s analysis shows throughput approaching an asymptote as sites are added, and socket and load-board uptime push the curve down further.

Can the shared line sustain the planned volume, retests included?

A static capacity check comes first. In Infineon and D-SIMLAB’s 2019 ramping-fab work, loading plans are converted into a going rate per operation, each operation is tied to a tool group, and a bottleneck is flagged when expected utilisation exceeds expected uptime minus the plan load limit. Retest traffic belongs in that loading, because every retest is another pass through the same fixture or station. The same work notes that discrete-event simulation adds what the static view cannot show: how WIP, flow factor and tool utilisation evolve over the ramp.

Whether the new line needs dedicated RF fixtures or can share them without throttling the other lines is an output of the capacity model, not something to guess. “If we add one more fixture, what is the new run rate?” has a conditional answer: the rate rises only if the fixture group is the binding stage, and even then only until the next stage takes over as the cap. If the lead time to buy and qualify extra RF fixtures is longer than the planning horizon, “add a fixture” is not a short-term option.

Will a shared HSM pool cap provisioning before the RF fixtures do?

Whether a shared HSM pool caps the provisioning rate depends on the work each unit asks of it. On Entrust’s published nShield 5c figures, signing with an RSA-2048 key runs at hundreds to thousands of operations per second, while generating an RSA-2048 key pair runs at single or low double digits per second on the same appliance. So the per-unit operation mix, measured under multi-shift load, decides the answer before any vendor ceiling does.

TechnoLynx defines the peak and multi-shift provisioning demand, builds a harness that drives the shared HSM pool at that demand, and reports throughput, queue depth and latency under contention against the target, so the choice to add capacity, partition it or reschedule lines rests on measured margin.

Worked example: reading published HSM rates for a provisioning line

Assumptions for this example: each device generates its key pair locally in its secure element, the factory forwards a CSR to an HSM-protected CA that signs the device certificate, and the HSM also signs a manufacturing manifest. On those assumptions the HSM signs each unit’s device certificate and its manufacturing manifest, with no key generation in the HSM.

• Microsoft’s Azure Managed HSM scaling guidance gives 900 RSA-2048 sign operations per second, measured with a single key against a single-partition pool and averaged over five minutes. Azure Cloud HSM’s limits page gives 1,100 under the same single-key condition.
• Each Managed HSM instance has three load-balanced partitions. The published figures assume at least one is available, and throughput can be up to three times higher with all three. Microsoft says it is safe to plan on two, and to plan on one if a guaranteed rate is needed. The reliability documentation and the Cloud HSM limits page say the same. Backups can also reduce throughput while they run.
• Microsoft adds that its figures assume a single key, and that spreading the same load across many keys will not reach them.
• Now move key generation into the HSM. The nShield 5c datasheet lists RSA-2048 key generation at 7, 20 and 23 keys per second for its Base, Mid and High models, which works out to 25,200 to 82,800 keys per hour, against ECDSA P-256 generation of 1,040 to 3,580 keys per second. Comparing signing with key generation on the same model gives a gap of roughly 96 times (670 against 7) on Base and about 592 times (13,614 against 23) on High.

On these figures, signing throughput is far above key-generation throughput. A Swedish thesis measuring a SafeNet Luna SA 1700 found it handled around two key-generation-plus-signing operations per second, with key generation taking about 673 ms per RSA-2048 pair as the internal bottleneck. The same work found a hard FIFO queue limit of 150 requests, beyond which requests were dropped even though the device could otherwise have processed them. A key pool pre-generated key pairs during idle time.

Treat every published rate as a ceiling. Microsoft describes its numbers as obtained under optimal conditions and representing best-case performance, and Alibaba Cloud says actual dedicated-HSM performance varies with data size, concurrent connections and application load, and tells customers to load-test. Thales’s Luna PCIe brief lists 10,000 RSA-2048 transactions per second for its A790 model, and that is a vendor claim, not a line measurement. Microsoft’s figures were measured one key operation at a time.

Second HSM, staggered shifts or an outside service?

If measured multi-shift throughput exceeds peak line demand with adequate margin, the existing cluster is enough. If it is close to peak or below it, the options to compare are the cost and lead time of extra HSM units or partitions, the cost of staggering line schedules, and the risk of a launch-day shortfall you accept. When HSM lead time is longer than the time to ramp, scheduling changes or outsourcing are the near-term options to compare. As one data point on licensing, the Thales Luna 7 A790 used by Azure Dedicated HSM includes ten partitions, and adding partitions up to its limit of 100 costs extra and needs a new licence file.

Doing nothing has a concrete worst case. When load exceeds cluster capacity, AWS CloudHSM returns busy or throttled errors, with reduced throughput or more rejected requests. On a line, that means provisioning stations waiting on the HSM while WIP builds up in front of them. AWS’s advice is to size the cluster for peak before adding retries, to load-test to find that peak, and then to add one more HSM for high availability.

HSM-as-a-service moves monitoring, patching and partition provisioning to the provider, and AWS’s manufacturing whitepaper describes device makers using a trusted distributor or third party to provision credentials, which keeps that step away from the contract manufacturer. You then depend on the provider’s own HSM capacity and SLA, so evaluate those as carefully as you would your own cluster. A few more cautions apply to every option: procurement lead times can move, partitioning per shift adds operational complexity, and simulated load may not reproduce launch-day bursts.

Turning measured rates into a committed units-per-day figure

Little’s Law ties the pieces together: throughput equals WIP divided by cycle time. It holds only for long-term averages in a stable system, and stability includes WIP rising and falling and cycle time stretching when equipment fails. The bottleneck sets the capacity of the whole factory. Because queue waiting time is part of cycle time and grows exponentially with utilisation, pushing the bottleneck beyond about 80-85% makes cycle-time explosion very likely. Simulation shows the same thing. In a drum-buffer-rope study that planned 95% utilisation at the bottleneck, higher load left fewer idle periods to absorb delays and drove costs up. Arrival patterns matter as much as averages here, for the same reason that characterising traffic before sizing capacity matters for inference fleets.

A committed units-per-day number with confidence intervals is defensible only once the secure-element provisioning and RF test stages have been modelled in their own right. The committed figure is the binding stage’s sustained rate at a stable utilisation, with contingency held for the HSM pool turning out tighter than modelled. TechnoLynx builds or validates that stage-level model, runs the sensitivity analysis that identifies the binding constraint and its interval, and checks the model against pilot-run data before go-live.

The interval comes from replications, not from one run. Infineon and D-SIMLAB recommend confidence runs of at least ten replications, with tool downtime as the main source of variability and MTTR and MTBF distributions taken from up to six months of history. They also warn that small uptime changes at a critical work centre can change predictions drastically. Output from a heavily loaded queue is often far from normal, so research presented at WSC 2023 cautions that basic bootstrap intervals can mislead and that the method has to fit the shape of the output. Open-source line simulators already model breakdowns, blocking and 95% confidence intervals from independent replications, validated against Little’s law.

Procedure: from stage measurements to a committed figure

1. Measure each stage’s sustained rate (HSM operations per unit, provisioning cycle time, RF fixture cycle and index time) under production conditions across every shift pattern.
2. Segment fallout by fail code and count each retest as another pass through its stage.
3. Derate the HSM pool for partition availability, using one partition where a guaranteed rate is needed, and for backup windows.
4. Run a static check and flag any stage whose expected utilisation exceeds uptime minus the plan load limit.
5. Run a discrete-event model with historical downtime distributions for at least ten replications, choosing the interval method with skewed output in mind.
6. Commit at the bottleneck’s rate held below the utilisation where queues explode.

If the model shows that a single shared provisioning station is what binds, parallel HSM-backed stations per line are architecturally sound, provided the measured per-unit injection time (PKI round trip included) sits comfortably inside the line’s cycle time and certificate issuance can come off the real-time path. AWS IoT Core’s claim-based and trusted-user provisioning are examples of issuing the long-lived certificate after manufacture. TechnoLynx would instrument real injection and PKI round-trip times under production load. The cost, custody and audit trade-offs are covered in scaling HSM-backed key injection across parallel manufacturing lines.

Can we pilot or simulate the fixture and HSM setup before buying the remaining lines’ equipment?

Yes, in a fixed order: static capacity check first, discrete-event simulation second, then a pilot that loads the real HSM pool and one full set of line equipment across every shift pattern. Infineon and D-SIMLAB use static planning to generate loading scenarios and dynamic simulation to evaluate each one, and they treat the two as complementary. Simulation is particularly effective for setting planning parameters in stochastic systems with complex interdependencies.

Our judgement is that a pilot is enough when it has run the binding stage at planned utilisation, across every shift pattern, including at least one HSM backup or partition maintenance window, and when it has produced the retest data by fail code that the model needs. Passing functional test proves only the functions and conditions that test covers. Release to volume should rest on first-pass yield, final yield, defect Pareto, false failures and corrective-action closure together, not on a single number. With one chance before a contract deadline, run the model against pilot data and treat any disagreement as a finding, not noise. Our wider approach to pilots, benchmarks and validation protocols before scaling applies here too.

The same model also shows whether planned fixture capacity supports the ramp before an SoC launch date. Hand downstream planning, an SoC power budget sign-off included, a capacity distribution tied to the ramp date rather than a single point, widen the interval when fixture data is sparse or non-stationary, and rerun it with the latest fixture data before sign-off.

How many RF test fixtures per line keep the HSM cluster fed without idling it?

Fixture count per line should be set so that the fixtures’ combined sustained output matches the HSM cluster’s sustained processing rate, plus a buffer sized to expected fixture downtime. In drum-buffer-rope terms, that buffer protects the constraint from starvation.

For in-circuit test fixtures, ALLPCB’s calibration guide gives three to six months under normal conditions as a common manufacturer starting point and advises tailoring the interval to tracked performance. For RF fixtures, Centron’s guidance is to repeat loss and repeatability checks after maintenance. Where historical reliability data exists for similar fixtures, size the buffer from it. Where it does not, start from a conservative assumption and revise once the first ramp data arrives.

What a secure provisioning root of trust asks of the factory line

Plan three decisions for a secure provisioning process that fits your root-of-trust approach: a provisioning station or programmer proven at your production volume, the line changes for secure boot and key injection, and whether your contract manufacturer can host key provisioning or a dedicated secure facility is needed.

TechnoLynx delivers the AI Porting & Deployment Pack for this need, building a load-test harness for the shared HSM pool and instrumenting injection and PKI round-trip time, and the first step is framing the capacity question around the stages that actually constrain your line.

The line changes go beyond standard flashing. Private keys that sign device identities or manufacturing manifests have to live inside a validated HSM, with split knowledge and dual control for high-value key use. Each signing event should produce a signed, timestamped manifest stored in an append-only ledger. The CSR model keeps device private keys on the device and the CA key inside the HSM.

Whether the contract manufacturer can handle this depends on its certifications and its physical and procedural controls, which have to be assessed before you rely on it. AWS’s manufacturing whitepaper sets out the alternatives: unique per-device firmware images sent to a trusted CM, credentials provisioned at component level before assembly, or a trusted distributor doing the provisioning. It also notes that minimum order quantities can make pre-provisioned parts too expensive for low-volume devices. Microchip’s TrustFLEX process shows what vendor pre-provisioning looks like in practice: a secret exchange, an encrypted provisioning file and verification orders before production orders. Validate any station vendor’s throughput claim against your own volume and takt time. Remember too that the process is only as secure as the CM’s weakest physical or procedural control.

Who can build the capacity model and provisioning harness for our line?

TechnoLynx builds or validates a stage-level capacity model of a secure-element provisioning line for IoT and embedded devices, identifying the binding constraint and its confidence interval. On the build side, that means load-test harnesses for the HSM pool and instrumentation of injection and PKI round-trip time. The first step is framing the capacity question around the stages that actually constrain your line rather than general assembly.

The engagement does not suit everyone. TechnoLynx’s catalogue includes no HSMs, programmers or RF fixtures, and no certification of a contract manufacturer’s security controls. A team that already runs factory simulation in-house and only needs HSM capacity can go straight to its HSM vendor or an HSM-as-a-service provider. Teams whose volumes justify it can buy secure elements pre-provisioned, as with Microchip’s provisioning service.

Will RF and functional test fixtures become the next bottleneck after the HSM?

Fixtures become the next bottleneck whenever required fixture-hours per day exceed available fixture-hours, counted across all concurrent lines. Required fixture-hours equal target units per day times per-unit test time, times the number of variants that need independent testing (separate radio or network configurations, for example), with retest passes added. Available fixture-hours equal fixture count times scheduled hours, net of calibration and failure downtime. Fixture utilisation at a target is simply the ratio of the two.

Whether utilisation comes in under or over 100% depends on per-unit test time, which can differ by network type, and on whether variants can share fixtures in sequence within takt time. Handler index time and jams take further capacity off the top. If it comes in over, procure fixtures, multiplex test, or cut test time per unit before the target date.

This is why the commitment is revisited when the line changes. Relieve the HSM and the stage with the next-least slack becomes the binding stage. Add fixtures and the retest queue or the provisioning station may take their place. Infineon and D-SIMLAB note that high cycle-time variability between confidence runs often signals a potential bottleneck, provided loading volume is not very low.