CRA Secure Boot and Firmware Signing for MCUs

Secure boot is one of the foundational requirements in the CRA, and it's the one that causes the most confusion for firmware teams. The regulation doesn't use the phrase "secure boot" directly — but Annex I Part I lays down requirements that are impossible to meet without it.

If you're building MCU-based products that will be placed on the EU market, you need a boot integrity chain and a firmware code signing pipeline. This post explains what the regulation requires, how to implement it for common MCU families, and what the documentation burden looks like.

What Annex I Actually Requires

Three Annex I Part I requirements map directly to secure boot and firmware signing:

Requirement 3 — Integrity protection:

Products must be designed so that their integrity is protected. This includes protection of firmware and software against unauthorised modification. For MCU firmware, this means: a mechanism to verify that the code running on the device is the code you intended to ship, and that it hasn't been tampered with at rest or during the update process.

Requirement 6 — Minimise attack surface:

Products must minimise the attack surface, including external interfaces. An unsigned bootloader that loads arbitrary firmware images from flash is an open attack surface. Secure boot closes it by verifying firmware authenticity before execution.

Requirement 2 — No known exploitable vulnerabilities:

Products must be delivered without known exploitable vulnerabilities. An unsigned or unverified boot chain is itself a vulnerability — it allows persistent code execution via firmware replacement attacks.

Taken together, these requirements mean: your device must verify the authenticity and integrity of its firmware at boot time, and the signing keys must be managed securely.

Secure Boot vs. Verified Boot vs. Measured Boot

These terms get conflated. For CRA compliance purposes, the distinctions matter:

Secure Boot: The bootloader verifies a cryptographic signature on the firmware image before transferring execution. If verification fails, the device refuses to boot the image. This is the minimum bar for CRA compliance on most MCU platforms.

Verified Boot: A chain of trust where each stage verifies the next — ROM bootloader verifies first-stage bootloader, first-stage bootloader verifies application firmware. Each stage is signed independently. This is what platforms like STM32 SBSFU and MCUboot implement.

Measured Boot: Each stage is hashed and the measurement is recorded (typically in a TPM PCR or equivalent). The device boots regardless of measurement, but a remote verifier can check whether the device booted the expected code. This is common in Linux-based systems with TPM but rarely used in bare-metal MCU deployments.

For CRA compliance: Verified boot (with a chain of trust from an immutable root) is the recommended approach. Measured boot alone isn't sufficient — it doesn't prevent a tampered image from executing; it only detects it after the fact.

Root of Trust: Where the Chain Starts

The entire boot integrity chain depends on an immutable root of trust — a piece of code and/or a public key that cannot be modified by software. If an attacker can replace the root of trust, the entire chain is broken.

STM32 (STMicroelectronics)

STM32 MCUs with Secure Boot and Secure Firmware Update (SBSFU) use the OTP (One-Time Programmable) fuses to store the root of trust public key hash. Once the Read-out Protection (RDP) level is set to Level 2, the internal flash containing the secure bootloader is permanently locked.

• Root of trust: OTP-fused public key hash + locked bootloader in protected flash
• Algorithm support: ECDSA P-256 for signature verification, AES-128-CBC for firmware encryption (default configuration)
• Key revocation: Limited — OTP fuses don't support easy key rotation; plan your key management carefully

ESP32 (Espressif)

ESP-IDF's secure boot V2 uses eFuse storage for up to three RSA-3072 or ECDSA-P256 public key digests. Once secure boot is enabled and the eFuses are burned, the ROM bootloader will only execute a signed second-stage bootloader.

• Root of trust: eFuse-stored key digests (up to 3 key slots for rotation)
• Algorithm support: RSA-3072, ECDSA P-256 (ESP32-S2 and later)
• Key revocation: Supported — individual key slots can be revoked via eFuse

NXP (i.MX RT, LPC, Kinetis)

NXP's HAB (High Assurance Boot) and newer AHAB use OTP fuses to store the Super Root Key (SRK) hash. The ROM bootloader verifies the first-stage image using the SRK table embedded in the image, validated against the fused hash.

• Root of trust: OTP-fused SRK hash
• Algorithm support: RSA-2048/4096 (well-established); ECDSA support varies by platform and HAB version — check your specific SoC's security reference manual
• Key revocation: SRK table supports up to 4 keys with per-key revocation via OTP fuses

Nordic Semiconductor (nRF52, nRF53, nRF91)

Nordic's Secure Bootloader (nRF Secure Immutable Bootloader, NSIB) uses a public key hash provisioned into a protected region. On nRF91 and nRF5340, ARM TrustZone provides hardware isolation for the secure bootloader.

• Root of trust: Provisioned key hash in KMU (Key Management Unit) or protected flash
• Algorithm support: ECDSA P-256 via nrf_oberon or cc310 crypto libraries
• Key revocation: Supported via key slot mechanism

Code Signing Pipeline

Having secure boot hardware support is necessary but not sufficient. You also need a signing pipeline that protects your private keys and integrates into your build process.

Minimum Viable Signing Pipeline

1. Key generation: Generate an ECDSA P-256 or Ed25519 key pair. The private key never touches a developer workstation or CI runner's filesystem unencrypted.
2. HSM or KMS storage: Store the signing private key in a Hardware Security Module (HSM) or cloud KMS (AWS KMS, Azure Key Vault, Google Cloud KMS). For cost-sensitive teams, a YubiHSM 2 (~$750) provides PKCS#11-compatible key storage.
3. CI/CD integration: Your build pipeline produces an unsigned firmware binary, then calls the HSM/KMS to sign it. The signed binary is the release artifact.
4. Signature verification: The bootloader on the device verifies the signature against the public key stored in OTP/eFuse before executing the firmware.

