A short update to the upcoming CRA

We informed about the Cyber Resielience Act already in the past. In cooperation with the BITMi we presented a couple of webinars about the upcoming regulations with regard to the CRA. In addition, you cannot only find a older blog article about The first ideas of teh CRA on our pages. Here's another short update with the most important topics.

The CRA (Cyber Resilience Act) can play a crucial role for the enhancement of cybersecurity in Europe. The EU Act is valid for product with digital elements, which by default applies to any product that contains a software. The CRA applies, similar to other Acts, a risk based approach to evaluate whether a product has to comply with higher security measures than others. Most of the software is covered by the „consumer“ side: around 80% of all software products fall under this category. As soon as critical resources, i.e. services that fall under the NIS-2 directive, are impacted by the software, the CRA applies stricter rules. The CRA is meant to regulate the access to the European market and to prevent tons of products where no security updates can be applied.

An exception to the rule above are pure OpenSource components, that do not bear any sign of making a profit (pure hobbyist projects). For other open source projects the model of stewardship will be applied: somebody has to take the ownership over the software and plan and apply the rules of the CRA to the software. There are different opinions how this stewardship will work out, but one consequence could be that each company that uses open source software in its products will automatically become a stewart for this project (like a fork of the project, but see below).

There are technical and organizational measures that companies and organizations have to meet.

The main organizational measures for CRA software includes:

Users have to be able to report security vulnerabilities, and the provider of the CRA software has to report software vulnerabilities to the national coordination center and to CVE databases within a certain amount of time. This enables customers to react promptly to possible critical exposures and eliminates the black market for vulnerabilities, where hacker can buy „unknown“ CVE for software products. Fixes for vulnerabilities have to be provided as per the next rule.
The maintenance and publication of security fixes for the period of five years for each release. The CRA mandates that these security fixes have to be applied cost-free for the users of the software. In consequence, especially companies have to take care that new features are not mixed with security fixes, because otherwise the new features will be offered for free as well. A stricter release management is the consequence.
To maintain a catalogue of used software libraries and the bill of materials (SBOM). Especially the SBOM allows the companies to search for vulnerabilities in an efficient way and will pave the path to an automated processing of vulnerabilities.
If software companies use open source software in their products, they have to take the accountability for this software as well, i.e. they have to apply bug fixes to the open source software as if it would be their own software. This guarantees that the vast ecosystem of open source components also benefits from the rules of the CRA. If companies are unable to supply a fix, they have to take other measures or remove the (buggy) open source component from their product.
The documentation of measures that have been applied in the own software stack. The documentation must be made available and the EU will use the documentation to grant the CE mark for (software) products based on this documentation. As of they writing, it is unclear what exactly the documentation has to cover and many people are waiting for the publication of the harmonized standards.

Of course, NIS-2 providers have to apply security fixes as soon as possible, based on their risk profile.

The main technical measures for CRA software includes:

The possibility to download security fixes for the own software. This step is crucial to implement, as you have to be able to react on possible shortcomings
The application of threat modeling for the (software) product. In the interconnected world of today there are many threats that have an impact on the operation of services. A threat modeling ensures that at least the most important threats are already covered and that new software products apply a bare minimum of the possible security defenses. Threat modeling usually happens on the base of attack vectors of the user, the application, the network or the physical system.
The integration and application of a Secure Software Development Lifecycle (see e.g. this OWASP SDLC article). As software is being build, the documentation for technical security measures should already be documented and applied. This not only eases the documentation of the software product, but it will ensure that authentication and authorization measures are applied early in the development. E.g. the application of „Security by Design and Default„ could ensure that default passwords have minimum length of 16 characters and that they contain special characters. The application of „Fail Safe“ ensures that system fall back into a state where no additional damages can be expected.

The consequence for companies that offer services under the NIS-2 is that they should mainly use CRA compliant software in their stack. CRA compliant software is the supply chain for their services and they ensure that vulnerabilities in the own software stack will be handled with. The CRA therefore complements the security defenses of NIS-2. If possible, NIS-2 providers should ask their software supply chain for CRA compliance already now.

Vendors have been given three years time to apply the CRA rules to their software products until the rules become mandatory. With the publication of the harmonized standards a lot things will become clearer. Nevertheless, some action can already start right away:, e.g. delivering security updates for your software is no rocket science and can already be prepared.