Generating Per-Device Keys at Manufacturing
Per-device keys are the right design, but they are only as good as the process that creates them. Generate them carelessly and you reintroduce the very shared-secret problem you were trying to avoid. The safest provisioning assumes the factory itself might be careless or hostile, and arranges things so it never touches a usable secret.
Why the Process Matters as Much as the Design
Deciding to use per-device keys is the easy part. The hard part is the provisioning process, the sequence of steps at manufacturing that actually creates, certifies, and installs those keys. A flawed process can undo the whole benefit, leaving you with the operational cost of unique keys and the security of a shared one.
The recurring theme of good provisioning is minimizing trust. Every system that handles a private key, every operator who can read one, and every database that stores one is a place the fleet’s security can leak. The strongest designs are the ones where the fewest parties ever touch a usable secret, ideally none but the device itself.
Generate on the Device
The strongest approach has each unit generate its own key pair internally, so the private key never exists anywhere else, not even on the manufacturing line. The device creates the pair inside its secure element or its crypto hardware and exports only the public key for certification.
# trigger on-device keygen; the private key never leaves the chip
provision_tool --generate --slot 0 --serial $(read_device_serial)device 340A91F2: generated P-256 keypair in slot 0 exported public key only; private key sealed in secure element
This removes the single most dangerous artifact, a central store of every device’s secret, from the process entirely. There is no file, no database, and no server that holds the private keys, because each one was born inside its device and never came out. A breach of the factory yields public keys, which are not secret by definition.
Beware the Central Key Server
Generating keys on a factory server and injecting them into devices is easier to build and a much larger risk. That server becomes a single point of failure holding every device’s private key. Breach it, or trust the wrong operator near it, and the whole fleet is exposed at once, exactly the outcome per-device keys were meant to prevent.
If a generation server is unavoidable, it has to be one of the most protected systems you run. Back it with a hardware security module so the keys are generated and wrapped without ever appearing in bulk plaintext, restrict and audit access tightly, and never let it accumulate a readable archive of private keys. The convenient version of this server is a catastrophe in waiting.
Certify the Public Key
After generation, the device’s public key is signed by your certificate authority, giving each unit a verifiable identity tied to your trust anchor. That certificate is what every later authentication and revocation decision references, and it is safe to handle because it contains no secret.
# sign the device's public key with the product CA to mint its identity cert
openssl x509 -req -in device_0.csr -CA product_ca.crt -CAkey product_ca.key \
-days 3650 -out device_0.crtSignature ok subject=CN=device-340A91F2 # device now has a certificate chaining to the product trust anchor
The certificate ties the device’s on-board key to your root of trust without your CA ever seeing the private key. The device proves possession of the private half by signing the request, the CA certifies the public half, and the secret stays on the device the whole time.
Protect the CA Itself
The certificate authority that signs device identities is the trust anchor for the entire fleet, which makes its private key the most valuable secret in the system. If that key leaks, an attacker can mint identities your backends will trust, so it belongs in a hardware security module and offline where practical.
A common and serious mistake is to keep the CA key on the same factory server that runs provisioning, for convenience. That concentrates the two most sensitive secrets in one breachable place. The CA key should be separated, hardware-protected, and used through a controlled signing service, not sitting in a file next to the provisioning script.
Inject Identity, Not Just Keys
Provisioning is also the moment to give each device the data it needs to participate in your system: its certificate, the trust anchor it should validate against, and any per-device configuration. Doing this once, securely, at manufacturing is far better than trying to bootstrap trust over the network later.
The device leaves the line already knowing who it is and who to trust, which closes a window attackers love: the first-boot or first-connect moment when an unprovisioned device might accept a malicious identity. A device provisioned correctly at the factory has no naive first contact to exploit.
Trust the Line Less
The safest provisioning assumes the manufacturing line itself might be careless or hostile, because it often runs at a contractor you do not fully control. On-device key generation, where the private key never exists off the chip, means a dishonest operator or a breached factory system has nothing worth stealing.
Design every step around that assumption. The factory triggers generation but never reads a private key, handles certificates but never secrets, and runs scripts that cannot exfiltrate anything usable. Building provisioning this way converts manufacturing from a point of catastrophic exposure into a step an untrusted partner cannot turn into a fleet-wide compromise.
Verify Provisioning Worked
A provisioning step that silently fails is its own risk, shipping units with no key, a duplicate key, or an uncertified one. Build a verification stage that confirms each unit has a unique, properly certified key before it leaves the line.
# end-of-line check: device has a unique cert chaining to the product CA
verify_tool --check-cert --device $(read_device_serial) --ca product_ca.crtdevice 340A91F2: unique key OK, cert chains to product CA OK, not a duplicate PASS
That end-of-line check catches the failures that matter: a unit that never generated a key, two units that somehow share one, or a certificate that does not chain to your anchor. Catching these at manufacturing is far cheaper than discovering them as field failures or, worse, as a security gap.
Handle the Test and Reject Path
Units that fail testing or get reworked are an overlooked provisioning hazard. A device that was partially provisioned, then pulled from the line, can carry a half-formed identity or a key that should never have been certified. Define what happens to those units so they do not leak secrets or ship in an inconsistent state.
The clean approach is to treat provisioning as atomic and revocable: a unit either completes the full flow and gets a certified identity, or it is wiped and its identity, if any was issued, is revoked. Rejected units should leave the line with no usable key and no trusted certificate, so a discarded board is not a discarded secret.
Plan for Re-Provisioning
Devices sometimes need a new identity: after a board repair that replaces the secure element, a security event that compromises a key, or a change of ownership. A provisioning design that only works once, at the factory, leaves you stuck when these happen. Decide up front how a device gets re-keyed under authenticated control.
The mechanism mirrors initial provisioning but gated by authentication: an authorized service tool triggers fresh on-device key generation and obtains a new certificate, while the old identity is revoked. Designing this path early means a repair or an ownership change does not force a choice between an insecure shortcut and scrapping the unit.
Common Pitfalls in One Place
The mistakes cluster into a short list: a central server holding every private key, the CA key stored next to the provisioning script, no end-of-line verification, no plan for rejected or repaired units, and weak randomness on the device producing predictable keys. Each one quietly reintroduces a shared-secret or single-point-of-failure problem.
Reviewing a provisioning design is largely a matter of walking that list and asking where a usable secret exists outside a device and who can reach it. The fewer such places, the more the per-device-key design delivers on its promise. The ideal answer is that no usable private key exists anywhere but inside the device that owns it.
Where This Fits
Designing or reviewing a manufacturing provisioning flow, so per-device keys are generated safely and the line never becomes a vault of secrets, is part of a product security assessment. If you want a provisioning design review before your line spins up, that is the kind of work we do at Berkner Tech.