CRA Reporting: the 24h, 72h and Final Report Explained

When something is being exploited, the clock starts. Here is what you must report, and when.

The CRA introduces one of its sharpest obligations: when a manufacturer becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting the security of the product, it must notify the authorities on a strict, staged timeline. These notifications go through the ENISA Single Reporting Platform (SRP) and are shared with the relevant national CSIRT and ENISA. Notably, these reporting duties apply earlier than the rest of the CRA — from 2026 — so they deserve attention now.

What triggers a report?

An actively exploited vulnerability contained in the product — i.e. there is evidence that a malicious actor is exploiting it, without necessarily any successful compromise being required.
A severe incident having an impact on the security of the product with digital elements — for example a compromise that affects the product's ability to protect its users.

Ordinary, non-exploited vulnerabilities that you find and fix through your normal handling process are not what this obligation is about — this is specifically for exploitation and severe incidents.

The three stages

24 hours

Early warning. An initial heads-up, without delay and no later than 24 hours after you become aware. It flags that an exploited vulnerability or severe incident is occurring — even if details are still thin — and can indicate whether it is suspected to be caused by unlawful or malicious acts.

72 hours

Notification. Within 72 hours, a fuller report: general information about the nature of the issue, an initial assessment, and where available any corrective or mitigating measures users can take.

Final

Final report. Once the matter is handled, a closing report covering a description of the vulnerability or incident including its severity and impact, information on the root cause, and the corrective measures applied. For an ongoing vulnerability, the final report follows once a fix is available.

Why the staged model?

The tight first deadline is deliberately about speed over completeness. Authorities and CSIRTs want to know quickly that something is being exploited so they can warn others and coordinate a response; the fuller picture can follow as you learn more. Trying to wait until you "have all the facts" defeats the purpose — and misses the 24-hour window.

The hard part is not the form — it is being ready. When an exploited vulnerability lands, you have hours, not days. That means the decision-making, the contacts, and the evidence-gathering must be prepared in advance, as a runbook.

Build the muscle before you need it

Know who decides. Have a named, reachable owner (and backups) who can authorise a report at any hour.
Have an internal approval step that does not become a bottleneck. Many teams want two or three responsible people to sign off before reporting — design that to happen fast.
Template your reports. Pre-build the 24h / 72h / final structures with the fields you know you will need, so you are filling blanks, not starting from scratch.
Keep the evidence trail. Link the report to the affected product, version, and SBOM finding.

ComplyCRA turns reporting into a workflow. It generates the 24h / 72h / final reports in a structured template aligned to the SRP fields, routes them through your responsible-approver sign-off, and keeps everything linked to the affected product and vulnerability — so when the clock starts, you are ready. Open ComplyCRA →

General information, not legal advice. Exact triggers, deadlines and content are defined in Regulation (EU) 2024/2847 and ENISA's Single Reporting Platform guidance — always follow the official sources.

The 24h, 72h and final report

What triggers a report?

The three stages

Why the staged model?

Build the muscle before you need it