The Cyber Resilience Act: what it means for your company

The Cyber Resilience Act: what it means for your company

The 6th episode of The Wide Open examines the Cyber Resilience Act, CRA in short. The CRA Regulation is a key component of the new cyber legislation in Europe

While regulations such as NIS2 focus on organizational resilience and security, GDPR focuses on the protection of personal data, and the recent AI Act focuses on the secure development and use of AI applications, the CRA addresses the security of products and their digital elements.

Consultants Maxim Baele and Leander Karuranga discuss what the CRA specifically entails for your organization.

09/02/2024

Full video: 38 min

In this episode of ‛The Wide Open’ podcast, Siebe De Roovere welcomes two of his cybersecurity colleagues: Senior Product Security Consultant Maxim Baele, and Governance, Risk, and Compliance Consultant Leander Karuranga, who are eager to discuss what the CRA specifically entails for your organization.

How did the CRA come about?

Excerpt #1



The regulatory landscape keeps expanding and is becoming more and complex.

The regulatory landscape keeps expanding and is becoming more and complex.

This legislation stems from Europe’s ambitious plans to achieve full digitization by 2030. The pursuit of digital independence requires not only broadband internet, 5G, and connectivity through the Internet of Things, but also a comprehensive cyber resilience framework across all sectors of society.

Why new laws?

Why is there a whole suite of new cybersecurity laws in Europe? The answer lies in the EU Cybersecurity Strategy for the Digital Decade. Europe recognizes that securing the growing digital infrastructure will not happen on its own. With cyber-attacks already occurring on a large scale, waiting for market self-regulation is not an option.

Following the success of NIS1 and GDPR, Europe decided to build on these directives and roll out regulations to ensure that European countries take the necessary precautions to secure critical infrastructure. The CRA is therefore an essential part of the broader strategy.

CRA: product security

Why address product security specifically? This stems from the growing trend of products connected to the internet. From ovens to cars connected in the Internet of Things, the landscape is becoming increasingly digitized. Europe recognizes that the security of these products is crucial to protect users from cyber-attacks and deal with the proliferation of unsafe devices.

The CRA acts as a unifying regulation across different industries. It creates a common foundation for digital security, with every sector paying attention to cybersecurity in the same way. Sectors with specific requirements, such as automotive and medical, are also addressed separately.

Security by design

Excerpt #2


Many companies struggle to address security at every stage. And to take the necessary steps.

Many companies struggle to address security at every stage. And to take the necessary steps.

The CRA focuses primarily on the implementation principle of ‘security by design’. This means that the focus on security is not limited to the end of the development process, instead taking place throughout the entire process, from start to finish. This principle is not new; it has repeatedly been integrated into various regulations, including 

  • GDPR;
  • the EU AI Act;
  • and specific regulations for industries such as automotive.

While security by design is not necessarily new, companies often struggle to implement cybersecurity initiatives at every development stage. The lack of knowledge and focus appear to be the main obstacles. Many organizations struggle when searching for the right balance between the development of features and ensuring technical depth, and are faced with a lack of specific knowledge to adequately secure products.

Technical debt

Excerpt #3



Technical debt is a kind of debt that you defer, and that will require more time to eliminate afterwards.

Technical debt is a kind of debt that you defer, and that will require more time to eliminate afterwards.

Cybersecurity must be addressed deliberately at every stage: identifying and addressing vulnerabilities later on has financial consequences.

What is technical debt? Technical debt occurs when you choose not to fix something or take a shortcut in creating a product, with the intention of fixing it later. It’s a bit like debts that you have to pay off later

Deferring security measures or adding features without addressing security right away can increase your technical debt. That’s why companies absolutely need to focus sufficiently on their technical debt, especially start-ups that are testing whether there is market interest as part of the MVP (Minimum Viable Product) phase. 

Should you deliver a perfectly polished product straight away? Absolutely not, but it’s important that basic security measures are in place.

The 3 key requirements of the Cyber Resilience Act

