Part 1 – Why ETSI’s Latest Guidance Makes Secure Boot More Important Than Ever
Secure Boot is No Longer Just Good Practice
For many years, secure boot has been regarded as one of the hallmarks of a well-designed embedded system. It has helped protect devices from tampered firmware, prevented unauthorised software from executing, and established a chain of trust that begins the moment power is applied.
The latest draft of ETSI EN 304 623 v0.1.3 (June 2026) suggests that the conversation is changing. While the Cyber Resilience Act (CRA) does not explicitly mandate secure boot, the latest draft devotes considerably more attention to boot verification, authenticated firmware, trust anchors, rollback protection and recovery. Taken together, these additions indicate that demonstrating a robust chain of trust is becoming an increasingly important part of demonstrating cybersecurity compliance.
For embedded developers this is an important shift. Decisions made during hardware selection and bootloader design now influence not only security, but potentially the evidence needed to support CRA conformity. Also, there is no longer the option of kicking the can down the road. Manufacturers will increasingly need to demonstrate how trust is established throughout the boot process. Failure to do so risks both delayed compliance and increased engineering effort later in the development cycle.
There may be a temptation for manufacturers to describe a product differently, or move functionality between components, to avoid classification as a boot manager or to remove the apparent need for secure boot and remote updating. In practice, the CRA is not based solely on the label placed on a product. Scope and classification depend on its intended purpose, reasonably foreseeable use and core functionality.
A device that still initialises hardware, selects firmware and transfers execution to an application does not cease to perform a boot-management function because it is described as system firmware or bundled into a larger product. Integration may change the conformity-assessment boundary, but it does not remove the need to assess the risks created by the boot process.
There are nevertheless legitimate architectural alternatives. A genuinely immutable device may have no update or OTA (Over-The-Air) capability and may fall into the immutable use case (UC-IMM) profile rather than the verified-and-updateable use case (UC-VER) profile. That choice carries its own obligation: the code and trust anchors must actually be protected by hardware-enforced immutability, and the manufacturer must account for the fact that vulnerabilities discovered after deployment cannot be patched.
Similarly, avoiding OTA does not necessarily mean avoiding secure updates. Updates can be delivered through controlled service tools, authenticated host systems or signed offline packages. What matters is not whether the update travels over the air, but whether the product has a credible method of addressing vulnerabilities throughout its support period.
A manufacturer can simplify its CRA obligations by reducing functionality and attack surface, but only where those restrictions are real, enforced and reflected in reasonably foreseeable use. In many connected products, implementing a protected chain of trust and a controlled update path is likely to be more defensible than attempting to explain why they are unnecessary.
Problems arise when embedded developers, who have not implemented secure boot in their previous products, have to get to grips with the complexities of today’s secure MCUs which have differing approaches to both key management and bare metal provisioning of their hardware. Many engineers will already be familiar with ARM TrustZone, particularly on higher-performance MCUs and MPUs, where it provides the hardware foundation for isolating secure and non-secure execution. However, tools provided by MCU vendors to ease the configuration of TrustZone can be complex to use and add to the challenges faced by embedded engineers. Unlike application development, mistakes during secure boot provisioning are not always recoverable. A configuration error during production programming can permanently lock a device, potentially affecting hundreds or thousands of units before the issue is detected. On top of that is the management of the secure boot signing and identity keys which you don’t want “safely” stored on an engineer’s “secure laptop”. Ultimately, anyone can implement secure boot. The real engineering challenge is implementing it securely while managing the cryptographic identities and keys that underpin the chain of trust.
Looking Beyond ‘Secure Boot’
One of the more interesting aspects of the ETSI draft is that it treats secure boot as part of a wider chain of trust rather than as an isolated feature. It distinguishes between unverified boot, verified boot and measured boot, before describing how trust should be established from immutable hardware through to the application firmware.
This subtle change is important. Rather than asking whether a product ‘supports secure boot’, the document encourages designers to consider whether every stage of the boot process can be trusted.
What Has Changed?
This new draft document provides much stronger implementation guidance around cryptographic verification, protection of trust anchors, rollback protection and secure recovery. The emphasis is no longer simply detecting modified firmware; it is proving that only authenticated firmware is permitted to execute and that the trust chain remains intact throughout the product lifecycle.
CQ Insight
In our experience, implementing the cryptographic verification itself is rarely the difficult part. The real engineering challenge is establishing a repeatable process for key management, provisioning, manufacturing and firmware updates without breaking the chain of trust. This is where engineering effort is typically underestimated. In the next article we will discuss the provisioning of secure MCUs in more detail and show how Crypto Quantique’s approach can ease the process.
Key Takeaways
- ETSI places much greater emphasis on establishing a complete chain of trust.
- Secure boot alone is not enough; provisioning, key management and recovery all matter.
- Choosing hardware with built-in security capabilities can simplify implementation and CRA compliance.
- Effective key and identity management are just as important as the secure boot implementation itself.