ETSI Draft Puts Boot Managers Under CRA Scrutiny
On 17 June 2026, ETSI's work item for EN 304 623, Cybersecurity requirements for boot managers, entered the deliverable approval procedure. The public draft shows how the Cyber-Resilience Act (CRA) is reaching below operating systems and applications into the firmware that establishes the first chain of trust.
The draft is not final, and it does not yet confer presumption of conformity. But it is still important: the ETSI work item shows the direction of travel for boot managers listed as Important Products under the CRA.
Why boot managers matter
Boot managers run before the operating system and before most product security controls are available. They decide what code starts, which boot target is trusted, whether recovery is allowed, and which configuration or measurement data survives handoff.
If that layer is compromised, later controls may not matter. A device can have good application hardening and strong cloud authentication, but still boot attacker-controlled firmware if the trust chain is weak.
That is why the CRA lists boot managers as Important Products — Class I, and why a dedicated vertical standard is emerging for them.
What the draft covers
The draft uses three boot-manager use cases:
| Use case | Security profile | Characterised by |
|---|---|---|
UC-IMM | Low | Immutable code and trust anchors |
UC-VER | Medium | Verified boot, update capability, logging, and key provisioning |
UC-HW | High | Verified boot plus hardware-assisted security |
That structure matters because it is risk-based. An immutable, non-updateable boot manager is not treated the same way as a hardware-assisted boot manager with update, logging, key provisioning, and recovery capabilities.
The draft covers topics including:
- verified boot and measured boot,
- anti-rollback protection,
- secure update and recovery behaviour,
- trust anchors and key provisioning,
- debug-interface control,
- boot logging and attestation data,
- configuration protection,
- availability and recovery,
- security testing and assessment evidence.
What this means for embedded teams
For embedded-device manufacturers, the key lesson is that secure boot is not just a checkbox. A credible CRA story may need evidence that the full boot architecture works under failure, update, recovery, and manufacturing conditions.
Teams should be asking:
- Are trust anchors immutable or otherwise hardware-protected?
- Are anti-rollback counters protected against downgrade attacks?
- What happens if an update fails halfway through?
- Are debug interfaces disabled, fused off, or authenticated in production?
- Can boot measurements, logs, and recovery events be trusted?
- Which evidence proves these properties on the exact production hardware?
These questions affect MCU and SoC selection, not just bootloader code.
We've updated the handbook
We have updated several handbook pages to reflect the draft:
- ETSI EN 304 623: Boot Managers is now the canonical handbook page for the draft, its scope, and the evidence themes it raises.
- CRA Overview now explains why boot managers are an Important Class I category and how EN 304 623 fits into the harmonised-standards picture.
- Secure Boot now calls out verified boot, measured boot, rollback protection, debug lockdown, and recovery evidence.
- STM32 Hardware Selection and ESP32 Hardware Selection now ask whether the chosen MCU or SoC can support boot-manager-style evidence.
The practical takeaway
EN 304 623 is still a draft, but it is a strong signal. CRA implementation is not stopping at application software or cloud services. It is reaching the bottom of the stack, where hardware roots of trust, boot ROMs, update recovery, and debug controls determine whether the rest of the product can be trusted.