CRA: reporting exploited vulnerabilities from September 2026

CRA vulnerability reporting is the obligation, set by Article 14 of the Cyber Resilience Act, for every manufacturer of a digital product to report actively exploited vulnerabilities and severe incidents affecting its products. In force since 11 September 2026, it requires an early warning within 24 hours, a notification within 72 hours and a final report, all filed on ENISA's single reporting platform. It also covers products sold before that date.

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets security requirements for products with digital elements that will only fully apply on 11 December 2027. One obligation was brought forward, however: reporting. Lawmakers wanted authorities to be told immediately about flaws that attackers are already exploiting, so they can warn and coordinate the response across the EU. Our article Cyber Resilience Act: what changes for digital products presents the regulation as a whole.

Article 14 comes down to four rules:

• report any actively exploited vulnerability contained in the product (paragraphs 1 and 2);
• report any severe incident having an impact on the security of the product (paragraphs 3 to 5);
• use the single reporting platform run by ENISA, addressed to the competent coordinating CSIRT (paragraph 7 and Article 16);
• inform affected users of the vulnerability or incident and of the measures to take (paragraph 8).

Who is concerned?

The obligation falls on the manufacturer, meaning whoever places the product on the market under its name, including an importer or distributor requalified as manufacturer. Open-source software stewards are also subject to it to the extent that they are involved in developing the products (Article 24). Article 69 extends reporting to all products already on the market: a router sold in 2023 and still in use is covered as soon as an exploited vulnerability is found in it. Products excluded from the CRA, such as medical devices, remain subject to their own rules.

The actively exploited vulnerability

The regulation defines it as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Two practical consequences. First, a flaw found by your teams or reported by a researcher, with no sign of exploitation, does not trigger Article 14: it follows your normal fix and disclosure process. Second, exploitation must be established, not merely possible: a published proof of concept is not enough on its own, whereas a CERT-FR alert, listing in a public agency's catalogue of exploited vulnerabilities or an incident report from a customer are serious indications to be investigated immediately.

The severe incident

An incident is considered severe when it:

• affects, or is capable of affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions;
• or has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of its users.

The typical example is the compromise of a vendor's update infrastructure: an attacker pushing a poisoned update to customers creates a severe incident, even if no vulnerability in the product itself is involved. An intrusion into the company's information system that does not affect product security falls under other texts such as NIS 2 or the GDPR.

Voluntary reporting

Alongside these obligations, Article 15 allows anyone, manufacturer or not, to voluntarily report a vulnerability, cyber threat, incident or near miss. According to ENISA, this option opens on the platform after 11 September 2026. In addition, a manufacturer that finds a vulnerability in a third-party component, including open source, integrated in its product must report it to whoever maintains that component (Article 13(6)): this is where the software bill of materials (SBOM) becomes essential.

Deadlines run from the moment the manufacturer becomes aware of the exploitation or incident, not from the discovery of the flaw nor from the availability of a fix. The first two steps are shared by both types of event; the final report differs.

Early warning: 24 hours

"Without undue delay and in any event within 24 hours", the manufacturer sends a short warning. For a vulnerability, it indicates in particular the Member States where the product is available; for an incident, it states whether it is suspected of being caused by an unlawful or malicious act. The point is not to have understood everything, but to raise the alarm.

Notification: 72 hours

Within 72 hours, the notification completes the warning: general information on the product, nature of the exploit or incident, initial assessment, corrective or mitigating measures already taken and measures users can apply, and how sensitive the information provided is.

Final report: 14 days or one month

• For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. It describes the vulnerability, its severity and impact, what is known of the malicious actor, and the fix.
• For a severe incident, it is due within one month of the 72-hour notification. It describes the incident, its severity, its likely root cause and the mitigation measures applied or ongoing.

ENISA's page lists, for each step, the mandatory, optional or conditional form fields, including the CVE or EUVD identifiers of the vulnerability. The 24-hour deadline is the hardest to meet, which is why Article 64 rules out fines for micro and small enterprises that miss it, without exempting them from reporting.

All reports go through the single reporting platform provided for in Article 16 and run by ENISA, the EU Agency for Cybersecurity. Announced for 11 September 2026, it has been operational since that date according to the European Commission. Access requires an EU Login account, which ENISA advises creating in advance; at launch, reports are filed through a web form, with no programming interface.

