Incident or vulnerability? How the CRA treats the two reportable events
The Cyber Resilience Act defines two reportable events. An actively exploited vulnerability is a flaw in the product with reliable evidence of exploitation; a severe incident is an event that impairs the product's ability to protect data or functions or introduces malicious code. The same 24-hour and 72-hour steps apply, but the final report is triggered differently.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- Vulnerability
- A weakness in the product; reportable when actively exploited (Art. 3, Art. 14(1))
- Incident
- An event affecting security; reportable when severe and impacting the product (Art. 3, Art. 14(3))
- Shared
- Early warning 24 h · Notification 72 h · Inform users
- Differs
- Final report: fix + 14 days (vulnerability) vs notification + 1 month (incident); early-warning content
The definitions side by side
| Actively exploited vulnerability | Severe incident | |
|---|---|---|
| What it is | A weakness, susceptibility or flaw of the product that can be exploited, for which there is reliable evidence of malicious code execution without the system owner's permission | An event compromising availability, authenticity, integrity or confidentiality that negatively affects (or can affect) the product's ability to protect sensitive or important data or functions, or that introduced or executed malicious code in the product or its users' systems |
| Typical origin | A CVE in a shipped component appears in an exploitation catalogue; telemetry shows exploitation; a researcher demonstrates in-the-wild abuse | Compromised update infrastructure; tampered release; leaked signing keys; fleet compromise; a breach of the product's cloud back-end |
| Early-warning extra | Member States where the product is available | Member States, plus whether malicious or unlawful acts are suspected |
| Final report trigger | 14 days after a corrective or mitigating measure is available | One calendar month after the notification |
| Final report content | Vulnerability description, severity, impact, actor information, security update details | Incident description, severity, impact, root cause or threat type, mitigation applied and ongoing |
Deciding which record to open
Ask what the event is about. If it is about a flaw in your code or a component — something a patch fixes — it is a vulnerability, and the question is whether exploitation evidence exists. If it is about something that happened — an intrusion into your build system, a malicious package delivered, devices enrolled in a botnet — it is an incident, and the question is whether it meets the severity threshold.
Many real events involve both: an exploited vulnerability leads to compromised devices, or an incident reveals the vulnerability that enabled it. Open both records, link them, and run the reporting case that best describes what you are notifying. Regulators would rather see one coherent case with linked facts than two contradictory ones.
The severity threshold for incidents
Not every incident is severe. The threshold is impact on the product's ability to protect sensitive or important data or functions, or the introduction or execution of malicious code. A brief outage of a non-security feature is an incident under the general definition but usually not a severe one; a compromised signing key is severe even if no malicious update has yet been shipped, because the capability to introduce malicious code now exists. Document the judgement with rationale either way — a recorded decision not to report is evidence of a functioning process.
Sensitive-data and function examples
- Smart lock: remote unlock command integrity — a core security function. Compromise is severe.
- Security camera: confidentiality of video streams. Unauthorised access is severe.
- Industrial controller: integrity of control commands and availability of safety functions. Loss is severe.
- Marketing website of the product vendor: not part of the product with digital elements; an incident there is a NIS2 or GDPR matter, not a CRA Article 14 event, unless it distributes the product or its updates.
What to record in either case
- Awareness time, timezone and the person who confirmed it.
- Affected products and versions, and the Member States where they are made available.
- The reportability decision, its rationale, reviewer and time — including 'not reportable' decisions.
- Measures taken and measures users can take, with timestamps.
- For vulnerabilities: when a corrective or mitigating measure became available.
- For incidents: whether malicious or unlawful acts are suspected; root cause once known.
- Every notification as a frozen revision with the submission reference.
Frequently asked questions
- A researcher shows us a proof of concept. Is that 'actively exploited'?
- A proof of concept demonstrated to you by the researcher is not evidence of exploitation on a system without the owner's permission. It is an exploitable vulnerability to remediate under Annex I Part II — urgently — but not, on its own, an Article 14 event. If the same researcher shows evidence of abuse in the wild, it is.
- Our cloud back-end had a breach. Is that a product incident?
- If the back-end is remote data processing the product depends on to perform its functions, it is part of the product with digital elements, and a breach affecting the product's security is assessed as a product incident. If it is a general corporate system, NIS2 or data-protection reporting may apply instead.
- Can a 'not reportable' decision be revisited?
- Yes, and it should be when new evidence arrives — for example a later KEV listing. Awareness for Article 14 then runs from the moment the new evidence made the event reportable, which is why the earlier decision and its rationale must be on record.