Updated: 20 December, 2024
5 September, 2024
It this article we explore the essentials of the EU Cyber Resilience Act (CRA), and dive into the details of what is required in this legislation and how organizations can demonstrate compliance.
The essentials of the Cyber Resilience Act (CRA).
What does CRA stand for?
CRA stands for Cyber Resilience Act.
What is the EU Cyber Resilience Act?
The Cyber Resilience Act is a EU regulation that aspires to achieve a minimal level of cybersecurity in all products with a digital component sold within the European Union. It does this by broadly requiring three things:
- Cyber Security Requirements.
- Vulnerability Handling Requirements
- Communication Requirements
When will the EU Cyber Resilience Act come into force?
The CRA regulation comes into force in the fall of 2024, around the time of publication of this article. There is a transition period to allow the industry to time to comply with the regulation. The reporting obligations will start in the fall of 2025, 12 months after the regulation entered into force. The bulk of the obligations become applicable in the fall of 2026, 24 months after the regulation came into force.
How to demonstrate compliance with the EU Cyber Resilience Act ?
It is up to the companies themselves to collect the evidence to demonstrate compliance. For the communication requirements the communication is the evidence in itself. For the cybersecurity and process oriented requirement companies have to demonstrate that they have the relevant processes in place. A good inventory of the security processes is important in order to manage for CRA compliance. AppSec programmes and maturity models such as OWASP SAMM can help structure the effort, create visibility and provide the relevant documentation.
A deep dive into complying with the Cyber Resilience Act
Risk of non compliance:
At the time of this talk the CRA (EU Cyber Resilience Act) will have been recently put into force. It applies to all products that have a digital element sold in the European Union. Other than NIS-2 (Network and Information Security Directive, ref. 2022/2555) it applies to all companies large and small. The regulation foresees a transition period that has just started (at the time of Blackhat Europe). The clock is ticking. There are about 10 months left for the reporting obligations to come into effect and 22 months for the whole regulation to be applicable.
Companies that don’t comply can be:
Fined up to €15 million for smaller companies, and up to 2.5% of turnover for larger companies. This could for example be a fine up to €8 billion for Apple or a fine up to €15 million for your local software shop. And there are 27 actors that can issue these fines (one per country).
If a product poses a significant cybersecurity risk, companies can be forced to recall or even entirely withdraw products from the market. The last say on product withdrawals lies with the European Commission.
This sweeping scope and huge fines have likened the CRA regulation to the GDPR (General Data Protection Regulation ref: 2016/679 ) regulation of a few years ago. Some call it the GDPR of cybersecurity. However compliance with CRA may prove to be harder and more ambiguous than it is for GDPR. GDPR asked for “relevant technical and organizational measures” which left space for companies to argue what these are. CRA defines a specific list of measures, processes and outcomes and states that decisions should be risk based. This implies a necessary set of organizational processes which is much wider than what was needed for GDPR.
So what is required?
The obligations of CRA are categorized into three buckets.
- Cybersecurity Requirements
- Vulnerability Handling Requirements
- Communication Requirements
Arguably the vulnerability handling requirements are really a combination of security process requirements and communication requirements. However as it is its own category in the legal text we shall treat it as such.
Products are also categorized into three buckets for whom the rules apply
- Critical Products Class 2 (highest)
- Critical Products Class 1 (lower)
- All other product with digital elements
Class 1 and Class 2 are explicitly defined in a list that may be updated in the future by the Commission. Everything not explicitly listed falls outside of the Class 1 and Class 2. But the main differences between classified and non classified products is in the way compliance should be demonstrated, and how stringent the process is.
It is up to the companies to demonstrate compliance.
The way this can be done builds on EU Decision 2008/768 on a common framework for marketing of products. Specifically there are 4 ways this can be done.
- Method A: Internal Control
- Method B: External Certification
- Method C: External Certification + Internal Control
- Method H: Full Certified Quality Control System
Method A is only allowed for non categorized products. Categorized products can choose to do B+C or H. Class 2 categorized products must always include a third party in the assessments.
In all cases the company will need to present evidence that It complies with the regulation.
Some requirements are clear, for example “deliver products without any known exploitable vulnerabilities”. But others are less specific, for example “be designed, developed and produced to limit attack surfaces, including external interfaces”. The question is how much should we be limiting the attack surface? Just a little or a lot? What is enough? The regulation specifically states that such decisions should be risk based and well documented.
So we need to first establish a target security posture based on the context and risk of the specific product or product group. By doing this we establish how high we need to set the bar on each of the required outcomes and processes. By setting such product specific internal goals before demonstrating compliance we provide a solid foundation for a well documented risk based approach. We first set the bar, and then jump over it.
The expensive way.
We can go through all the requirements in an exhaustive fashion, establish a kind of risk-based checklist for the specific product or product group, and then evaluate if we have met all criteria. Where things are lacking, new processes would be set up. This compliance-driven approach is not uncommon, especially in smaller organizations. However, it can lead to a fragmented security program and the absence of a holistic security strategy. Essentially, it becomes another compliance checklist filled out predominantly by the compliance team, driving up bureaucratic costs and creating sprawling measures and processes.
If done in good faith, this approach can have some positive impact. For example, obligations to measure and report on vulnerabilities and provide SBOMs (Software Bill of Materials) will force many companies to implement some form of SCA (Software Composition Analysis). However, other issues may be difficult to resolve using a checklist-based method without an adequate security program in place. For instance, addressing a vulnerable dependency might require compensating controls or substantial effort to switch to another library. Without the right people and processes, the checklist alone isn’t going to achieve much.
The security driven approach with maturity models.
The purpose of a good security programme is good security, and easy compliance should be a byproduct. CRA is on many aspects process oriented in:
- requiring specific security related processes, for example, the required vulnerability handling processes, and
- implicitly requiring processes, by for example requiring well documented risk profiles, and subsequent actions based on these profiles.
How well established are processes on these different activities? How well documented are these processes? Are they consistent across the different product teams? These are all questions companies will have to answer in the coming months. The more mature companies will have well documented and inventoried processes. The organizations that are best of class have this inventory structured in industry standard maturity models such as OWASP (Open Worldwide Application Security Project) SAMM (Software Assurance Maturity Model), BSIMM (Building Security in Maturity Model), OWASP DSOMM (DevSecOps Maturity Model) or NIST (National Institute for Standards and Technology) CSF (Cyber Security Framework).
Starting from a process maturity model has several advantages. Maturity models allow companies to map out their processes and develop a continuous process improvement cycle. Implementing strategic choices about investments in process improvements with a holistic overview.
The maturity model is the structured backbone of the security programme which is fleshed out with good documentation on all processes in place, and roadmaps of process improvements. This allows for a truly security driven approach, where decisions are made primarily for their security value.
Having all processes inventoried and documented makes demonstrating compliance relatively easy. It is a question of collecting the evidence from the existing structure and transforming it into the structure of the case of the CRA legislation. Of course we only have to do this mapping once and then share it with the community.
Industry mapping efforts
With the explosion of regulatory requirements and the rise of maturity models in recent years there has been significant progress in community mappings in the recent years. For example OWASP has worked together with NIST to provide a NIST approved mapping from OWASP SAMM to NIST SSDF (Secure Software Development Framework), an important requirement for companies supplying federal institutions in the USA (Executive order memorandum M-22-18).
There is the OWASP Integration Standards Project with Open CRE that provides mappings between a wide range of frameworks.
Mapping CRA to OWASP SAMM
At the time of this writing we have a provisional mapping of the security requirements in CRA to OWASP SAMM. By December 2024 this mapping will be reviewed and updated by a series of experts and validated by OWASP. It is our intention to have the mapping also validated by ENISA, similar like we did with SAMM to SSDF mapping, which was validated by NIST.
You can find the current version of the mapping here.
So what does that look like?
By mapping the requirement of CRA to OWASP SAMM we identify the maturity level needed on each one of these processes. Having this maturity level will of course not guarantee compliance with CRA. It will provide an indication of having the right processes in place to be able to comply with CRA. These processes still need the correct inputs, such as security requirements and security principles as outlined in the legislation. This overview covers the technical and process readiness for CRA, not the communication requirements.
Having this CRA-ready security posture would facilitate compliance by having all the processes in place and well documented. This makes the communication requirements easy to comply with, as the information can easily be collected and communication triggers defined.
In all methods of compliance demonstration (A, B, C and H), the companies are responsible for presenting the documentation demonstrating compliance.
SAMM provides a structured overview of the processes in place, an effective way to identify gaps and a structured way to demonstrate compliance.
The minimal security posture to be CRA ready
The minimal security posture per business function
So is the industry ready?
No it is not. At first glance the required overall maturity level is 1.55 whereas the OWASP SAMM industry Benchmark is at 1.42. And this benchmark is largely made up by large multinational companies. Smaller companies tend to have less mature processes. And if we dig deeper on the security practice level the gaps become even more prevalent.
Requirement Driven Testing is at 1.05 in the industry and needs to be at 2.13 to be CRA ready.
In Architecture Assessment the industry is at 1.06 and needs to get to 2.
For other practices, such Security Architecture and Security Requirements, the industry seems to be well positioned to comply with CRA.
Conclusion
CRA is upon us and it comes with a large stick to enforce compliance. We don’t yet know how readily the stick will be used. If GDPR is to be a reference point then the stick will be used. As of mid 2024 4.48 Billion Euros in GDPR fines have been issued. CRA could be worse, much worse. In part because it is up to companies to demonstrate compliance, and that will be harder and more ambiguous than demonstrating compliance with GDPR. Security Maturity models help us to list the processes at organizations and analyze where these processes are lacking. In this research we mapped the security requirements of CRA to OWASP SAMM and presented a target posture to be CRA ready. The industry is not at this level yet, but there is still time. The clock ticks, and the SBOMs are coming.
List of relevant regulations:
Regulation (EC) No 765/2008 CE marking
Decision 768/2008/EC Common framework on marketing of products (defines methodology of conformity checks in CRA annex 6, things called module A and Module B)
Directive 2014/53/EU. (RED) Radio Equipment Directive
Regulation (EU) 2016/679 GDPR (complementary relationship to CRA)
Directive (EU) 2016/1148 (original) NIS Directive
Regulation (EU) 2017/745 Medical Device regulation (has priority over CRA)
Regulation 2018/1139 Civil Aviation (has priority over CRA)
Regulation (EU) 2019/881 EU cybersecurity act (ENISA and certifications)
Regulation (EU) 2019/2144 Motor Vehicles (Combines in certification)
Regulation (EU) 2022/30 Wireless devices (updated RED)
REGULATION (EU) 2022/2554 DORA
Directive (EU) 2022/2555 NIS2
Regulation (EU) 2023/1230 Machinery directive (combines in certification)
Regulation (EU) 2024/1689 AI Act (partial overlap)
