Just before Christmas, I was on a call with an FAE about some SoCs we were interested in for an upcoming space project. At the end of the call, they asked me if I had heard of the new EU Cyber Resilience Act (CRA) and what impact I thought it might have on the world of FPGA and embedded systems.
To be honest, while I was aware of the CRA, many of our applications are already covered by existing regulations, so it is not something that I had looked too much into. However, following this conversation, I sat down and read the Cyber Resilience Act. This brought back memories of when I was designing high-grade cryptos and the lengths we went to ensure they were secure — plus all the associated testing, such as TEMPEST. (For those unfamiliar, TEMPEST refers to measures ensuring that electronic devices do not emit signals that could compromise their security.) This remains one of the most nerve-wracking testing processes I’ve experienced.
Introduction to the Cyber Resilience Act
The Cyber Resilience Act was passed by the EU Parliament in October 2024. This new law aims to establish cybersecurity requirements for products that contain digital elements when sold in the EU market. As the CRA becomes enforced, manufacturers must demonstrate compliance with the CRA to obtain CE marking certification.
The key requirements of the CRA
- Security by design: Manufacturers must demonstrate they have considered threats and cyber security features in the design.
- Transparency: Mandatory to document the cyber security features which have been implemented within the solution.
Note: The CRA is not a “one size fits all” regulation. Different applications/products have varying budgets and scopes for cybersecurity assessments.
Applicability classifications
The CRA applies not only to final product vendors but also to component manufacturers, such as microcontroller and FPGA manufacturers. They must provide documentation on security measures and risk assessments and implement security controls throughout the manufacturing chain. Products sold in the EU are classified into three categories:
Default
- Expected scope: 90% of product
- Certification: Self-certified.
- Examples: Smart home appliances, printers
Important
- Class 1: Self-certified if using CRA-defined standards or certifications
- Examples: Operating systems, network management systems
- Class 2: Requires third-party conformity assessment
- Examples: Hypervisors, firewalls, tamper-resistant microprocessors
Critical class
- Scope: Products presenting the highest risk
- Certification: European Common Criteria Cybersecurity Certification
- Examples: Smart meter gateways, secure crypto processing, hardware security boxes
What this means is that for each product developers will need to consider the potential threats, and what counter measures can be implemented within the design. As such products are going to need some security engineering up front along with the systems engineering phase.
For some products this will lead to some very interesting engineering and testing to ensure compliance. This may include, encryption, root of trust, hardware design techniques to reduce accessibility of signals on the board if physical access is a threat mode.
Exemptions from CRA
Several exemptions exist, including:
1. Products with sector-specific regulations: These include medical, automotive, aviation, and military/defence products.
2. Open Source Software (OSS): OSS is exempt unless used in a commercial product. However, this raises questions about accountability for mixed-use scenarios.
3. Products for internal use only: These are not placed on the EU market.
4. Standalone products: Products not connected to a network are exempt as they pose no cybersecurity threat.
Implications for developers and manufacturers
One of the more interesting aspects of the CRA is the requirement for on going surveillance and monitoring and reporting of vulnerabilities. Failure to do this to the appropriate agency can have significant impacts both criminally and financially for the company.
Developers will need to:
- Proactively consider security engineering during systems design phases.
- Implement measures such as encryption, root of trust, and hardware techniques to minimize accessibility of signals on boards. (Particularly important if physical access is a potential threat.)
Manufacturers are required to:
- Offer security updates as vulnerabilities are discovered.
- Maintain ongoing surveillance, monitoring, and reporting of vulnerabilities to appropriate agencies.
- Understand that failure to comply with surveillance and reporting requirements could lead to criminal and financial penalties.
Looking forward
Over the next few years, we will see how the CRA shapes practices for component manufacturers and product developers. For engineers, security will become as integral to system design as other considerations, such as performance or cost. Documenting decisions around security will be essential to meet the transparency requirements of the Act.
Excitingly, this could lead to more penetration testing and countermeasure validation during development, adding an extra layer of rigor to engineering practices.
Hopefully, this act will result in more secure components and solutions while setting a precedent for global cybersecurity standards.
As always, engineering evolves with new challenges, and the CRA represents an opportunity to design systems that are not just functional but also resilient in an increasingly connected world. I also expect the CRA may lead to other regions introducing similar laws.
