The EU Cyber Resilience Act (CRA) will require embedded developers to integrate security considerations throughout the product lifecycle, from design to maintenance. Noncompliance can lead to significant monetary fines.
That means a shift from reactive security measures to proactive, integrated, and lifecycle-oriented practices. The CRA was promulgated in late 2024, with full enforcement coming into effect in 2027. Enforcement means fines for violations of core cybersecurity requirements reaching up to €15 million or 2.5% of a company’s global annual revenue, whichever is higher.
For lesser transgressions, fines could reach up to €10 million or 2% of global annual revenue. In either case, customers can pursue independent legal action for damage caused by security vulnerabilities.
The CRA applies to most products with “digital elements.” Exceptions are reviewed at the end of this article. It covers software and hardware products, plus any associated remote data processing capabilities, including software or hardware components that work together but are marketed separately.
The CRA recognizes four product categories (Figure 1):
- Default are all products that meet the general requirements but don’t fit under any of the more stringent categories.
- Important Class I products are important for cybersecurity but can have limited impacts, like password managers, smart home virtual assistants, and antivirus software. They require more detailed performance assessments, but those assessments don’t need to be performed by an independent third party.
- Important Class II products pose a higher cybersecurity risk and could result in significant negative impacts on organizations or society. Examples include tamper-resistant MCUs, certain critical infrastructure elements, operating systems, container runtime systems, and firewalls. They typically require third-party compliance assessments.
- Critical products can impact broad infrastructure and critical services if they are compromised. Smart meters and associated gateways, and security systems for infrastructure protection are critical products under the CRA and require the use of a third-party auditor.
Impact on embedded developers
The CRA places significant demands on embedded developers. Security by design approaches should be implemented to proactively identify and mitigate potential vulnerabilities and security risks during the design and development phases. For example, the CRA mandates that manufacturers “implement secure boot processes verifying the integrity of software before execution.” Sensitive data must be encrypted at rest and in transit.
Security testing is expected to be a standard part of the quality assurance process. Systems and devices must be secure upon first use. An inventory of software components (software bill of materials, SBOM) must be maintained for vulnerability tracking.
A vulnerability management process must be established and maintained. If vulnerabilities arise, they must be quickly addressed. Devices must be able to receive and install security updates. Security updates must be available for a minimum of 5 years or the expected lifetime of the product.
There are numerous factors to consider when planning for CRA compliance (Figure 2):
- It can be necessary to develop a specific product roadmap for the EU market.
- Make certain that there’s sufficient expertise and staff for secure product development.
- Conduct a risk assessment for categorizing products and providing certifications as required.
- Ensure that security by design development processes are implemented for all affected products.
- Define secure default settings as the delivery state; products must be shipped with no known vulnerabilities.
- Initiate ongoing vulnerability management and reporting processes; critical vulnerabilities must be reported within 24 hours
- Prepare technical documentation and certification systems for obtaining a CE mark on all products
- Develop needed materials and communication channels for efficient and transparent communication with end users.
- Create systems needed for ensuring continuous CRA compliance
Not all inclusive
Some products are covered by other regulations and don’t lie within the scope of the CRA, like digital elements developed or modified exclusively for national security or defense purposes.
Other examples include motor vehicles and related systems and components, which are covered by EU Regulation 2019/2144. Professional medical devices covered by EU regulations 2017/745 and 2017/746. Civil aviation systems are covered by EU Regulation 2018/1139. Marine equipment is covered by EU regulations https://eewodev.wpenginepowered.com/wp-content/uploads/2014/90/EU.
Summary
The EU CRA changes almost everything related to security in embedded system development. It requires that cybersecurity and related support be baked into not only the design, but the entire product lifecycle. It delineates requirements for four product classes, requires proactive systems to nix vulnerabilities as they appear, and much more. Failure to meet CRA requirements can result in stiff monetary fines.
References
Cyber Resilience Act: Who is affected by CRA, and what needs to be done now, swissbit
Cyber Resilience Act (CRA): Step-By-Step Guide to Compliance, Yogosha
EU Cyber Resilience Act Compliance Enablement, Kiteworks
How the EU Cyber Resilience Act Will Reshape the Embedded Device Market, Prom Wad
Secure Solutions for Cyber Resilience Act (CRA) Compliance, Microchip
The Cyber Resilience Act: How Manufacturers Can Meet New EU Standards and Strengthen Product Security, Cyber Defense
The Embedded Developer’s Guide to the Cyber Resilience Act, Exein
The EU Cyber Resilience Act: Planning for Compliance, QIMA
What is the Cyber Resilience Act (CRA)?, The Embedded Kit
What to expect from EU CRA fines?, Codific
EE World related content
How does a zero trust security architecture work?
What can be done to prepare for post quantum cryptography?
How do eye & iris scan biometrics work?
Securing devices for the IoT – FIPS 140-3 and common criteria
How do AI and ML enhance SASE security?