Why does the secure element verify firmware signatures instead of the host MCU?

Because an attacker who compromises the host MCU can lie about signature verification. Moving the verification inside the secure element means an attacker must also compromise the SE's burned-in issuance public key — which is a different and considerably harder problem.

What does an IoT attestation chain actually look like?

Device attestation signature → per-batch attestation CA → AmbiSecure issuance CA → HSM key ceremony record. The auditor walks that chain backwards from a deployed device to prove the credential came off the certified line. The whole chain is verifiable at any future point.

IoTCornerstonePublished 2026-05-11Updated 2026-05-1113 min read

Building Secure IoT Identity with Security Applets.

Q: How often should IoT device keys rotate?

Operator policy. Monthly for high-assurance industrial control. Annually for consumer IoT. Never (or only on incident) for the long tail of disposable sensors. The rotation applet handles the cryptography; the cadence is a business decision.

Hardware-backed IoT identity isn’t one applet, it’s five. Provisioning, attestation, mTLS, signed firmware, key rotation — on a Common Criteria EAL5+ secure element the host MCU never sees the private key on.

The IoT identity problem, restated

An IoT device is a credential bearer that lives outside an administrator's reach for years. It boots at a factory line. It is shipped to a customer site. It connects to a cloud or fleet platform. It runs for five to fifteen years. It will, eventually, be compromised — an attacker physically present, a malicious firmware update, a stolen unit reverse-engineered to extract a key. The identity architecture has to assume all of these and still be defensible.

The single most consequential decision is where the device's private key lives. If it lives in flash on the host MCU, the key is extractable by anyone with the device in hand. If it lives in a hardware secure element with a certified boundary, extraction becomes a different problem — one with cost-per-extraction in the thousands or tens of thousands of dollars per key, depending on the certification class. That is the threshold a serious IoT identity programme has to clear.

This post walks through how IoT security applets on a hardware secure element solve the credential-lifecycle problem from first boot through revocation.

The applet layer, briefly

A secure element on its own is silicon. It runs whatever applet you load onto it. The applet layer is where the device's identity workflow gets expressed: provisioning, attestation, mutual TLS, signed firmware update, key rotation. A well-designed IoT identity programme assembles the right set of applets and loads them on a CC EAL5+ secure element over GlobalPlatform SCP03. The host MCU then talks to the secure element over a thin bus (ISO 7816, I2C, SPI) and never sees the private key.

Five applets cover the IoT identity lifecycle:

1. The provisioning applet

First boot. The device leaves the factory with a Master Key already injected during personalisation. The provisioning applet's job is to derive per-device identity keys from the Master Key and the device's unique identifier (UID), then lock the security domain so the operation cannot be repeated without an authorised admin ceremony.

The flow:

Personalisation line injects the Master Key into the secure element's secure domain over SCP03.
Device powers on at the customer site.
The provisioning applet computes identity_key = KDF(master_key, UID, "identity-v1").
The applet stores the identity key in a non-extractable slot, exports the public key for the fleet platform to ingest, and sets a "provisioned" flag.
The "provisioned" flag refuses further provisioning until an admin re-key ceremony.

The point of this dance: extraction of one device's key tells the attacker nothing about any other device's key, because each is derived from the unique UID. Compromise of one device is bounded by that one device.

2. The attestation applet

Once provisioned, the device needs to prove to a fleet platform that it is, in fact, the hardware that was provisioned. This is attestation. The applet emits a signed quote covering:

The device's UID.
The device's identity public key.
A nonce supplied by the verifier (replay protection).
A signature from the attestation key, which is itself signed by the per-batch attestation CA.

The verifier (cloud-side or on-prem) walks the chain: the attestation signature is valid; the attestation CA is the AmbiSecure issuance CA; the device is therefore the hardware that came off the line. The verifier can now trust the identity public key for mutual TLS, encrypted command channels, signed telemetry, anything.

This is structurally identical to FIDO2 attestation (WebAuthn attestation) and to TPM attestation. The pattern repeats because the problem repeats: prove the hardware is what it claims to be.

3. The mTLS credential applet

For day-to-day operations the device authenticates to its fleet platform via mutual TLS. The mTLS credential applet holds the X.509 client certificate and the matching private key. The host MCU's TLS stack delegates the private-key operations (sign the handshake's CertificateVerify) to the applet over APDU.

