CRA Article 14: EUVD listing ≠ automatic actively exploited vulnerability

Articles 3(40)–(42) and 14(1) — three steps, one that files

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. Article 3(41) defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions. Article 3(42) defines an 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.

Only the third triggers the mandatory Article 14(1) chain: the manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of, via the Article 16 Single Reporting Platform, to the coordinating CSIRT and ENISA. An EUVD row for a CVE that is exploitable but not actively exploited in the Article 3(42) sense is a handling problem (and may be Article 15 voluntary later) — not an automatic 24-hour early warning. Related traps: CISA KEV ≠ automatic AEV, CVSS / EPSS ≠ automatic AEV, CVE / NVD ≠ automatic AEV, OSV / GHSA ≠ automatic AEV, SBOM / CVE-in-SBOM ≠ automatic AEV, VEX / CSAF ≠ automatic AEV, public PoC / exploit code ≠ automatic AEV, zero-days / FAQ 5.2, and AEV vs severe incident.

What Article 17(5) and Recital 66 actually say

Article 17(5): after a security update or another form of corrective or mitigating measure is available, ENISA shall, in agreement with the manufacturer of the product with digital elements concerned, add the publicly known vulnerability notified pursuant to Article 14(1) or Article 15(1) to the European vulnerability database established pursuant to Article 12(2) of Directive (EU) 2022/2555 (NIS2). ENISA’s SRP FAQ confirms the Agency may contact the manufacturer to verify if and when that information can be added.

Recital 66 adds that ENISA should, in agreement with the manufacturer, disclose fixed vulnerabilities to that database, and that the database will assist manufacturers in detecting known exploitable vulnerabilities in their products. Detection is the point — then you still run the Article 3(42) / 14(1) product test. An EUVD entry that originated from another manufacturer’s Article 14 or 15 notification does not clone that filing duty onto every SBOM hit elsewhere.

For third-party components, guidance point 218 (not binding) addresses not-reachable / not-exploited-in-your-product shapes — see Article 14 for third-party components.

The SRP EUVD ID field is not the decision

When you do file an actively exploited vulnerability, ENISA’s platform and glossary ask for a CVE ID and EUVD ID where available. That is identification metadata for the notification stages — see the SRP fields checklist. Leaving the field blank when no ID exists yet is normal; inventing a duty because a scanner showed an EUVD badge is not. Walk the report shape in the vulnerability notification template.

When the 24-hour clock starts

Article 14(2)(a) runs the early warning from the manufacturer becoming aware. The Regulation does not define awareness. Guidance point 213: assess suspicious events or third-party alerts immediately; awareness is when, after that initial assessment, you have a reasonable degree of certainty that a vulnerability contained in your product is being actively exploited. Point 214: circumstances vary, but the emphasis is prompt assessment — not waiting for a perfect patch or a board memo. An EUVD match is a reason to start that clock-starting assessment, not a reason to treat the catalogue timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.

The trap: EUVD as the reporting rule

Two failure modes. First: playbooks say “EUVD → file CRA” and burn the 24-hour clock on every SBOM hit before version match, reachability and exploitation evidence are checked — flooding the SRP. Second: teams treat “not on EUVD” as a holiday even after reliable exploitation evidence arrives for a vulnerability contained in the product — exactly when Article 14(1)–(2) expect the AEV chain (final timed from corrective or mitigating measure available + 14 days under Article 14(2)(c); see corrective or mitigating measure). Record the assessment in the evidence log: CVE/EUVD identifier, SBOM/version match, reachability call, exploitation evidence relied on, and when reasonable certainty was reached.

Decision table

Questions people ask

Is every EUVD-listed vulnerability in our SBOM reportable under Article 14?

No. Article 14(1) requires notification of an actively exploited vulnerability contained in the product with digital elements. Article 3(42) defines that 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. An EUVD entry can support triage; it does not by itself prove the CVE is in your product at an affected version, that the code is reachable, or that you have reached reasonable certainty of active exploitation in your product.

Does Article 17(5) mean EUVD listing triggers the 24-hour clock?

No. Article 17(5) says that after a security update or another corrective or mitigating measure is available, ENISA shall, in agreement with the manufacturer concerned, add the publicly known vulnerability notified under Article 14(1) or Article 15(1) to the European vulnerability database (established under NIS2 Article 12(2)). That is largely a downstream disclosure step for a vulnerability that was already notified — not a rule that every EUVD row starts a new Article 14 clock for every other manufacturer.

The SRP asks for an EUVD ID. Does filling that field mean we must file?

No. ENISA’s SRP guidance treats CVE ID and EUVD ID as vulnerability fields where available. They identify the flaw you are notifying. The decision to open an Article 14 chain still turns on Articles 3(42) and 14(1) after your product assessment — not on whether an ID field exists in the form.

What should a new EUVD match on our components trigger?

Immediate initial assessment, not an automatic SRP early warning. Commission guidance C(2026) 5252 point 213 (not binding) says that when a third party or other signal brings a potential vulnerability to your attention, you should assess immediately; you are regarded as aware when, after that assessment, you have a reasonable degree of certainty that a vulnerability contained in your product is being actively exploited. Point 214 stresses prompt action. Recital 66 likewise frames the European vulnerability database as helping manufacturers detect known exploitable vulnerabilities — detection and assessment, not a substitute decision rule.

Our component is on EUVD but the vulnerable code is not reachable in our product. Still mandatory?

Guidance point 218 (not binding) addresses third-party components: if you are aware that a component vulnerability cannot be exploited in your product (for example the vulnerable code is not reachable) or has not been exploited in your product, it does not qualify as an actively exploited vulnerability contained in that product for mandatory Article 14. You may still owe Annex I Part II handling (mostly from 11 December 2027) and Article 13(6) upstream notice once that package applies — see our third-party components and Article 13 vs Article 14 guides.

Absence from EUVD means we never have to report?

No. EUVD is incomplete for CRA purposes. Customer telemetry, researcher reports, your own detection, a CISA KEV listing, or other reliable exploitation evidence can meet Article 3(42) with no EUVD row. Absence from EUVD is not evidence of non-exploitation.

When did this duty start?

Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). EUVD-driven triage is part of that live reporting duty — it is not postponed to the December 2027 Annex I conformity package.