Why the chain starts in silicon
Annex I demands integrity protection for firmware and configuration. On an embedded device that means the code that runs first must be immutable and must verify what it loads. Anything less and an attacker with flash access owns the device permanently.
A workable chain on a typical MCU or SoC:
- Immutable boot ROM — mask ROM in silicon, or a first-stage bootloader written to a one-time-programmable region and locked.
- Root of trust public key — the verification key hash burned into eFuses/OTP. Never the private key.
- Second-stage bootloader — signature verified by stage 1 before execution.
- Application image — verified by stage 2, including version/anti-rollback counter.
- Runtime attestation (optional) — the device proves its measured boot state to a backend before receiving credentials.
Debug ports must be closed as part of this: JTAG/SWD disabled or authenticated in production, and the transition from development to production lifecycle state made irreversible.
Choosing where keys live
| Option | Strength | Cost | Typical use |
|---|---|---|---|
| Plain internal flash | Weak — readable via any code-execution bug | Free | Never for long-lived secrets |
| MCU with protected flash region + readout protection | Moderate | Free with the right part | Low-value devices, defence in depth |
| Integrated secure enclave (TrustZone-M, secure processor) | Good | Silicon choice | Mainstream connected products |
| Discrete secure element (SE05x, ATECC, TPM) | Strong, tamper-resistant | ~€1 BOM plus board area | Devices holding third-party credentials, payment, critical class |
The CRA does not name any of these. Your risk assessment justifies the choice — and that justification must be written down. A €12 sensor with a per-device symmetric key in protected flash can be perfectly defensible; the same sensor holding a fleet-wide shared key cannot.
Per-device secrets during manufacturing
Fleet-wide shared keys are the classic embedded failure: one device extracted compromises every unit, so a single flaw becomes a full-fleet recall. Provision unique per-device identity at production, ideally as a keypair generated inside the secure element so the private key never leaves it, with the manufacturing station holding only a signing CA and never the device secrets.
The production line then becomes part of your attack surface: HSM-backed CA, access-controlled programming stations, audit logs of every certificate issued. Market surveillance can ask how device identity is provisioned.
Signing infrastructure that survives ten years
- HSM-held signing keys. No key material on a developer laptop or a CI runner's disk.
- Separate keys per role — development, release candidate, production — so a compromised dev key does not sign shipped firmware.
- A rehearsed rotation and revocation plan. Devices must be able to accept a new signing key via a signed update; design a key-update path or you cannot recover from a compromise.
- Documented custody. Who can trigger a production signature, under what approval, with what audit trail.
The support period may be ten years or more. The keys, the HSM, the build container and the toolchain must all still exist and still work at year nine. Version and archive them together with the release.