Your Root of Trust Is Only as Honest as the Factory That Installed It.

Pick any security property an embedded device claims — secure boot, encrypted storage, authenticated updates, a unique identity on a network — and follow it back to its source. It bottoms out, every time, in a secret placed into the device before it ever reached a customer: a key, a fuse value, a certificate. The device did not negotiate that secret with anyone. It was given it, once, at manufacture. Provisioning is the moment trust is created, and like most moments of creation it is both decisive and badly observed.

The uncomfortable part is where that moment happens. For most products it is not in a facility the vendor owns, staffs, or watches end to end. It is at a contract manufacturer, frequently on another continent, running a line the vendor sees through a narrow window of reports and occasional audits. The root of trust — the thing every later security property leans on — is installed in an environment the vendor does not fully control. A review that takes device security seriously has to begin there, because nothing built afterward is stronger than what was placed at that step.

Provisioning is where trust is born

Provisioning is the act of giving a blank device its identity: writing or generating keys, burning the fuses that fix its lifecycle state, loading initial firmware and the certificates that let it prove who it is. Everything downstream is a consequence of how well this is done. A device-unique key enables per-device attestation and encryption; a key shared across a product line, or a fuse left unburned, silently removes those properties while the device continues to behave normally in every visible way.

What makes provisioning unlike almost every other engineering step is that it is largely irreversible. Fuses are one-way. You cannot recall fielded silicon to provision it again. The decisions executed in the few seconds a unit spends at the provisioning station are decisions the device carries for its entire service life — a decade or more, for a lot of industrial and infrastructure hardware. Getting them wrong is not a bug you patch; it is a property the fleet simply lacks, forever.

The factory is usually untrusted

The correct default posture toward the provisioning environment is that it could be hostile. This is not an accusation against any particular manufacturer; it is a statement about what you can prove. The contract manufacturer has physical access to the device in its most vulnerable state — blank, unlocked, fully open — sees the provisioning data pass through its tooling, and operates the equipment that performs the personalization.

A compromised or malicious actor on that line is in a position to copy keys as they are injected, record the identities of the units built, run extra devices the vendor never ordered, leave debug interfaces open, or substitute keys of their own. You cannot audit your way to certainty about a process running continuously in a building you visit occasionally. So you design as though the provisioning environment might betray the device, because the alternative is to bet the entire root of trust on an assumption you have no way to verify.

Injecting versus generating keys on-device

There are two ways a device gets its private key, and the difference between them decides how many parties could ever leak it. In the injection model, keys are generated outside the device — in an HSM — and written into it on the line. In the on-device generation model, the device generates its own key pair internally, and the private half never exists anywhere outside the chip; the device exports only a public key or a certificate-signing request to be certified.

On-device generation is the stronger model wherever the silicon supports it, for a simple reason: a private key that never left the chip has no pre-device existence to steal, no copy sitting in a provisioning database, and no moment on the factory line where it is visible. Injection is sometimes unavoidable — symmetric secrets, or parts without a trustworthy internal generator — and then the whole problem becomes custody. The secret is born in an HSM, delivered to the line encrypted, injected by tooling that retains nothing, and its plaintext never touches a factory disk. The goal in both cases is the same: shrink the set of people and places that ever hold the secret down toward the device itself.

A private key the factory never saw cannot be leaked by the factory. Wherever the silicon can generate its own, that is not an optimisation — it removes an entire party from the list of those who could betray the device.

Lifecycle states and the point of no return

Secure microcontrollers and SoCs implement a lifecycle state machine held in one-time-programmable memory: blank, then provisioned, then secured — debug closed, test access disabled, keys made non-extractable — and often a terminal or return state at end of life. These states are enforced by hardware, and the transitions between them are deliberately one-way.

The critical transition is the one into the secured state. Before it, the device is soft: open to debug, open to readout, personalizable. After it, the device is hard, and there is no path back. The failure that recurs across real products is devices leaving the line not fully secured — the locking transition skipped to save a step, deferred "to firmware" and then never reliably applied, or simply never verified on the actual units. A device that shipped provisioned-but-not-secured carries its guard down for its entire life, and nothing about its normal operation will ever reveal the omission. It has to be caught at the station, because it cannot be caught later.

Overproduction and cloned identities

A factory able to build the units you ordered is able to build more of them. Overproduction — the proverbial third shift — yields authentic-looking devices the vendor never commissioned: same firmware, same keys, same certificates, the same ability to pass whatever checks a genuine unit passes, but entirely outside the vendor's accounting. Closely related is cloning, where secrets recorded during provisioning are used to personalize gray-market hardware.

Whether these attacks work depends almost entirely on one earlier decision. If identity is per-device and registered in a backend the vendor controls, overbuilt and cloned units surface as unknown or duplicate identities that services can refuse. If identity is shared across the product line, or tracked nowhere, then an overbuilt unit is genuinely indistinguishable from a sanctioned one, and the vendor has no basis on which to tell them apart. Legitimacy has to be something the backend affirmatively knows, not something the device merely asserts about itself.

A defensible provisioning flow

The thread running through all of this is verification per unit. It is not enough that the line was configured correctly; you need to be able to prove, for an individual device, that it received its unique identity, had its fuses set, and had its lock applied — a signed provisioning record you can audit later. "The process was right" is a claim; a per-device attestation is evidence, and the gap between them is exactly where silent defects hide.

• Generate on-die where the hardware allows — the private key never leaves the chip, and the factory handles only public material.
• When injection is unavoidable, keep tight custody — secrets born in an HSM, delivered encrypted, injected by tooling that retains nothing, with plaintext never written to a factory disk.
• Make every device unique and registered — a per-device identity, certified and recorded in a backend, so that legitimacy is known rather than asserted.
• Drive the lifecycle to fully secured on the line — the locking transition applied and verified before the unit ships, never deferred to firmware or to luck.
• Account for every unit built — reconcile produced against ordered, so overproduction appears as a discrepancy in a ledger rather than a surprise in the field.
• Verify provisioning per device — a signed, auditable record for each unit, because a fleet is only as provisioned as its worst-handled device, and you will never know which one that was without the record.

The root of trust is the one security property you cannot add later. A firmware flaw, a weak protocol, a rotated server key — all of these can be fixed in the field. The identity and the fuses cannot; they are set once, in a building the vendor largely does not control, with the device in its most exposed state. When 6QURE reviews provisioning, the work is to follow a single device through that building — what secret it was given, who could have seen it, whether it left fully locked, and whether anyone can prove any of it — because that short, unglamorous passage is where the entire chain of trust is either anchored or quietly lost.