Device Identity Provisioning at the Factory Floor

The factory floor is where device identity is born — or where it is fatally compromised. How the private key gets into the secure element determines whether the device's identity is genuinely hardware-bound or merely hardware-adjacent. Three provisioning models exist, each with different security properties, throughput characteristics, and supply chain trust requirements.

Three provisioning models

Model	How it works	Key exposure risk	Line throughput	CM trust required
On-device key generation	SE generates keypair internally; CSR sent to CA; certificate returned and stored	Lowest — key never leaves SE	Slower (SE crypto + CA round-trip)	Low — CM sees CSR, not key
Pre-provisioned SE	Silicon vendor generates key and certificate at wafer/package; device ships with identity	Low — vendor's secure facility	Fastest — no provisioning step	None — identity exists before CM
Key injection	External HSM generates keypair; private key transported to SE over secure channel	Highest — key in transit	Fast (parallel HSM generation)	High — CM handles private keys

On-device key generation is the gold standard for security — the private key is born inside the SE and never exists anywhere else. The trade-off is speed: the SE's internal RNG and key generation take 50–500ms depending on the part, and the CA must sign the CSR and return the certificate before the device moves to the next station. This is where CA throughput matters.

Pre-provisioned SEs (Microchip Trust Platform, Infineon OPTIGA Trust) eliminate the provisioning step entirely — the device arrives at the CM with identity already installed. The trade-off is that the certificate hierarchy is controlled by the silicon vendor unless you use a custom provisioning programme. For Matter-specific pre-provisioning, see Matter Device Attestation Certificates.

Key injection is the legacy model still common in contract manufacturing. It works, but the key exists outside the SE during transport — creating a window of exposure. If the CM is compromised, every key injected through that facility is compromised. The hardware vs software key storage analysis explains why this window matters.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

Key transport security

For key injection models, the transport channel between HSM and SE is the critical attack surface. Two approaches:

Encrypted channel: HSM wraps the private key with a transport key known only to the SE. Requires the SE to support key unwrapping (ATECC608B, OPTIGA Trust M both do). The transport key itself must be provisioned — turtles all the way down, but the chain terminates at silicon-vendor-injected secrets.
Physical isolation: Air-gapped provisioning station with no network connectivity. Keys travel on encrypted USB tokens between HSM and station. Slower, more operationally burdensome, but eliminates network-based key exfiltration.

Provisioning station architecture

The provisioning station is the fixture that holds the device, communicates with the SE, and coordinates with the CA. Architecture varies by provisioning model, but common elements include:

Device fixture: JTAG/SWD or I²C/SPI connection to the SE. Must support the SE's communication protocol and timing requirements.
Provisioning controller: Industrial PC or embedded controller running the provisioning software. Connects to the CA (local or cloud) and manages the certificate request/response flow.
CA integration: For cloud CAs (AWS PCA, 3AM Mint), the controller needs network access with appropriate latency for the line rate. For on-premises CAs (EJBCA), the CA runs on the factory network or on the station itself.
Logging and audit: Every provisioning operation must be logged — device serial, certificate serial, SE part ID, timestamp, success/failure. This is the chain of custody for regulatory compliance. See Machine Identity Governance for the broader governance framework.

Provisioning station architecture: air-gapped HSM or cloud CA → provisioning controller → device fixture → SE/TPM — annotated with key transport channels, verification checkpoints, and failure handling. Contract manufacturer trust boundary highlighted.

End-of-line verification

Provisioning is not complete until verified. End-of-line tests must confirm:

The SE contains a valid certificate chain (DAC → PAI → PAA for Matter, or the custom xPKI chain)
The SE can perform a challenge-response proving possession of the private key corresponding to the certificate
The certificate serial is registered in the fleet inventory system
The secure boot chain is intact — firmware signature verification succeeds using the SE-stored public key

Devices that fail verification must be quarantined, not reworked on the line — rework stations are a common source of provisioning errors and security gaps.

Contract manufacturer trust boundaries

Most hardware companies use contract manufacturers. The CM is an outsider with physical access to every device. The provisioning model determines what the CM can compromise:

On-device keygen: CM sees CSRs (public keys) and certificates — not private keys. Compromise of the CM does not compromise device identity.
Pre-provisioned SE: CM never touches identity material. Identity arrives with the silicon.
Key injection: CM handles private keys in transit. Compromise of the CM compromises device identity. Mitigations (encrypted transport, air-gapped stations) reduce but do not eliminate this risk.

For the broader vendor dependency analysis, see Vendor Lock-in & Device Identity.

Implementation Guide — CTO Strategy & Business Case — SPIFFE & Workload Identity — Matter DAC — Hardware vs Software Keys — IoT Certificate Lifecycle — Private CA Comparison. Contact Axelspire or Ask Axel.