.png){kind=logo}
Implement Secure Boot for CRA
In the context of the EU Cyber Resilience Act (CRA), ensuring device integrity from the earliest stage of operation is a critical cybersecurity objective. Annex I of the CRA outlines essential requirements that all products must meet regardless of classification. While detailed harmonized standards are still under development (expected by September 2026), manufacturers are already under pressure to align product designs with CRA expectations ahead of the regulation’s enforcement in December 2027.
Secure boot is a foundational mechanism that ensures only trusted and verified firmware can be executed on a device. By cryptographically validating the firmware at startup, secure boot plays a direct role in addressing CRA objectives around protection from unauthorized access, malicious code execution, and software integrity.
This guide explores how secure boot fits into CRA compliance and how cryptographic controls, particularly those enabled by Public Key Infrastructure (PKI) and digital signing, support manufacturers in fulfilling their obligations, even in the absence of finalized harmonized standards.
This guide is intended for embedded engineers, product security teams, firmware developers, and compliance leads who are building or maintaining connected products intended for the European market. It is especially relevant to those responsible for security architecture and product lifecycle risk mitigation, including those preparing for conformity assessment under the CRA.
Key Challenges in the Domain
Organizations face several key challenges when building compliant and secure products under the CRA and related regulations, including:
Meeting CRA Annex I security requirements without finalized harmonized standards
Designing secure boot processes that are resilient, scalable, and verifiable
Ensuring firmware authenticity and integrity in resource-constrained environments
Managing and protecting cryptographic materials (e.g., root of trust, signing keys)
Integrating PKI and signing processes into manufacturing workflows
Planning product roadmaps with regulatory deadlines and design lead times in mind
Supporting both new and existing product lines with retrofit-ready security architectures
Disclaimer: This guide provides one possible interpretation of the Cyber Resilience Act (CRA) and outlines how enabling Secure Boot may contribute to compliance efforts.
Keyfactor anticipates that forthcoming harmonized standards will align with this interpretation; however, at the time of writing, Keyfactor does not have direct involvement or firsthand insight into the development of those standards.
Secure Boot for CRA
Secure boot definition
Secure boot is a means to verify that the software/firmware running on a product with digital elements (PED) is authentic and can be trusted. It works by using cryptographic signatures rooted in a chain of trust starting from immutable code (e.g., ROM) to validate each stage of the bootstrapping process. Only code signed with trusted keys can run.
A simple secure boot process can work like this:
The Immutable ROM (BootROM) is the first code to execute when the device is reset or powered on.
The BootROM initializes basic hardware functions (clocks, memory controller, security processor, etc.)
The BootROM also has access to a non-mutable public cryptography key (or a hash of a cryptography key).
The BootROM loads the next stage, the signature of the next stage, and the public key associated with the signature of the next stage.
The BootROM tests that the public key matches the non-mutable public cryptography key.
After verifying that the public key is trusted, it is used to verify the signature of the next process stage.
If the signature passes, control is transferred to the next stage.
The next stage is the First-Stage Bootloader (FSBL) - (u-boot will call this the minimal Secondary Program Loader or SPL in u-boot, which is misleading). This is a minimal bootloader.
The FSBL initializes more device hardware (like DMA, DRAM, CPU core, and other peripherals).
The FSBL also has access to the non-mutable public cryptography key.
The FSBL loads the next stage.
As in the BootROM, the public key is tested for match
As in the BootROM, if the public key is trusted, it is used to verify the signature of the next process stage.
As in the BootROM, if the signature passes, control is transferred to the next stage.
The next stage is the Operating System (OS).
The operating system and the final payload.
In Linux-type systems, this may be a Flattened Tree Image (FIT) including the kernel, device tree blob, initramfs, configurations, and the digital signatures of these items or a combined FIT signature.
In Real-Time Operating Systems (RTOS), this typically includes all of the applications packaged with the RTOS.
Either system may implement trusted application loading, which follows a similar pattern to the above flows.
Simple Secure Boot Process Diagram:
Of course, more stages can be (and are) added by different secure boot mechanisms on different devices. For example, in UEFI boot, the core processor can load U-Boot as the FSBL, which then loads UEFI, which then loads the Operating System. This UEFI model is common in ARM SBSA platforms and is used in ARM reference platforms using Trusted-Firmware or in implementations like QEMU.
The specific implementation is very chipset-specific (due to the RomBOOT reliance) and must align with the higher-level designs in place.
Secure Boot Alignment with CRA Annex I
How does secure boot align with the CRA? The following table aligns the Essential Cybersecurity Requirements in Annex I with the features enabled by secure boot.
CRA Annex I Part I Clause | Verbatim Text | Secure Boot Relevance |
|---|---|---|
(1) | Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. | ✅ Secure boot is a foundational control to address boot-time code tampering risk. |
(2)(a) | Be made available on the market without known exploitable vulnerabilities. | ✅ Boot-time code execution without verification = known exploit class. Secure boot mitigates this. |
(2)(d) | Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access. | ✅ Prevents execution of unauthorized firmware — an entry point for unauthorized access. |
(2)(f) | Protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions. | ✅ Secure boot ensures that command and code integrity is preserved at boot. |
(2)(j) | Be designed, developed and produced to limit attack surfaces, including external interfaces. | ✅ Bootloaders are high-value attack surfaces. Secure boot reduces that surface by enforcing signed-only code. |
(2)(k) | Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques. | ✅ Secure boot prevents persistence of malicious code after a reboot — reducing incident impact. |
(2)(l) | Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user. | 🟡 Secure boot complements this by ensuring only authorized logging components run. |
(2)(m) | Provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner. | ⚪ Not directly related to boot, but secure boot ensures the erasure tool itself can be trusted. |
Source: OJ L, 20.11.2024, Regulation (EU) 2024/2847, Annex I
Notice that secure boot is not explicitly referenced. Instead, it can be a control that enables compliance with several essential requirements in Annex I:
Reduces known vulnerabilities (2)(a)
Prevents unauthorized modifications (2)(f)
Hardens the attack surface (2)(j)
Ensures continuity of trust and incident resilience (2)(k)
The process of signing is a part of secure boot
CRA Annex I Part I Clause | Verbatim Text | Secure Signing Process (Secured Keys and Auditing) |
|---|---|---|
(1) | Products with digital elements shall be designed, developed, and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. | ✅ Minimized risk of unauthorized signed software. |
(2)(d) | Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access. | ✅ Prevents execution of unauthorized firmware — an entry point for unauthorized access. Keys are only used in secured enclaves. |
(2)(j) | Be designed, developed, and produced to limit attack surfaces, including external interfaces. | ✅ Control over keys and auditing of signing operations limits attack vectors. |
(2)(l) | Provide security-related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user. | ✅ Control over keys and auditing complements this by ensuring only authorized users can sign software. |
Also, in reference to (2)(d), (2)(f), and (2)(I), the control of the signing keys can be inferred. What does this mean?
Preventing unauthorized access to the private signing keys is critical in preventing software with intentional vulnerabilities from being trusted.
While this is not a function of secure boot, it is a function of the process used to sign the components as trusted pieces. Many existing processes and tools cannot:
Prevent signing keys from being distributed on many computers at once (security risk)
Prevent signing keys from being copied without authorization (security risk)
Prevent signing keys from being used inside of a secure enclave (security risk)
Provide auditing information on signing operations.
The signing process is also part of secure boot security and is at the core of establishing trust in the private/public key pair used for signing.
How Keyfactor helps?
EJBCA PKI and SignServer provide the PKI and signing infrastructure required to implement secure boot at scale and to meet the security requirements of the Cyber Resilience Act (CRA). Together, they enable manufacturers to establish trust across diverse hardware platforms and supply chains, from initial provisioning to field updates.
Key capabilities include:
Code and Firmware Signing – Sign bootloaders and firmware images using policy-controlled workflows to ensure only verified code is executed at startup.
Root of Trust Management – Protect signing keys in Hardware Security Modules (HSMs) and establish trusted certificate authorities to enable secure boot verification.
Integration with Manufacturing – Automate certificate issuance and signing during production or provisioning to embed trust from the beginning.
Auditability and Lifecycle Control – Track signed artifacts, key usage, and certificate status to support CRA conformity assessments and incident response.
The diagram below shows how EJBCA and SignServer integrate into a CI/CD pipeline to enforce these controls and provide a trusted foundation for secure boot.
To further secure the signing process itself, EJBCA and SignServer enforce strict operational controls:
Signing keys are stored and used only inside HSMs, preventing key exposure.
Signing operations are restricted to authorized workflows and times.
Attack surface is minimized, reducing the risk of unauthorized code signing.
Only trusted software and firmware are released, limiting unauthorized modifications.
All signing events are logged for auditing and compliance evidence.
Signing integrates seamlessly with existing developer tools and CI/CD pipelines.
Monitoring and alerts help detect potential key misuse or leaks before incidents occur.
Conclusions
Secure boot is not explicitly named in the EU Cyber Resilience Act (CRA), but it clearly aligns with several of the essential cybersecurity requirements outlined in Annex I. As a foundational control, it plays a critical role in protecting devices from unauthorized code execution, maintaining software integrity, and reducing attack surfaces—all of which contribute to meeting CRA obligations.
With no finalized harmonized standards available yet, manufacturers must take a proactive approach to security architecture. Implementing secure boot, backed by cryptographic trust mechanisms such as PKI and digital signing, allows organizations to begin aligning with CRA expectations today, even as regulatory details continue to evolve.
PKI and signing solutions, including EJBCA and SignServer, provide the tools needed to implement secure boot at scale across complex device ecosystems. By automating signing workflows, enforcing key protection, and maintaining auditability, these solutions help manufacturers embed trust from the first line of code to device deployment, ensuring long-term compliance readiness.
Related Content
Complementary Solution Areas and Guides
The EU CRA Requirements: Security and Compliance Across the Product Lifecycle - An engineering-focused summary of the CRA.
Implementing Secure Firmware Updates for CRA - Sign firmware and software updates to guarantee authenticity and prevent tampering in the field.
Implementing Initial Device Identities for CRA – Issue and manage identity certificates at manufacturing or first boot to establish strong device identity.
Implementing Operational Certificates for CRA – Automate the lifecycle of operational certificates to enable secure communications, access control, and encrypted services.
Implementing SSH Certificates for CRA – Replace unmanaged SSH keys with certificate-based access, enforce security policies, and enable auditability.
Contact us
Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.