Actively exploited vulnerability vs severe incident: which one are you reporting?

An actively exploited vulnerability is a flaw in your product that someone has reliably been shown to exploit. A severe incident is an event that has compromised, or could compromise, your product's ability to protect sensitive data or functions, or that has led or could lead to malicious code running in it. Under CRA Article 14 both carry the same 24-hour and 72-hour clocks, but different content and a different final-report anchor, so the first question in any case is which one you are reporting.

How does the CRA define each one?

The Regulation defines the two terms separately, in Article 3, and adds a severity test for incidents in Article 14(5). A vulnerability is a weakness in the product. An incident is an event. Which one you are reporting depends on whether the thing you learned about is a flaw that is being used, or something that happened.

Article 3(40) defines a vulnerability as "a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat".Art. 3⁠(40)⁠

Article 3(43) borrows the definition of incident from NIS2: "an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems".Art. 3⁠(43)⁠

Article 3(44) narrows that to an incident having an impact on the security of the product with digital elements: "an incident that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions".Art. 3⁠(44)⁠

Only severe ones are reportable. Article 14(5) says such an incident "shall be considered to be severe where":Art. 14⁠(5)⁠

(a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or

(b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.

Read (a) against Article 3(44). The words that make an incident severe are "sensitive or important". Read (b) on its own. It needs no data at all: an incident that could put malicious code into your product or onto a user's systems is severe whether or not anything was taken. And note "is capable of" in both limbs. An incident caught before it caused harm can still meet the test.

How do the two reports compare?

The early warning and notification run on the same clocks for both kinds. Everything else differs: what triggers the report, what each stage must contain, and what the final-report clock runs from.

Both go to the CSIRT designated as coordinator and to ENISA, through the single reporting platform.Art. 14⁠(7)⁠ The anchors in the final-report row are where people slip. The vulnerability clock can sit unstarted for weeks while there is no fix. The incident clock starts when you press submit on the notification, not at the 72-hour deadline. Both are explained in why the CRA final report isn't due 14 days after the bug.

Five cases, worked through

These are illustrations, not legal advice. Each one turns on facts your team would have to establish. The point is the reasoning, not the verdict.

A compromised build pipeline

An attacker gets into your CI system and alters a build step. A release containing their code is signed and published. There may be no flaw in your product's source at all. This is an incident, and it meets Article 14(5)(b): it has led to the introduction of malicious code into the product. If you catch the change before any release ships, "is capable of leading to" may still apply. Report it as a severe incident. The final report is due one month after you submit the notification.

An exploited bug in a shipped dependency

A library you ship appears in the CISA Known Exploited Vulnerabilities catalog. That listing says someone, somewhere, exploited the library. It does not yet tell you whether your product is affected. Open an assessment: is the component shipped and the vulnerable path reachable, is there evidence of exploitation against your product or your users, which supported versions contain it, and is a fix already out. If the answers make it an actively exploited vulnerability in your product, the clocks start at that decision, and the final report is due 14 days after your fix is available. How we keep catalogue matches from becoming false alarms is in how we tier KEV alerts.

A leaked firmware signing key

You find your private signing key in a public repository, or in an attacker's tooling. Nobody has exploited a flaw in your product; your key has been exposed. With it, anyone could sign firmware your devices would accept. That is capable of leading to the execution of malicious code in the product, so Article 14(5)(b) is met. It also goes to the authenticity of the product's updates under limb (a). Report a severe incident, and plan the revocation and rotation as the mitigation the final report will describe.

A customer data breach on your SaaS backend

Start with scope. A standalone SaaS product is generally outside the CRA, and a breach there is a matter for GDPR and possibly NIS2, not Article 14. The answer changes if the backend is the remote data processing for a product you ship, such as the cloud service behind a connected device or a mobile app. Then a breach that compromises the confidentiality of sensitive user data the product is meant to protect can meet Article 14(5)(a). The scope question is worked through in is your SaaS in scope for the CRA. GDPR obligations may run alongside, on their own clock, to a different authority.

A case that is both

An attacker exploits a flaw in your device's update agent and uses it to push code to customers' devices. The flaw meets Article 3(42): there is reliable evidence it was exploited without the owner's permission. The resulting compromise meets Article 14(5)(b): malicious code has been executed in users' systems. The Regulation does not say the two duties exclude each other, and the reporting platform takes one notification type per report. The cautious course is two reports, each with its own final-report clock: 14 days from the fix for the vulnerability, one month from the incident notification for the incident. Agree the approach with your coordinating CSIRT early, and cross-reference the two in each summary.

How do you decide which one you are reporting?

Ask what you have learned: that a flaw in your product is being used, or that something happened to your product or its users. Then test each against its own definition. The order below keeps a catalogue signal from starting a clock, and keeps an incident without a flaw from being forced into the vulnerability form.

1. Is the product in scope? It must be a product with digital elements made available in the EU, within its support period. There is no exemption for products placed on the market before December 2027. If it is pure SaaS, stop here, or check whether it is the remote data processing of a product.
2. Is there a flaw in the product, and reliable evidence that a malicious actor exploited it without the system owner's permission? If yes, you have an actively exploited vulnerability. Record the decision and the time.
3. Separately, has an event affected the product's ability to protect data or functions? If yes, test it against Article 14(5). Sensitive or important data or functions, or malicious code in the product or a user's systems, makes it severe.
4. If both step 2 and step 3 are yes, prepare two reports and run two final-report clocks.
5. If neither is yes, record the decision with the evidence and reasoning. A "not reportable" decision is evidence too, and should be as durable as a reportable one.

The decision you record in step 2 or 3 is the awareness time, and it starts the 24-hour and 72-hour clocks. Product class does not change any of them. What counts as that moment is examined in what becoming aware actually means, and the clocks for both families are set out on Article 14, in plain language. The full text is on EUR-Lex, and the Commission's summary is on its CRA reporting page.

What to do this week

1. Write the two definitions and the Article 14(5) test into your incident runbook, word for word, so the person on call is not paraphrasing from memory.
2. Add a "both?" check to your triage: every exploited-vulnerability case asks whether users' systems were compromised, and every incident asks whether a product flaw was the way in.
3. Make sure you record the submission time of every incident notification. It is the only anchor for the one-month final report.
4. Run your SBOM through the free KEV check to see which components would open an assessment today.