People talk about "CRA reporting" as one thing. Article 14 actually defines two, and while they share a rhythm, treating them as interchangeable is a good way to file the right report against the wrong deadline.
Two streams, one cadence
Both streams run the same first two steps: an early warning within 24 hours of becoming aware, and a fuller notification within 72 hours. That shared cadence is why they're easy to conflate. What differs is what starts each one and how each one ends.
The actively exploited vulnerability stream
This stream triggers on a vulnerability in your product being actively exploited — reliable evidence that an attacker is exploiting it in the wild. The subject is a flaw. The detail of the trigger — what clears the "actively exploited" bar and what doesn't — is its own topic; see what counts as actively exploited.
The severe incident stream
This stream triggers on a severe incident having an impact on the security of the product — an event that negatively affects, or is capable of affecting, the product's security. Think a compromise of your build or update infrastructure, a malicious update pushed to users, or an availability event with security impact. The subject here is an event, not a specific flaw, and it can arise with or without a known vulnerability behind it.
Where they diverge: the final report
| Actively exploited vulnerability | Severe incident | |
|---|---|---|
| Trigger | A flaw exploited in the wild | A security-impacting event |
| Early warning | 24 h | 24 h |
| Notification | 72 h | 72 h |
| Final report | within 14 days of a corrective measure being available | within 1 month of the 72-hour notification |
The final-report clocks are genuinely different — and one is pegged to a corrective measure being available, the other to a fixed period after the notification. A report timed to the wrong reference point is a compliance miss even if the content is perfect.
Keeping them separate in your process
Because the triggers and end-points differ, the two streams want to be distinct workflows from the moment an event is classified — each with its own timeline, templates and audit record. One real-world event may open both at once (an exploited vulnerability that leads to a compromise), in which case you run two clocks in parallel, not one merged one. All of it lands in the same place — the Single Reporting Platform — and sits inside the same overall obligation described in the reporting pillar.
Frequently asked
What is the difference between a severe incident and an actively exploited vulnerability under the CRA?
An actively exploited vulnerability is a flaw in your product being exploited in the wild. A severe incident is an event that negatively affects, or is capable of affecting, the security of your product — for example a compromise or a malicious update. They are separate reporting triggers, though one can lead to the other.
Do the two streams have the same deadlines?
They share the 24-hour early warning and 72-hour notification. The final report differs: within 14 days of a corrective measure being available for an actively exploited vulnerability, and within one month of the 72-hour notification for a severe incident.
Can one event trigger both streams?
Yes. An actively exploited vulnerability that leads to a compromise can generate both a vulnerability report and a severe-incident report. Track them as distinct obligations with their own timelines rather than collapsing them into one.