Putting hardware-rooted identity on a connected-device line at the SMT stage.

A fleet-class IoT manufacturer adding hardware-backed device identity to a connected industrial product line — secure element on the BOM, certificate provisioning at the personalisation line, and a PKI lifecycle that survives 10-year fielded devices.

The challenge

The customer ships connected industrial controllers in tens of thousands per year, into environments where physical access is sometimes weeks of travel away. The existing identity story was a static device certificate per stock-keeping unit, signed by a single corporate CA, with a private key in flash.

That posture failed three tests their security team had begun to apply:

• Per-device uniqueness. An attacker who pulled the key out of one device could speak as any device of that SKU.
• Certificate lifecycle. Certificates were valid for the lifetime of the device, with no rotation path. A 10-year SHA-1 era certificate was still in service in some fielded units.
• Attestation. Backend services trusted the certificate but had no way to verify that the key the certificate covered was really inside a hardware secure element rather than in software somewhere.

The brief was to redesign the device-identity stack so that the next-generation product line shipped with each unit hardware-uniquely-identified, with a key rotation path, and with provable hardware-binding.

Architecture overview

The design centres on three components:

Standards involved

• X.509 — device certificate format.
• RFC 7030 EST — enrollment-over-secure-transport for re-issuance.
• RFC 8902 — attestation as an X.509 extension (where applicable).
• FIPS 140-3 Level 2/3 — secure element certification (where the chip is certified to that level).
• Common Criteria EAL5+ — for the secure element silicon.
• IEC 62443-4-2 — the customer’s industrial-controls cyber-security framework.

Deployment constraints

• SMT-line time budget. Personalisation has to fit into the existing line cadence. Adding more than a handful of seconds per board would cost more than the security upgrade is worth.
• Field rotation. Devices sit in remote environments for years. Certificate rotation has to be possible over a constrained cellular link without ever exposing the private key.
• 10-year horizon. The certificate chain has to be defensible for the life of the device. Algorithms picked today have to be ones the customer is happy holding in 2036.
• Cost. The secure element is a per-unit BOM line, so the bill has to fit the product margin.
• Existing devices. Already-fielded units cannot be retrofitted with a secure element; the customer accepted that the security upgrade applied to the new product line only and is shipped alongside the existing stack during a multi-year transition.

Trust model

The threats the customer’s security team had escalated:

• Device cloning. A counterfeit device with a copied certificate authenticating to the cloud as a legitimate unit.
• Key extraction. Recovery of a private key from a single physical device giving attackers durable identity-spoofing capability.
• Long-tail algorithm risk. A 10-year-old certificate locked to a deprecated algorithm with no rotation path.
• Insider supply-chain risk. A malicious actor at the contract manufacturer issuing valid certificates against fake devices.

The chosen architecture addresses each by construction:

Implementation approach

Three tracks, run in parallel:

1. Silicon & firmware. AmbiSecure delivered the secure element and the host-side firmware library that runs on the device’s main MCU. Library exposes a small API: generate_keypair(), attest(), sign(), import_certificate(), get_certificate().
2. PKI. Customer security team operated the issuing CA. AmbiSecure provided integration to the SMT-line personalisation rig (a small appliance that talks to the CA on one side and the device under test on the other).
3. Cloud-side verification. Customer cloud team updated the device-onboarding service to verify per-device certificates and the attestation extension. Old-style devices kept working during the transition.

SMT-line personalisation, step by step

// Per-device personalisation, end to end. Target: under 2 s.
1. Personalisation rig powers the device under test.
2. Rig sends: secure_element.generate_keypair("device-identity")
   -> secure element returns: public key + attestation signature
3. Rig forwards (CSR + attestation) to issuing CA over EST.
4. CA verifies attestation; signs a device certificate; returns it.
5. Rig sends: secure_element.import_certificate(cert)
6. Rig pings device: prove_possession(challenge)
7. Device proves possession of the private key with the secure element.
8. Rig logs the unit serial + certificate to manufacturing MES.

The full sequence fits comfortably inside two seconds per board, which the customer’s SMT line accommodates without a cadence change.

Operational considerations

• Manufacturing-rig redundancy. The personalisation rig is a single point of failure during line production. The customer ships two; either can run alone, but throughput depends on both.
• CA availability. The issuing CA is on the customer’s side of the network. Manufacturing has to call back to it for every device. Outages stop production. The customer accepted this; the alternative (offline issuance) had been rejected on supply-chain-risk grounds.
• Certificate validity. Initial certificates are issued for 5 years. EST re-enrolment over the device’s normal connectivity gives the customer the ability to rotate without touching devices.
• Cryptographic agility. The customer’s long-term roadmap names a candidate post-quantum algorithm and is comfortable that the secure element can be migrated to it in a future product generation. The fleet doesn’t need to move yet; the architecture doesn’t prevent it.

Integration flow

Once devices are in the field:

1. Device boots, opens mTLS to the cloud, presenting its device-identity certificate.
2. Cloud-side TLS terminator extracts the certificate, checks the chain, and pulls the attestation extension.
3. Cloud-side onboarding service verifies the attestation against the secure element’s manufacturer’s attestation root.
4. If both pass, the device is allowed to publish telemetry / accept commands.
5. If the certificate is approaching expiry, the device runs EST re-enrolment over the same mTLS channel; the secure element generates a new keypair, the CA issues a new certificate, and the rotation completes without operator intervention.

Lessons learned

1. "Device identity" is a four-layer problem. Silicon, personalisation, PKI, and runtime verification each have to be designed by the people who own them. A vendor that "does device identity" is usually only doing one or two layers; planning the other two is on you.
2. SMT-line time is the binding constraint. Every second of personalisation time costs real money at fleet volume. Designs that take 30 seconds per board do not survive into production. Design for two seconds.
3. Rotation > duration. A 5-year certificate with a working rotation path is safer than a 25-year certificate without one.
4. Attestation is what makes the certificate trustworthy. Without it, you have a PKI that says "this key has been signed by my CA" with no way to verify what the key is.

Related products and services

• IoT Security Chipset
• Technology: Secure elements
• Digital Signature Token (companion PKI hardware)
• Solution: secure-element integration
• JavaCard development service — for higher-end applet-based device identity.

Related references & reading

• Why Hardware-Backed Identity Matters
• APDU From First Principles
• Product: IoT Security Chipset (alternate link)
• Tool: X.509 viewer
• Tool: ASN.1 parser