CRA reporting from 11 September 2026: what, to whom, and by when

What triggers a report

Two things, both about your product with digital elements (Article 14):

• An 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 permission of the system owner” (Article 3(42)). A known vulnerability on its own is not enough; see what “actively exploited” means.
• A severe incident having an impact on the security of the product. Severe means it affects, or can affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or it has led or can lead to malicious code being introduced or executed (Article 14(5)).

Who has to report

The manufacturer: whoever develops a product, or has it developed, “and markets them under its name or trademark, whether for payment, monetisation or free of charge” (Article 3(13)). Article 14 applies from 11 September 2026 (Article 71(2)) and, unlike the rest of the regulation, also to products placed on the market before 11 December 2027 (Article 69(3)). Software you already sell is covered today.

ENISA's FAQ adds one relief: you don't have to report retroactively an actively exploited vulnerability you were already aware of before 11 September 2026.

Where reports go

Notifications go “simultaneously to the CSIRT designated as coordinator” and to ENISA, “via the single reporting platform” (Article 14(1)). In practice that is one submission on ENISA's Single Reporting Platform, live since 11 September 2026. The CSIRT is the one in the Member State of your main establishment: where decisions on your products' cybersecurity are mainly taken (Article 14(7)).

According to ENISA's FAQ, the platform has no API at launch, is in English only, and organisations register through “assigned representatives”. One notification is required per vulnerability or incident, and later stages update it. The coordinating CSIRTs must also offer helpdesk support, “in particular” to micro, small and medium-sized enterprises (Article 17(6)).

The deadlines

The early warning and the notification are due “without undue delay and in any event within” those hours: they are a maximum, not a target. The early warning can be short; it states, where applicable, the Member States where you know the product is available. The final report describes the vulnerability and its severity and impact, any information on the malicious actor, and the security update or other corrective measure.

ENISA's FAQ (updated 3 October 2026) notes that the platform's countdown currently shows the 72-hour deadline as 48 hours after the early warning, and that a later release will fix it. Count from the moment you became aware.

Tell your users

After becoming aware, you must also inform the impacted users, and where appropriate all users, of the vulnerability or incident and of any mitigation they can apply, “where appropriate in a structured, machine-readable format” (Article 14(8)).

Fines and small companies

The administrative fines in Article 64 do not apply to micro and small enterprises for missing the 24-hour early-warning deadline (Article 64(10)(a)). The obligation itself stays, and so do the 72-hour notification and the final report.

What to have ready

• Who decides that a vulnerability is actively exploited, and who files. Register your assigned representatives on the platform before you need them.
• A way to know what you shipped: which versions contain which components.
• A record of when you became aware and who decided. That moment starts every clock, and it is what you will be asked to justify.