What the host MCU sees: a thin shim that returns "here is the signed CertificateVerify." What the host MCU does not see: the private key. An attacker with control of the host MCU can still force handshakes using the applet, but cannot exfiltrate the credential for use elsewhere. Compromise containment is the goal.

4. The signed-firmware applet

Firmware updates are the highest-risk operational surface in IoT. A malicious firmware update gives the attacker permanent control; nothing else comes close in blast radius.

The signed-firmware applet verifies update signatures inside the secure element, not on the host MCU. The flow:

Fleet platform serves a firmware image plus a detached signature.
Host MCU streams the firmware image and the signature to the applet.
The applet computes the firmware hash and verifies the signature against an issuance public key burned into the applet at personalisation.
The applet returns "valid" or "invalid." The host MCU only applies the update on "valid."

An attacker who compromises the host MCU still cannot accept a tampered update; the signature verification is inside the secure element. To pass a tampered update, the attacker must compromise the issuance signing key — which lives in an HSM at the operator’s manufacturing site, not on the device.

5. The key-rotation applet

Long-running devices need credential rotation. Static keys are static threat surfaces. The key-rotation applet handles per-device key rolls on a schedule the operator sets:

Generate a fresh identity keypair inside the secure element.
Sign the new public key with the previous identity key (the proof-of-continuity).
Push the signed transition to the fleet platform.
Mark the previous key as retired but retain it for forensic decrypt of historical telemetry encrypted to that key, until the operator's retention window expires.

Rotation cadence is operator policy: monthly for high-assurance industrial control; annually for consumer IoT; never (or only on incident) for the long-tail of disposable sensors.

Where the host MCU sits

The host MCU runs the device's application. It does network I/O, business logic, sensor I/O, the user-facing surface. It does not hold private keys. The relationship to the secure element is asymmetric: the MCU calls the SE, the SE refuses operations the MCU is not authorised to perform.

From an integration perspective, this is a thin shim library (~3 KB ROM on a Cortex-M) that:

Wraps APDU construction for the five applets.
Exposes a credential-lookup API to the host's TLS / mTLS stack.
Exposes a firmware-verify API to the host's bootloader.
Handles SE bus errors gracefully (retry, fail-safe to "no credential available").

The shim is the only host-side code that touches the SE. Everything else in the device's firmware is unchanged.

Standards posture

The applets use ECC P-256 / P-384 for new deployments and RSA 2048 / 3072 for legacy fleets that have existing CA infrastructure. Hashing is SHA-256 / SHA-384. Personalisation is GlobalPlatform SCP03 (AES-128). The secure element itself is Common Criteria EAL5+.

For a regulated fleet (industrial IoT, automotive, medical devices), the standards posture matters at audit time. The traceability is: X.509 certificate ↔ attestation chain ↔ per-batch CA ↔ AmbiSecure issuance CA ↔ HSM key ceremony record. The auditor can walk that chain from a deployed device back to a key ceremony with a documented quorum.

What an attacker still has

Hardware-backed IoT identity is not a complete defence; it is a credential-protection layer. An attacker who physically captures a device can still:

Use the device’s credentials for as long as the operator doesn’t revoke them. Detection is the operator's job; revocation is the operator's job.
Reverse-engineer the host MCU's logic and discover application-layer vulnerabilities (the SE protects keys, not code).
Perform side-channel and fault-injection attacks against the SE at considerable cost — the CC EAL5+ certification means "considerable cost," not "impossible."

The threat model the SE addresses is "attacker extracts the credential and uses it elsewhere." The threat model it does not address is "attacker uses the captured device itself." For that, the operator's revocation pipeline has to be fast enough — minutes, not days — from "device reported missing" to "device's credential is no longer accepted."

The bottom line

A serious IoT identity programme runs five applets on a CC EAL5+ secure element: provisioning, attestation, mTLS, signed update, key rotation. The host MCU stays light; the SE stays load-bearing. The credential lifecycle — from factory injection through field rotation to revocation — lives inside an auditable chain. None of this is novel; the standards have been stable for a decade. What changes is the depth and discipline with which the applet layer is implemented. That is where AmbiSecure ships.