1 December, 2025
The upcoming Cyber Resilience Act (CRA) is a EU regulation that was published on November 20, 2024. The regulation sets a security baseline for every product with digital elements. More importantly, software is largely within scope for the CRA and non-compliance might result in huge fines. The key question is obviously how to prepare for the CRA.
Unfortunately compliance with the CRA is not a button click. Neither is it a legal document you can file and forget, just as you did with the GDPR. Real compliance requires security baked into your SDLC. That is a monumental effort and the time to start was when you started developing your product.
In this blog, I will give you a brief overview of the CRA. The core of the article explains how OWASP SAMM can help you prepare for the CRA.
Key takeaways
- CRA compliance requires a systematic approach to developing software systems with security baked in.
- Existing standards like the ISO27001 might help you, but they are nowhere near real application security.
- OWASP SAMM provides a proven methodology to a systematic approach to application security.
- Codific’s SAMMY tool offers a manageable way to implement SAMM across all your products with digital elements.
What is the EU Cyber Resilience Act?
In layman terms, the EU Cyber Resilience Act (CRA) is a regulation that mandates every product with digital elements sold in the EU to meet a minimum level of security throughout its entire lifecycle. The CRA covers both hardware and software products and their remote data processing solutions. The goal of CRA is simple: make sure products are secure. The CRA becomes fully applicable on 11th of December 2027.
CRA is the extension of the existing CE label that already appears on many products. The CE label tells consumers that a product meets safety and health requirements. The CRA works in a similar way, but for cybersecurity. If a company wants to sell a smart device, a connected tool, or a piece of software in the EU, it must prove that it meets these security expectations before it reaches the market.
Despite the simple goal, defining what is secure is a really challenging task.
The CRA scope
All products with digital elements are within scope for the CRA. A product with digital elements includes software and hardware products and their remote data processing solutions.
Examples of products in scope for the CRA
Let us look at some examples of products in scope for the CRA.
Any smart appliance like a smart TV, smart fridge, smart scales, video cameras all of that fall in scope for CRA. The platforms where they send their data to are also covered by the CRA. Note that some of these platforms, such as video surveillance platforms fall in scope for a more stringent regulation, namely NIS 2.
Microsoft Office software and any other software package that you buy in the store or online to run on your machine all fall under the CRA as well. However online versions of these applications that you view through your browser do not. So there are two notable exceptions when it comes to what is outside the scope of CRA.
SaaS is exempt from CRA
Software as a Service (SaaS) is exempt from the CRA. So anything that you access as a software product via your browser is not within scope. So Microsoft Office that I’ve mentioned earlier running in the cloud (Office 365) is exempt from the CRA.
The browser itself (e.g., Safari, Chrome, Firefox) is within the scope of the CRA. In fact, they fall under a more special category called “Important products with digital elements”.
However the moment your SaaS lands in an on-prem setting it is again subject to the CRA. The same goes for all mobile applications.
Open source software is sort of exempt from CRA
The CRA keeps all community open source products outside its scope. So volunteers who build open source projects do not need to comply. Think of the VLC player for instance. Developers who contribute to VLC do not have to make it compliant with the CRA.
If a company decides to commercialize an open source product, the CRA applies fully. Think of Red Hat for instance. The responsibility shifts to the company that places the open source based product on the market. The company must provide secure development, vulnerability handling, long term support, and all the documentation that the CRA requires.
Unfortunately most commercial software today contains more than 90% open source components. This creates real friction. Companies must guarantee the security and maintenance of components they did not write, do not control, and often cannot influence. Many open source libraries receive irregular updates. Some have a single volunteer maintainer. Others become abandoned without warning. The CRA expects commercial vendors to take full responsibility for these dependencies, even when upstream projects move slowly or stop entirely. This gap between legal obligation and practical control shows how little the legislators understand the open source ecosystem. But let us park that topic.
Application security definition in the context of CRA
The CRA mentions the word risk. In fact, CRA mentions the word risk 178 times! And yes, risk is a key concern when I am talking about security. However measuring risk in the context of software products is a notoriously challenging concept. So aside from mentioning risk the CRA provides some details as to what areas of application security should one focus on in order to be “compliant” with the CRA. Here is a non-exhaustive list of those concern areas:
- Risk management including both business and technical aspects
- Privacy and data minimization
- Secure design and secure development
- Vulnerability management and SBOMS
- Secure default configurations
- Long-term support plan including patching and updating
- Documentation and vulnerability disclosure process
- Logging and incident management
OWASP SAMM in the context of CRA
Fortunately, SAMM solved the puzzle pieces behind the CRA long before the regulation appeared. SAMM has existed for more than fifteen years and brings together more than a century of combined security expertise, which is longer than the EU itself has existed. If anyone knows how to approach real application security challenges, it is the SAMM community.
OWASP SAMM is a maturity model that helps organizations evaluate and iteratively improve their application security posture based on risk. SAMM comes with 90 security activities that cover the complete domain of application security and secure software development lifecycle. Each of these activities is measurable and SAMM provides actionable guidance on how to improve.
SAMM is also agnostic towards development methodology, technology, organization size and industry. So you can use SAMM to prepare for the CRA whether you are developing a mobile application, a smart fridge or the next amphibian swimming, driving and flying vehicle.
Hence, SAMM provides a complete answer to how to develop software products securely by taking into account risk.
How to use SAMM to prepare for the CRA
Prepare: set the scope
Preparing for a SAMM assessment requires you to select a scope for the assessment. That could be your complete organization, a specific line of business or a team, or a specific product. In the context of the CRA I would recommend you to start with the scope of a specific product.
Assess
If you can’t measure it, you can’t improve it. The next step in SAMM is running an assessment. The assessment involves answering 90 SAMM questions that will allow you to get a clear picture where you currently are.
Set the target
This is perhaps the hardest part of your SAMM journey. Especially when we bring in the context of the CRA. So the question is what is good enough to be ready for the CRA. Luckily, the SAMM core team has created a draft mapping between SAMM and the CRA. Here is an overview of the SAMM scores that are likely to provide you with a CRA ready security posture.
You can find the full target posture in the SAMMY tool. Based on this version remarkably, only a few areas of security are not relevant in the context of the CRA:
- Security champions programs are not really mentioned in the CRA. However this is an area that is likely to help you scale your application security program and hereby grow faster.
- Training and awareness is not explicitly mentioned, though it is obvious that without training and awareness you are unlikely to get there.
- Metrics and feedback in the context of implementation.
Plan and implement the improvements
Once you know your target scores, you can plan the improvements that move you toward a CRA ready posture. The right actions depend on your current maturity and your organizational reality. Based on my experience in conducting 50+ SAMM assessments I strongly believe the following areas will need focus as they are typically lacking in most organizations we’ve seen.
- Application risk and threat modeling
- Security requirements
- Dependency management process
In any case you should create a focused improvement plan that closes the gap between your current state and the target you selected. Then implement these changes in small, steady steps to build a sustainable and CRA aligned application security practice.
Conclusion
SAMM gives you a strong foundation for CRA readiness, but it does not cover everything. The CRA also expects clear documentation, structured communication, and well defined product information for users and authorities. These activities sit outside the scope of SAMM. They focus more on compliance hygiene than on technical security maturity. But it is my strong belief that the remaining compliance tasks are more administrative. You can handle them once the core of your engineering practice is strong.