The coordinating CSIRT

The notification goes simultaneously to ENISA and to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment, meaning where most cybersecurity decisions about its products are taken. For a manufacturer established outside the EU, the Member State of its authorised representative, then of the importer or distributor, determines the competent CSIRT. In France, ANSSI confirms that the coordinating CSIRT is CERT-FR.

The coordinating CSIRT then forwards the notification to the CSIRTs of the other Member States where the product is sold, and can inform market surveillance authorities, in France ANFR. In exceptional circumstances, for cybersecurity reasons, it can delay this dissemination; a delegated act adopted by the Commission on 11 December 2025 sets out the conditions. Once a fix is available, ENISA adds the vulnerability to the European Vulnerability Database (EUVD).

What about the Digital Omnibus?

The Digital Omnibus proposal presented by the Commission on 19 November 2025 provides for a single entry point for incident notifications under NIS 2, the GDPR, DORA and other texts, which ENISA would build on its experience of the CRA platform. In its proposed form, it does not change CRA reporting obligations. As of 25 September 2026, the text is still at committee stage in the European Parliament: nothing changes for now.

Reporting to authorities is not enough. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform affected users and, where appropriate, all users, along with the mitigating or corrective measures they can apply. Where relevant, the regulation asks for a structured, machine-readable format, so that customers' vulnerability management tools can process it automatically. If the manufacturer fails to do so in good time, the CSIRT can inform users itself.

For customers, this is a significant change: CISOs will receive faster and more consistent information from their suppliers. To benefit, you need to know which products you use and who will notify you: one of the benefits of a third-party risk management approach that keeps the inventory of products and security contacts up to date.

The deadlines look alike, but the three obligations target neither the same actors nor the same events. A single incident can still trigger all three: a software vendor, an important entity under NIS 2, whose update infrastructure is compromised and which exposes its customers' personal data.

Article 14 deals with emergencies. Day-to-day work falls under coordinated vulnerability disclosure, which CRA Annex I makes mandatory from 11 December 2027. The manufacturer must:

• publish a coordinated disclosure policy explaining how to report a flaw, how it will be handled and within what timeframe;
• provide a contact address for reports, included in the information for users;
• fix without delay and distribute fixes free of charge, securely;
• publish information on fixed vulnerabilities: description, affected products, severity, remediation.

The two mechanisms meet: a vulnerability received through coordinated disclosure becomes an Article 14 case as soon as reliable evidence of exploitation appears. The Commission guidance of 27 July 2026 accepts that manufacturers rely on their existing coordinated disclosure processes. A manufacturer that already has a contact address, a triage process and fast CVE assignment will find the 24 hours much easier to meet.

Twenty-four hours, weekends included, is short. Manufacturers that meet this deadline prepared the ground before the first case. Here are the building blocks, to be scaled to the size of the organisation.

1. Detect

Monitor your own products: CERT-FR advisories, public catalogues of exploited vulnerabilities, reports from researchers and customers, feedback from support and operations. Cross-reference these sources with the software bill of materials of each release to know within minutes whether a vulnerable component is present.

2. Triage

Write a decision grid: is the vulnerability present in a covered product? Is there reliable evidence of exploitation? Does the incident affect product security? Name who decides, with a deputy, and record each decision and its time: the moment of awareness starts the clock, and you will be asked for it.

3. Notify

Create EU Login accounts for authorised staff in advance and have their link to the manufacturer validated. Prepare templates for the warning, notification and final report that follow the platform's fields. Plan legal review without letting it hold up the early warning.

4. Inform and fix

Prepare user messages, the security advisory page and, if possible, a machine-readable format. Coordinate communication with the fix: the 14-day final report assumes a corrective measure is available.

5. Rehearse and align

Include the "exploited vulnerability in a product we sell" scenario in your crisis exercises and your business continuity plan. Align the process with those for NIS 2 and the GDPR so that one incident is not handled three times by three different teams. Finally, if you buy products rather than make them, check that your suppliers have set up this process: it is a question to add to your assessments, as explained in our article on the Cyber Resilience Act, and how to classify products by category is covered in CRA: important and critical products.

To link these processes to your risk analyses and track the resulting action plans, see also our Risk & Compliance module.