The Cyber Resilience Act (CRA) was adopted by the European Council on October 10, 2024. It was then published in the Official journal of the EU on November 20, 2024 and enters into force today, December 10, 2024. Most of the law will start applying in 3 years, on December 11, 2027.

However, the obligation for manufacturers to report any actively exploited vulnerability or any security incident impacting the security of their product to ENISA will apply from September 11, 2026.
The other parts of the law that will start applying from June 11, 2026 apply to the member states and specify the details of setting up the administrative entities that will assess conformity with the CRA.

At Bootlin, we have been paying close attention to this topic for several reasons. First, the CRA will affect a large number of our clients, as almost every embedded device sold in the EU will need to comply with it. Second, the CRA also affects us directly, for instance as the maintainer of Snagboot.

This post is therefore the first in a series that will present our understanding of the CRA, and clearly lay out what one needs to have in mind in order to be confident of one’s compliance on time.

Am I directly impacted by the CRA?

In short, if you are one of the entities in the chain of electronic hardware with some type of connectivity or software being designed, written/manufactured, marketed, rented/sold or even provided for free in the context of a commercial activity in the European Union, then yes, you are very likely directly impacted by the CRA in some capacity. We’ll see how in this series of posts.

Page 9:

The proposed Regulation will apply to all products with digital elements whose intended and reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

The CRA is concerned with:

• products with digital elements, so a typewriter wouldn’t be impacted
• that have some type of connectivity (network, bluetooth, but also USB or other cables), so a “dumb” electronic watch shouldn’t be impacted
• being placed onto the internal EU market: if you build your own keyboard but don’t sell it or only outside of the EU, you need not worry about the CRA.

Large classes of devices are excluded from the CRA, because they are covered by other regulations:

• Medical devices for human use are covered in 2017/745 and 2017/746
• Motor vehicles and their trailers/ systems need to comply with 2019/2144
• Civil aviation systems are the object of 2018/1139
• National security, military and classified information systems are exempt from the CRA as long as they exclusively target these applications

Although the term “product” evokes hardware, the text of the CRA makes it very clear that it is intended to apply to both hardware and software.

As outlined in the regulation, it does not apply to Cloud services (SaaS) in general. However, it does apply to such services that are integral to the product functioning:

It does not regulate services, such as Software-as-a-Service (SaaS), except for remote data processing solutions relating to a product with digital elements understood as any data processing at a distance for which the software is designed and developed by the manufacturer of the product concerned or under the responsibility of that manufacturer, and the absence of which would prevent such a product with digital elements from performing one of its functions.

An exemption is explicitly provisioned for presentation and use in “trade fairs, exhibitions and demonstrations or similar events“, as well as for unfinished software, as long as it is:

• only available for required testing for a limited time
• clearly marked as such and as non-compliant with the CRA

Stricter obligations apply to the following products:

• important products as defined in Annex III
  Class I of this category applies to a rather large list, including routers, switches, VPNs, SIEMs, antivirus software, smart home assistants, door locks, security cameras, OSes, bootloaders, password managers, microprocessors – microcontrollers – ASICs – FPGAs with security-related functionalities, network interfaces, toys that record voice or video or have location tracking, and wearable devices with health monitoring or used by children
  Class II includes hypervisors, container runtime systems, firewalls, IPS, IDS and tamper-resistant micoprocessors and microcontrollers.
• critical products as defined in Annex IV:
• Hardware Devices with Security Boxes, which is a technical domain defined in the EUCC and refers to systems where “security relies on a physical envelope […] that is designed to resist direct attacks, e.g. payment terminals, tachograph vehicle units, smart meters, access control terminals and Hardware Security Modules”
• Smart meter gateways
• smartcards and devices with secure elements
• high-risk AI systems as defined in Article 6 of the AI Regulation

These systems will need to go through external assessment, depending on the exact category in which they fit.

What do I need to do and when?

The CRA applies to products as soon as they are placed on the EU market, meaning that compliance to the CRA should be part of the launch plan. Several provisions of the law apply to the design phase, and writing the documents that will be necessary for compliance will be easier to do as design advances than all at the end. The law is intended to have impact on technical design decisions made in the implementation of the product.

