CRA vulnerability reporting: 24 hours to warn, 72 for details, 14 for the final report

Two tracks, one platform

The Cyber Resilience Act requires manufacturers of products with digital elements to report two kinds of events: actively exploited vulnerabilities and serious incidents. ^[1] Each has its own reporting track, its own triggers and its own coordinating body, but both go through the same platform run by ENISA, the EU Agency for Cybersecurity. ^[1]

The rules apply from 11 September 2026. ^[2] That leaves less time than many organisations think to decide who reports what, and when the clock starts.

Actively exploited vulnerabilities

A vulnerability counts as actively exploited when the manufacturer becomes aware that it is being used in the wild, before a patch is available. ^[1] The moment you become aware starts the clock.

The first deadline is 24 hours: an early warning to ENISA, with basic details of the vulnerability and the products affected. ^[1] Within 72 hours of becoming aware, you send a detailed notification, including technical information, affected product identifiers and, if you know it, who is exploiting it. ^[1] The final report comes within 14 days and includes mitigation measures and any update on the exploitation. ^[1]

ENISA coordinates the response and can share the information with national CSIRTs and other manufacturers whose products may be affected. ^[1] The reports are not published, but ENISA may issue public warnings. ^[1]

Serious incidents

A serious incident is one that has caused or could cause significant disruption, loss or harm, and that affects the security of a product with digital elements. ^[1] The test is materiality, not just technical severity.

The early warning goes out within 24 hours of becoming aware of the incident. ^[1] Within 72 hours you send a detailed notification, including the nature of the incident, the products affected and the estimated number of affected users. ^[1] The final report is due 14 days after the incident has ended or been sufficiently mitigated, and it must include lessons learned and measures taken. ^[1]

For incidents, the national CSIRT in the member state where the manufacturer is established coordinates the response. ^[1] If the incident affects users in several member states, CSIRTs cooperate.

When you became aware

Both tracks count hours from when the manufacturer became aware, not from when the vulnerability was discovered or the incident occurred. ^[1] That phrase matters. Becoming aware is not something that can be quietly redated.

Say a serious incident happens on a Tuesday morning. An engineer notices it, escalates it and the decision to report is made that afternoon. The 24-hour clock for the early warning started on Tuesday morning, when the organisation, through the engineer, became aware. If the warning goes out on Thursday morning, the timeline will be asked about.

Sealing the timeline as it happens

Here, the thing to seal is each step of the incident or vulnerability response: the first detection note, the decision to escalate, and each report as it is submitted through ENISA's platform. Sealing takes a fingerprint of the record, not the content, so sensitive details never leave your systems.

Seal the detection note when it is written, the escalation decision when it is made, and each report at the moment you submit it. Anyone you share the timeline with, including auditors and supervisors, can later check that the records are exactly what was written at each step. A change to any record, even by someone with administrator rights, shows up the moment the fingerprint is recalculated.

What it doesn't do is show that the report was complete, that the response was adequate, or that the incident was correctly characterised. It shows when each step was recorded, in a way that nobody can quietly rewrite afterwards.

You seal the timeline through WitniumChain, using the REST API, the SDK or the MCP server. The content stays with you. The first 2,000 witnesses a month are free. Read the documentation to see how it fits your incident response workflow.

How it would work

1. Your incident response system writes a detection note the moment an engineer flags a potential incident. A fingerprint of that note is sealed.
2. When the decision to escalate is made, that record is sealed with the time.
3. Each report submitted through ENISA's platform is sealed at submission, so you have a checkable record of what was sent and when.

What this means for you

If you manufacture products with digital elements that will be placed on the EU market after 11 December 2027, the reporting obligations apply. ^[2] Medical devices and vehicles with type approval are excluded. ^[2]

Here are three questions to ask now. Who in your organisation decides when you became aware of a vulnerability or an incident? Who drafts the reports, and who reviews them before they go out? Do you have a way to show, if asked, when each step was recorded?

The penalties for non-compliance go up to 15 million euro or 2.5 per cent of worldwide annual turnover, whichever is higher. ^[2] The reputational cost of getting the timeline wrong is harder to quantify.

What to watch

11 September 2026: the reporting obligations in Article 14 apply. ^[2]

11 December 2027: the essential requirements in Annex I apply, including the duty to have processes for handling vulnerabilities throughout the product's support period. ^[3]