CRA reporting: what to send, to whom, and how fast

Since 11 September 2026, the Cyber Resilience Act (CRA) has required you to report two kinds of event: an actively exploited vulnerability in your product, and a severe incident that affects its security (Article 14). Each one needs an early warning within 24 hours of you becoming aware, a fuller notification within 72 hours, and a final report later. You send them through ENISA's Single Reporting Platform, and you tell affected users too.

The two events and their clocks

Step	Actively exploited vulnerability	Severe incident
Early warning	Within 24 hours of becoming aware (Article 14(2)(a))	Within 24 hours of becoming aware (Article 14(4)(a))
Notification	Within 72 hours of becoming aware (Article 14(2)(b))	Within 72 hours of becoming aware (Article 14(4)(b))
Final report	No later than 14 days after a fix or mitigation is available (Article 14(2)(c))	Within one month after the 72-hour notification (Article 14(4)(c))

The law says "without undue delay and in any event within" those times. So 24 hours is the latest you may send, not a target.

What counts as actively exploited

The CRA 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 (Article 3(42)).

That's narrower than "a known bug". A researcher who finds a hole in your camera firmware and tells you about it hasn't triggered Article 14, because nobody exploited it. A CVE in a library you ship, with attackers already using it against your product in the field, is the case the law means.

What makes an incident severe

An incident that affects the security of your product is severe when it harms, or could harm, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It's also severe when it has led, or could lead, to malicious code running on the product or on a user's network (Article 14(5)).

Think of a compromised update server pushing tampered firmware. That fits.

What each report contains

Early warning. That it happened and, where you know, the EU countries where the product is sold. For an incident, also whether you suspect unlawful or malicious acts caused it.

Notification. General information about the product, the nature of the exploit or incident, what you've done to fix or limit it, what users can do themselves, and how sensitive you consider the information to be.

Final report for a vulnerability. A description of the flaw with its severity and impact, any information on who exploited it, and details of the security update or other fix (Article 14(2)(c)).

Final report for an incident. A detailed description with severity and impact, the likely root cause or type of threat, and the measures applied and still ongoing (Article 14(4)(c)).

The coordinating CSIRT can also ask you for an intermediate status report in between (Article 14(6)).

Where the reports go

You submit through the Single Reporting Platform to the CSIRT designated as coordinator in the member state where your company has its main establishment, and ENISA sees the report at the same time (Article 14(7)). A CSIRT is a national computer security incident response team.

Your main establishment is the member state where decisions on the cybersecurity of your products are mostly taken. If that's unclear, it's the one where you have the most staff in the EU. Makers with no EU establishment follow a fixed order: the authorised representative's country, then the importer's, then the distributor's, then the country with the most users.

The platform runs in a basic version and has no machine interface. Someone on your team types or pastes each report in.

Telling your users

Once you know, you must inform the affected users, and all users where appropriate, about the vulnerability or incident and any steps they can take to reduce the risk (Article 14(8)). If you don't do this in time, the CSIRT may tell them itself.

Products you sold years ago

The reporting duty also covers every product in scope that you placed on the market before 11 December 2027 (Article 69(3)). Devices you sold in 2022 are included.

A note for micro and small companies

If you're a micro or small enterprise, you can't be fined for missing the 24-hour early warning deadline (Article 64(10)(a)). The early warning itself is still required, and so are the 72-hour notification, the final report and the user notice. Our small companies guide covers who qualifies.

Getting ready before it happens

Most of the 24 hours goes on finding things out, so the useful work happens beforehand:

• Keep a current parts list for every firmware version you still support, so you can tell in minutes whether a flaw is in your product.
• Decide who files, and who stands in when they're away.
• Write templates for the early warning and the notification now.
• Keep the user notice short and ready to send by email or in your app.

What Proofsheet does here

Watchdog (€79 a month, opening soon) is a software subscription. It keeps the parts list for each release and matches it against new CVEs as they come in. When a part you use appears on CISA's known exploited list, the app sends you an email. The 24-hour kit then generates drafts of the early warning, the 72-hour notification, the final report and the user notice from your parts list and product details.

Two limits, plainly. A CVE on CISA's list means someone exploited that flaw somewhere; only you can judge whether it is exploited in your product, which is what Article 14 asks about. And the app doesn't submit anything. You review the text, add what only you know, and send it on ENISA's platform. It's technical evidence, not a legal certificate.

See how Watchdog works, or read about the SBOM and the CRA deadlines.