CRA compliance for electronics manufacturers: how SBOM, Secure Boot, and root of trust ensure EU market access
Connected electronic products must remain secure and updatable throughout their entire lifecycle. The EU’s Cyber Resilience Act requires manufacturers to incorporate cybersecurity into development, production, and maintenance. Automated SBOMs, Secure Boot, and hardware root of trust provide transparency for that, protect firmware integrity, and secure updates. However, what matters is not just formally meeting individual requirements but also establishing from the outset a robust security architecture that can be automated and verified.
Why CRA and the digital product passport should be considered together
In the future, connected products will not only need to be secure in the future, but also have accompanying documentation that is technically comprehensible. For example, the Cyber Resilience Act (CRA) requires manufacturers to integrate cybersecurity across all stages of the value chain: from planning and development, to production and product maintenance. That applies to all products with digital elements (PDE), as they are referred to. These include both connected hardware products and pure software products.
To comply with the relevant documentation requirements, companies can use the digital product passport (DPP). It provides a structured data foundation for product-related information along the entire value chain and consolidates information, for example, on materials, repairability, and recyclability, to make products transparent and traceable.
The real challenge for companies going forward will be to translate CRA compliance into robust technical formats. As a result, the simple obligation to provide evidence creates a solid basis for secure, updatable, and trustworthy products.
What does the CRA mean for manufacturers of electronic products?
The CRA requires manufacturers to incorporate cybersecurity as a technical product feature throughout the entire product lifecycle. Products with digital elements must be designed and manufactured in a way that systematically reduces risks. Examples of the obligation to provide evidence include:
- A documented risk analysis
- Secure default configurations
- Protection against unauthorized access
- Software and data integrity
- Mechanisms for security updates and vulnerability management
CRA compliance will also become part of the CE-related documentation for affected products. That means companies must, for example, document security requirements in a verifiable manner, integrate them into development processes, and maintain them throughout the product’s expected service life. The scope of the CRA is quite broad.
According to the BSI, the CRA includes products that can be connected directly or indirectly to devices or networks. The CRA therefore applies both to connected hardware products such as smartphones, laptops, microprocessors, firewalls, and smart meter gateways, as well as to pure software products such as accounting software or computer games.
Why should companies maintain an SBOM?
Transparency regarding the software used is one of the requirements for CRA compliance. Manufacturers need to know which components, libraries, and dependencies there are in each product. That is exactly what a software bill of materials is intended for. According to ZVEI, an SBOM is a formal, ideally machine-readable data set that provides an inventory of the software components contained in a product. Among other things, it contains information on:
- Component name
- Version
- Author
- Dependencies
The SBOM provides transparency in the software supply chain and helps manufacturers check more quickly whether a product is affected when vulnerability reports are issued. Developers should therefore display changes to the actual software promptly in the SBOM.
The BSI TR-03183-2 guideline, among others, is helpful when creating and evaluating an SBOM. It describes how it should be structured to serve as verifiable evidence of software transparency, and provides specifications for minimum formal and technical information on, for example, components, versions, and machine-readable formats.
However, this transparency is only one part of CRA compliance. In addition, manufacturers must ensure that only authorized and unmodified software is executed in the product. This is where Secure Boot and the hardware root of trust come in.
What are Secure Boot and hardware root of trust?
Secure Boot ensures that a device executes only verified and unmodified software during startup. To that end, the code is cryptographically validated before it is loaded. The hardware root of trust forms the secure starting point of this chain of trust: It is the first element in the system that is trusted, and serves as the basis for all subsequent verifications.
This is relevant for CRA compliance, as manufacturers must demonstrate that firmware integrity, device identity, and secure updates are technically secured. Depending on the platform, different features can be used for that purpose, for example:
- Trusted Platform Module (TPM)
- Secure Element
- TrustZone
- Physical Unclonable Function (PUF)
- MCU integrated security features
Signed firmware images, robust key management, rollback protection, hardened debug interfaces, and validated OTA updates are also important.
Why an architectural decision instead of a compliance checklist?
SBOM, Secure Boot, and hardware root of trust serve different purposes within CRA compliance. The SBOM provides transparency regarding software components, versions, and dependencies. Secure Boot and hardware root of trust take a different approach: They protect the product itself and technically secure device identity, firmware integrity, and updatable product architectures. CRA compliance can only be reliable throughout the entire product lifecycle when companies take both levels into account: a transparent software supply chain and a secure device architecture.
To ensure that these two levels work together, development, system architecture, procurement, quality assurance, and technical project management should define common standards early on: which components are used, how keys are managed, what information suppliers need to provide, and how releases are documented. Instead of being checked only right at the end of the project, CRA compliance is therefore incorporated into product design, the development process, and the supply chain from the outset.
What does CRA mean for the electronics industry?
For the electronics industry, thorough CRA readiness is increasingly becoming a distinguishing feature. Companies that automate the management of firmware, vulnerability information, and evidence reduce their audit effort and strengthen trust in their connected products. The CRA addresses this product responsibility across the entire lifecycle and makes cybersecurity a verifiable component of marketability.
For manufacturers, developers, and system architects, electronica offers the right industry context. As the world’s leading electronics trade fair, it covers the entire range of modern electronics and brings together components, systems, software, and application markets.
Anyone who wants to dive deeper into topics related to CRA, cybersecurity, embedded and IoT security, can get extensive information at electronica in technical presentations, panel discussions, and expert forums, such as the Cyber Security Forum or the Embedded Systems Forum, and talk with the leading experts in the industry.