Ideally, design decisions and tests will be documented throughout  design and implementation then be compiled into the technical documentation that must be provided when the product launches.

The content and timeline of tasks and requirements depends on the role one fulfills out of the ones detailed below and in the CRA’s Article 3. The very first step in knowing what one needs to do to comply with the CRA is therefore to determine what role one does or will fulfill for every product.

• Manufacturer: either the actual developer/manufacturer of the product, or the person/entity marketing it
• Authorized representative: person or entity within the EU who received a written mandate to act on behalf of the manufacturer
• Importer: if the manufacturer is outside of the EU, that is the entity placing the product on the market
• Distributor: entity other than manufacturer or importer who places the product on the market
• Open-Source software steward: entity systematically contributing to or supporting specific open-source software intended for commercial activity

Obligations apply at several stages. Initial obligations apply from the conception stage, from the moment the product is being designed. These initial obligations mostly consist of:

• Taking security into account when designing and implementing the product
• Documenting the risks that were taken into account and their mitigations
• Preparing for the continuous obligations by designing the processes that will be used e.g. for responsibly handling vulnerabilities in the product

The continuous obligations apply starting when the product is placed on the market throughout its lifetime, and refer to a concept known as the support period, which will be detailed in the later post for manufacturers. In short, they require:

• Updating the documentation produced to meet the initial obligations
• Making that documentation available to users and authorities
• Responsibly handling vulnerabilities
• Reporting vulnerabilities known to be exploited as well as security incidents

The last stage is when the entity behind the product stops operating. The final obligation is to make authorities and users aware of this cessation of operations.

This is a broad overview, and there is of course more to discuss, which is why subsequent posts in this series (stay tuned!) will go into the details for manufacturers, who bear most of the responsibilities, and for open-source software stewards, as they are a slightly special case, and one whose criteria Bootlin and many in the embedded community fit.
This post will still go into reporting obligations, as they apply broadly, and will be the first to apply outside of conformity assessment bodies (not exactly the target audience of this series), in September 2026.

Reporting – ENISA and users

Starting September 11, 2026, all roles in the CRA are, under certain conditions for importers, distributors and representatives and always for manufacturers and open-source stewards, under obligation to report:

• any vulnerability in the software that is known to be exploited
•  severe incidents that impact the security of the software

Both must be reported to the single reporting platform that ENISA has been charged with creating in Article 16.
This single reporting platform mentioned above does not exist yet. It is the responsibility of ENISA, and should ultimately have one endpoint for each member state’s Computer Security Incident Response Team (CSIRT).
The list of those CSIRTs should theoretically be available at https://csirtsnetwork.eu/homepage, but appears to be currently not working. ENISA’s CNW can help with an educated guess: in the case of France, for instance, the CSIRT is the CERT-FR. Today, reporting incidents or vulnerabilities to the CERT-FR must be done by encrypted email, as indicated on this page (french). But ultimately, they should own an endpoint of ENISA’s reporting platform.

The CRA specifies what it means by “severe” incidents. That includes events that could negatively affect the software’s ability to protect the CIA triad: Confidentiality, Integrity, Authenticity of “sensitive or important data or functions” or even their availability. This will most likely be the case of any security incident.

The CRA explicitly addresses the introduction of malicious code into the software as a severe incident. The xz backdoor discovered earlier this year would be a prime example.

It is also specific as to how this reporting should happen:

• A first notification should be published as soon as possible, and before 24h of the entity becoming aware. For an incident, it should include whether it is suspected to have been caused by malicious actions. For a vulnerability, it should include the member states where the product is known to be used.
• As soon as possible and before 72h, an initial assessment and mitigations should be provided.
• As soon as possible and within one month after the initial assessment above, the entity should publish a final report detailing the incident or vulnerability, its impact, the root cause and the mitigations.
  For a vulnerability, it should also include information about any malicious actor known to have exploited or be exploiting it.

Reports after the first are only mandatory if they would add information.
In the case of an incident which impact, root cause and mitigations are all known within 24h, only one notification need be sent

Conclusion

This first post should have given you some insights as to where you stand regarding the CRA. Though it might still be unclear what exactly you need to be doing, you should have a rough idea of what to expect and when to expect it.
The next post will go into the details of what manufacturers will need to do.