Actively exploited vulnerability or severe incident? Which one am I filing?

The core distinction

Which form you open in the portal depends on what you actually found, not on how bad it sounds. Article 14 of Regulation (EU) 2024/2847 (the CRA) creates two separate manufacturer notification duties, not one duty with two labels.

Article 14(1) covers “any actively exploited vulnerability contained in the product with digital elements.” Article 3(42) of the same regulation defines “actively exploited vulnerability” as “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” So an AEV notification is anchored on a flaw in your product, plus reliable evidence a malicious actor has actually exploited that flaw.

Article 14(3) covers “any severe incident having an impact on the security of the product with digital elements.” The CRA does not give “severe incident” a standalone Article 3 definition. Instead, Article 14(5) sets the severity test directly: an incident having an impact on the product’s security counts as severe where either (a) it negatively affects, or is capable of negatively affecting, the product’s ability 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 the product or in a user’s network and information systems.

Unsettled: “severe incident” has no standalone Article 3 definition the way “actively exploited vulnerability” does. Its bar is set operationally in Article 14(5), which this page treats as the working definition.

The practical decision rule

Ask what you actually have evidence of.

If what you have is reliable evidence that a specific flaw in your own product is being actively exploited by a malicious actor, that is an AEV, reportable under Article 14(1)/(2), regardless of whether it has yet caused any measurable impact.

If what you have is an incident, meaning an event whose effects meet the Article 14(5) severity bar, that is an SI, reportable under Article 14(3)/(4), even if the trigger was not a product vulnerability at all, for example a compromise of build infrastructure, credentials, or a supply chain link.

The European Commission’s CRA implementation guidance describes the moment of “becoming aware” in these same either/or terms: a manufacturer must assess a suspicious event to determine whether it constitutes an actively exploited vulnerability or a severe incident, and is treated as aware once it has a reasonable degree of certainty that either a vulnerability in its product is being actively exploited, or a severe incident has occurred and has compromised the security of its product.

That same Commission guidance also confirms the premise behind treating exploitation as product-specific: if a third-party component contains a vulnerability that either cannot be exploited in your product, for example because the vulnerable code path is unreachable, or has not actually been exploited in your product, it does not qualify as an actively exploited vulnerability for you, and mandatory reporting does not apply. A vulnerability record appearing in ENISA’s European Vulnerability Database (EUVD) is therefore evidence worth investigating, not itself a reportable AEV: recital 66 of the CRA describes the EUVD as a tool that “will assist manufacturers in detecting known exploitable vulnerabilities in their products,” and the SRP Glossary’s EUVD ID field treats an EUVD record as a reference identifier a manufacturer can cite once it has separately established that the vulnerability is exploitable in, and has actually been exploited in, its own product, which is the Article 3(42) test, not the fact that a record exists in the database.

The ENISA SRP mechanics

The ENISA SRP FAQ confirms this is treated as a binary choice in the reporting tool itself: an Assigned Representative must select whether the notification concerns an AEV or an SI having a severe impact on the security of a product with digital elements, and the reporting fields then adapt to the selected notification type. The SRP Glossary likewise frames this as a single “Vulnerability or Incident” selection per notification.

Where both could plausibly apply

A single real-world event can plausibly satisfy both definitions at once. Example: a malicious actor actively exploits a vulnerability in your product, satisfying Article 3(42), and that exploitation introduces or executes malicious code in the product, satisfying the Article 14(5)(b) severity test for a severe incident.

None of the primary sources checked for this page state what a manufacturer should do in that overlap case: which notification type takes priority, or whether both must be filed for the same event. The SRP’s single “Vulnerability or Incident” selection field implies the platform expects one classification per notification, but no source explains how to choose when both are genuinely met.

Unsettled: this is a real gap in the guidance reviewed here, not something this page can responsibly resolve by inference.