Embedded PKI Architectures for IoT Security

Public-key infrastructure on the open web has a comfortable set of assumptions: the relying party has a clock, memory is plentiful, the network is reachable, revocation lookups happen on demand. None of these hold reliably on a connected device. Embedded PKI is not "the same PKI on a smaller computer" — it is PKI under different assumptions, and getting it right is what makes IoT identity meaningful.

The assumptions break

Designing PKI for embedded systems starts with naming the assumptions that don't hold:

• Clocks: a device may not have an authoritative time source on power-up. NotBefore/NotAfter checks become a design problem, not a library call.
• Memory: certificate paths and CRLs can dwarf the device's available RAM. Path validation needs to be incremental, and revocation cannot rely on storing large lists.
• Connectivity: the device may be offline at the moment a check is needed. OCSP and CRL fetches do not happen on demand the way they do on a phone.
• Lifetime: devices may live longer than the algorithms or hierarchies they were issued under. Crypto agility becomes a property of the architecture, not an afterthought.
• Manufacturing: the device receives its first credentials in a controlled environment that has its own constraints — and those constraints are part of the PKI design.

A workable hierarchy

Most embedded PKI deployments converge on a similar shape:

• Root of trust — held offline, signs intermediates, never used directly.
• Manufacturing intermediate — used in controlled provisioning environments, signs product-line intermediates.
• Product / SKU intermediate — issued per product family, allows revocation at product granularity.
• Per-device leaf — generated in the Secure Element, signed by the appropriate intermediate, never leaves the SE in usable form.

The hierarchy is not arbitrary. Each layer aligns with a real-world boundary — the offline root with the most trusted process; the manufacturing intermediate with a specific factory or batch; the product intermediate with a recall surface; the leaf with the device.

Where keys actually live

The leaf key is the one that matters operationally. It must be:

• Generated inside the Secure Element / eUICC.
• Signed by an authorized issuer under a controlled provisioning step.
• Used only inside the SE, never exposed to firmware.
• Bound to a specific device via documented manufacturing logic.

If the leaf key ever exists, even briefly, in a place that isn't the Secure Element, the rest of the PKI architecture is doing significantly less than it appears to.

Revocation under embedded constraints

Revocation is where embedded PKI most often differs from web PKI. Three workable patterns:

Short-lived leaves with offline issuance

Devices receive shorter-lived leaves and re-attest periodically through the back-end. Revocation collapses to "stop reissuing". This works only when the device can be expected to reach the back-end at reasonable cadence.

Status-on-demand with caching

Relying parties (the back-end, not the device) check status when they receive an assertion, with caching to keep the load reasonable. This shifts the revocation burden off the device entirely.

Per-product or per-batch revocation

Revoke at the intermediate level when an entire product run is compromised. Less surgical, but operationally workable when granularity isn't critical.

None of these are universally correct. The right answer depends on connectivity, lifetime, and how surgical revocation needs to be.

Crypto agility

Devices live longer than algorithms. A 15-year industrial deployment provisioned today will live through cryptographic transitions that have not yet been announced. Embedded PKI architectures should:

• Use Secure Elements that support algorithm migration paths.
• Avoid baking specific OIDs or curve choices into firmware that cannot be updated.
• Plan for hybrid or multi-key designs where the operational risk warrants it.
• Make algorithm transitions a lifecycle event the architecture already understands.

Manufacturing as part of the PKI

The single highest-risk PKI decision is how the leaf key first gets signed. If a casual manufacturing tool can produce a valid signature, the entire PKI is downstream of that tool's security posture. Manufacturing-time provisioning needs:

• An authenticated, auditable issuance path.
• A small, well-defined tool with constrained capability.
• Logs that the back-end can correlate later.
• Failure modes that produce unprovisioned devices, not silent bad credentials.

Common mistakes

• Storing the manufacturing intermediate's private key in a place where it is reachable from a misconfigured tool.
• Treating the device as if it has wall-clock time when it doesn't.
• Designing revocation only for the connected case.
• Using one key role for everything (signing, key wrapping, authentication, attestation).
• Letting certificate path size grow until it blows the device's RAM under update conditions.

Where this fits in the architecture

Embedded PKI is not standalone. It is the structural layer underneath identity, attestation, secure provisioning, and lifecycle. Each of those depends on a hierarchy that holds up under the constraints described here. For the surrounding architecture, see trust chain architecture; for attestation specifically, see Device Attestation.

Embedded PKI is mostly about being honest about which assumptions don't hold. The architectures that survive in the field are the ones that name those assumptions early and design around them.

Conclusion

PKI on connected devices is a different engineering problem from PKI on the open web. Treating it as the same problem is the most common reason embedded PKI deployments age badly. Architectures that account for clocks, memory, connectivity, lifetime, and manufacturing — and that put the leaf key inside a Secure Element — produce identity that can actually be trusted at fleet scale.

FAQ

Related capability: Trust chain architecture · IoT Security