Excerpt #4

The SBOM requires additional governance but, in the right circumstances, you can accelerate your business growth.

The SBOM requires additional governance but, in the right circumstances, you can accelerate your business growth.

The CRA contains 3 key points or requirements that organizations must meet:

  • Reporting obligation

One of the CRA requirements is the reporting obligation. Organizations are required to immediately notify ENISA (European Union Agency for Cybersecurity) and their local CSIRT (Cybersecurity Incident Response Team) when a vulnerability seriously impacts the security of their products.

But when exactly should an organization report? The CRA mentions a ‘serious impact’, which goes beyond just vulnerabilities in the product itself. Even if a cyber-attack does not have a direct impact on the products, it still needs to be reported. This highlights the importance of proactive communication in the case of cyber incidents.

  • Vulnerability handling

The method used to handle vulnerabilities is another key aspect of the CRA. Vulnerability handling means that organizations need to proactively look for vulnerabilities, fix them within a reasonable time frame and send updates to users in a secure manner. 

While the regulations do not set hard deadlines, they encourage the ‘comply or explain’ principle. Organizations must have a clear policy and be able to implement it.

  • Technical documentation

The CRA’s third requirement focuses on documentation, with an emphasis on technical documentation that clarifies the requirements and makes them more visible to suppliers and stakeholders

To what end? The aim is to provide users with greater transparency and insight about the security of your product. This includes risk assessments and information about the frequency and speed of updates.

Software Bill of Materials (SBOM)

This technical documentation is the basis for the SBOM. It makes the software components and their versions more transparent. Actually, the best comparison would be a kind of ingredients list for your software.

The SBOM doesn’t just contribute to transparency; it also speeds up the response to security issues. By creating a detailed SBOM in advance, developers and security teams can respond to threats faster. And improve the overall security of the product.

CRA and OWASP SAMM

The relationship between the CRA and the OWASP SAMM framework – a useful tool to help companies comply with the rules – is an interesting aspect. Implementing OWASP SAMM facilitates CRA compatibility, with many best practices overlapping.

How to ensure compliance as an organization

Excerpt #5



Many companies wouldn’t know what to do if an ethical hacker finds a vulnerability.

Many companies wouldn’t know what to do if an ethical hacker finds a vulnerability.

As the Cyber Resilience Act (CRA) Regulation presents new challenges for organizations, being well prepared is crucial. If we zoom out from the CRA, it becomes clear that several IT governance aspects need to be addressed. These include processes, notifications and more.

How does an organization ensure compliance with the CRA? A first step is to assign responsibilities. In smaller companies, this could be a systems architect, lead developer, or even the CTO. In larger organizations, the function of product security architect or manager is now commonplace.

This person should not only be technically savvy, but also proficient at drafting policies. While finding this profile may prove challenging, it can also be developed within the organization. We often see someone who works with the product on a daily basis taking on this role, acting as a kind of security champion within the development team. 

More from The Wide Open

Written by Laurent DupontThe CRA promotes innovation and cybersecurity in European digital products. Learn how your company can comply with applicable standards.

Written by Laurent DupontIn the fifth episode of The Wide Open, we welcome two experts, Jasper Hooft and Thomas Dejagere, who delve deeper into the…

Written by Süleyman YilmazA CISO is the last line of defence to protect your assets. What’s the CISO’s role? And what makes a good CISO?

Written by Süleyman YilmazTech companies go through 3 stages. Which cybersecurity issues do they face at each stage? We cover it all on this edition…

Written by Süleyman YilmazPlanning to develop your own application? You might want to consider the many possible pitfalls. We explain them in this article.

Written by Süleyman YilmazWant to integrate a cloud solution without a strategy? That’s risky. Check out what you need to do to grow your business…

Do you have a specific question about the CRA?

Contact us, our security experts would be happy to assist you.

Do you have a specific question about the CRA?

Contact us, our security experts would be happy to assist you.

Start typing and press Enter to search

Shopping Cart