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. A critical, exploitable CVE with no reliable exploitation evidence is a handling problem (and may be Article 15 voluntary later) — not an automatic 24-hour early warning. See also zero-days / FAQ 5.2, SBOM / CVE-in-SBOM ≠ automatic AEV, VEX / CSAF ≠ automatic AEV, public PoC / exploit code ≠ automatic AEV, and AEV vs severe incident.
What a KEV listing actually gives you
CISA’s Known Exploited Vulnerabilities catalogue lists CVEs for which that US authority has evidence of active exploitation. For a CRA manufacturer that is useful in one direction and limited in the other.
Useful: reliable third-party evidence that the vulnerability has been exploited somewhere — material for the first half of Article 3(42). A clear reason to open the immediate initial assessment that guidance point 213 expects when a third party or public source flags a potential issue.
Not enough alone: KEV lists CVEs, not your SBOM. It does not prove the vulnerable component version is in your product (Article 14(1) “contained in”). It does not settle reachability in your product — guidance point 218 treats not-reachable / not-exploited-in-your-product component cases as outside mandatory Article 14 for that manufacturer (with upstream / handling duties still in view). And it is not complete: exploitation you learn from a customer, researcher or your own telemetry can meet Article 3(42) with no KEV row. See Article 14 for third-party components.
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. A KEV match is a reason to start that clock-starting assessment, not a reason to skip it or to treat the catalogue timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.
The trap: catalogue as the reporting rule
Two failure modes. First: playbooks say “KEV → file CRA” and burn the 24-hour clock on every SBOM hit before version match and reachability are checked — flooding the SRP and confusing CSIRTs. Second: teams treat “not on KEV” or “KEV but we think we’re fine” 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/KEV identifier, SBOM/version match, reachability call, exploitation evidence relied on, and when reasonable certainty was reached.
Decision table
| Fact pattern | Article 14 AEV? |
|---|---|
| CVE on KEV; not in your SBOM / affected version | No Art 14(1) for that product (still watch for other SKUs) |
| KEV + component in product, but vulnerable code not reachable (point 218 shape) | Usually not mandatory Art 14; assess + handle / upstream |
| KEV + contained + reachable; assessment reaches reasonable certainty of active exploitation | Yes — start 24h / 72h AEV chain from awareness |
| Reliable exploitation evidence; CVE never listed on KEV | Can still be Art 14(1) — KEV absence ≠ safe harbour |
| High CVSS / EPSS only; no exploitation evidence (see CVSS / EPSS guide) | Art 3(40)/(41) territory — not automatic Art 3(42) |
| EUVD listing only (see EUVD guide) | Same product test — catalogue ≠ automatic Art 3(42) |
| CVE / NVD listing only (see CVE / NVD guide) | Same product test — identifier ≠ automatic Art 3(42) |
| OSV / GHSA listing only (see OSV / GHSA guide) | Same product test — advisory ID ≠ automatic Art 3(42) |
Questions people ask
- Is every CISA KEV CVE 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. A KEV listing can support the exploitation half; it does not by itself prove the CVE is in your product at an affected version, or that the vulnerable code is reachable in your product.
- Does the CRA mention KEV at all?
- No. Regulation (EU) 2024/2847 never names CISA’s Known Exploited Vulnerabilities catalogue. The legal tests are Article 3(42) (actively exploited) and Article 14(1) (contained in the product you made available). US catalogue criteria are not a CRA substitute decision rule.
- What should a new KEV match 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. KEV is exactly that kind of signal.
- Our component is on KEV 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 KEV means we never have to report?
- No. KEV is incomplete for CRA purposes. Customer telemetry, researcher reports, your own detection, or other public exploitation evidence can meet Article 3(42) with no KEV entry. Absence from KEV is not evidence of non-exploitation.
- Does a high CVSS or EPSS score make a CVE “actively exploited”?
- No. Article 3(40) covers vulnerabilities generally and Article 3(41) covers exploitable vulnerabilities (potential under practical conditions). Scores speak to severity or exploitability forecasts. Article 3(42) requires reliable evidence that a malicious actor has exploited it — a score is not that evidence. Dedicated walkthrough: our CVSS / EPSS guide.
- 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)). KEV-driven triage is part of that live reporting duty — it is not postponed to the December 2027 Annex I conformity package.