┌─────────────┐    ┌──────────┐    ┌─────────┐    ┌────────────┐
│  CI/CD      │───▶│ Build    │───▶│ Sign    │───▶│ Release    │
│  Pipeline   │    │ Firmware │    │ via HSM │    │ Artifact   │
└─────────────┘    └──────────┘    └─────────┘    └────────────┘
                                        │
                                   ┌────┴────┐
                                   │  HSM /  │
                                   │  KMS    │
                                   └─────────┘

Algorithm Selection

Recommendation: Use Ed25519 for MCUboot-based systems (it's well-supported and fastest to verify). Use ECDSA P-256 when the MCU's secure boot ROM requires it (STM32, NXP HAB). Use RSA-3072 only for ESP32 secure boot V2 where the ROM requires it.

Anti-Rollback Protection

Signing prevents unauthorised firmware from running. But without anti-rollback protection, an attacker with physical access can flash an older, signed firmware version that contains a known vulnerability.

Annex I Requirement 2 (no known exploitable vulnerabilities) and Requirement 3 (integrity protection) together imply that rollback to a known-vulnerable version should be prevented.

How Anti-Rollback Works

The firmware image includes a monotonic version counter. The bootloader stores the minimum acceptable version in a one-way counter (OTP fuses, monotonic counter register, or a wear-levelled flash counter). During boot, the bootloader rejects any image with a version counter below the stored minimum.

Implementation by platform:

Limitation: OTP-fuse-based counters have a finite number of increments (typically 32 or 64). Plan your versioning strategy so you don't exhaust the counter during the product's lifetime. For a 10-year product with monthly security updates, 120 increments are needed — this exceeds most OTP counters. Consider using flash-based counters with integrity protection for long-lifecycle products.

Bootloader Comparison for CRA Compliance

For CRA purposes: MCUboot is the most portable and best-documented option for Cortex-M based designs. STM32 SBSFU is a reasonable choice if you're committed to the STM32 ecosystem. ESP-IDF secure boot is the only practical option for ESP32 products. U-Boot is relevant for Linux-based embedded systems (Yocto, Buildroot) rather than bare-metal MCU products.

Annex VII Documentation Requirements

Your technical documentation file must include evidence that the secure boot and firmware signing implementation meets Annex I requirements. Specifically:

1. Security architecture description

• Boot chain diagram showing each verification stage
• Root of trust description (which hardware mechanism, what key material is stored)
• Key management lifecycle (generation, storage, rotation, revocation)

2. Threat model coverage

• Firmware replacement attack and mitigation (secure boot)
• Rollback attack and mitigation (anti-rollback counter)
• Key extraction attack and mitigation (OTP fuses, HSM)
• Physical access attack surface (JTAG/SWD disable — see our post on CRA threat modeling for embedded)

3. Test evidence

• Test results showing the device rejects unsigned firmware images
• Test results showing the device rejects firmware signed with the wrong key
• Test results showing the device rejects rollback to a lower version
• Test results for the recovery mechanism when a valid image is unavailable

4. SBOM entries

• Bootloader component listed in the SBOM with version, supplier, license, and hash
• Crypto library used for signature verification listed separately

Implementation Checklist

Root of trust

• Public key or key hash provisioned in OTP/eFuse
• Bootloader stored in write-protected flash or ROM
• RDP/security fuses set to prevent readback of keys and bootloader

Signing pipeline

• Private signing key stored in HSM or cloud KMS (never in source control, never on CI filesystem)
• CI/CD pipeline signs firmware as a build step
• Signed binary is the only release artifact (unsigned binaries are not shipped)
• Signing key rotation procedure documented and tested

Boot verification

• Bootloader verifies firmware signature before execution
• Verification failure results in a safe state (not a boot loop — either hold in bootloader for recovery or load a known-good backup)
• Chain of trust covers all executable stages (ROM → bootloader → application)

Anti-rollback

• Monotonic version counter implemented in hardware or integrity-protected flash
• Bootloader rejects firmware with version below the stored minimum
• Counter increment strategy documented (how many updates before exhaustion)

Debug interface lockdown

• JTAG/SWD disabled or locked in production firmware (see debug interface section of the Annex I checklist)
• Readback protection enabled

Documentation

• Boot chain diagram in technical documentation file
• Key management lifecycle documented
• Test evidence for all verification scenarios
• Bootloader included in SBOM

If you're starting from scratch with secure boot and need to assess your full CRA gap, the Stack Canary assessment tool identifies which Annex I requirements you still need to address based on your current firmware architecture.

Based on Regulation EU 2024/2847 Annex I Part I (Requirements 2, 3, 6), Annex VII, MCUboot documentation, STM32 SBSFU reference, ESP-IDF Secure Boot V2 documentation, NXP HAB/AHAB documentation. This does not constitute legal advice.

Sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act (full text)
• MCUboot — Design documentation
• MCUboot — Image signing tool (imgtool)
• Espressif — Secure Boot V2 (ESP-IDF)
• STMicroelectronics — SBSFU Secure Boot and Firmware Update
• NXP — High Assurance Boot (HAB) overview
• Nordic Semiconductor — Secure Bootloader documentation
• Yubico — YubiHSM 2