Articles 3(40)–(42) — severity is not exploitation
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. 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. Related traps: CISA KEV ≠ 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 CVSS and EPSS actually give you
CVSS (Common Vulnerability Scoring System) ranks relative severity — typically confidentiality, integrity, availability and related metrics. It answers “how bad could this be if abused?” It does not answer “has a malicious actor already exploited it?”
EPSS estimates how likely a vulnerability is to be exploited in the wild in a near-term window. Useful for prioritising patches when you have hundreds of CVEs. It remains a statistical forecast. Article 3(42) is about reliable evidence of exploitation that has occurred — not a percentile that it might occur.
Neither score proves the CVE is in your product at an affected version, nor that the vulnerable code is reachable. For third-party components, Commission guidance C(2026) 5252 point 218 (not binding) addresses not-reachable / not-exploited-in-your-product shapes — see Article 14 for third-party components.
Public PoCs and scanner dashboards
A published proof-of-concept, Nuclei template or Metasploit module is often strong exploitability evidence (Article 3(41) territory). It is still not automatic Article 3(42) unless you also have reliable evidence that a malicious actor has used the vulnerability without the system owner's permission. Recital 68 steers good-faith testing, investigation, correction or disclosure away from mandatory notification; FAQ 5.2 walks the bug-bounty / lab-find examples on the zero-day guide.
SBOM and CVD tooling that shows CVSS, EPSS and KEV side by side is useful triage — not a CRA decision engine. Treat each badge as a reason to open the product assessment, then decide Article 14 on Articles 3(42) and 14(1).
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 Critical/high-EPSS alert is a reason to start that clock-starting assessment, not a reason to treat the score timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.
The trap: score as the reporting rule
Two failure modes. First: playbooks say “Critical / EPSS > X → file CRA” and burn the 24-hour clock on every scanner hit before version match, reachability and exploitation evidence are checked — flooding the SRP. Second: teams treat “low EPSS” or “Medium CVSS” 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 identifier, scores seen, SBOM/version match, reachability call, exploitation evidence relied on, and when reasonable certainty was reached.
Decision table
| Fact pattern | Article 14 AEV? |
|---|---|
| Critical CVSS / high EPSS; CVE not in your product | No Art 14(1) for that product (still watch other SKUs) |
| Critical CVSS / high EPSS + in product; no reliable exploitation evidence | Art 3(40)/(41) territory — not automatic Art 3(42) |
| Public PoC only; no malicious in-the-wild use evidenced | Usually not mandatory Art 14; assess + handle / voluntary |
| Scores modest, but reliable evidence of malicious exploitation in a system + contained in your product | Can still be Art 14(1) — low scores ≠ safe harbour |
| Contained + reachable + assessment reaches reasonable certainty of active exploitation (scores whatever) | Yes — start 24h / 72h AEV chain from awareness |
Questions people ask
- Does a Critical CVSS score mean we must file Article 14 within 24 hours?
- No. CVSS measures relative severity and impact characteristics of a vulnerability. Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. A Critical score without that evidence is not an automatic Article 14(1) notification — even if the CVE is in your SBOM.
- What about a high EPSS probability?
- EPSS (FIRST’s Exploit Prediction Scoring System) estimates the probability that a vulnerability will be exploited in the wild in a near-term window. It is a forecast, not an observation that exploitation has already occurred. Article 3(42) asks for reliable evidence of exploitation that has happened; a high EPSS percentile alone does not meet that test.
- Does the CRA mention CVSS or EPSS?
- No. Regulation (EU) 2024/2847 never names CVSS or EPSS. The legal ladder is Article 3(40) (vulnerability), Article 3(41) (exploitable vulnerability — potential under practical operational conditions), Article 3(42) (actively exploited), and Article 14(1) (contained in the product). Scoring systems are assessment inputs, not substitute decision rules.
- A public proof-of-concept (PoC) or Metasploit module appeared. Automatic AEV?
- Not on that fact alone. A public PoC often supports Article 3(41) exploitability — someone showed the flaw can be used under practical conditions. Article 3(42) still needs reliable evidence that a malicious actor has exploited it without the system owner’s permission. Good-faith research, testing or disclosure without malicious exploitation sits with Recital 68 and is not mandatory Article 14. Dedicated walkthrough: our public PoC / exploit code guide; also our zero-day guide (FAQ 5.2 bug-bounty example).
- Should a Critical / high-EPSS hit still start an assessment?
- Yes. 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. A scanner score is a reason to open that assessment — not to skip product match, reachability and exploitation evidence.
- Low CVSS / low EPSS means we never report?
- No. Scores are incomplete for CRA purposes. Customer telemetry, researcher reports of in-the-wild abuse, your own detection, a KEV listing, or other reliable exploitation evidence can meet Article 3(42) even when scores look modest. Low scores are not a safe harbour.
- 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)). Score-driven triage is part of that live reporting duty — it is not postponed to the December 2027 Annex I conformity package.