Articles 3(40)–(42) and 14(1) — exploit code is not the filing test
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 public PoC without Article 3(42) evidence is a handling and prioritisation problem (and may be Article 15 voluntary later) — not an automatic 24-hour early warning. Related traps: CVSS / EPSS ≠ automatic AEV, CISA KEV ≠ automatic AEV, CVE / NVD ≠ automatic AEV, OSV / GHSA ≠ automatic AEV, SBOM / CVE-in-SBOM ≠ automatic AEV, VEX / CSAF ≠ automatic AEV, zero-days / FAQ 5.2, and AEV vs severe incident.
What a public PoC actually proves
A proof-of-concept is demonstration code or steps showing that a vulnerability can be triggered. Metasploit modules, nuclei templates and similar packages make that demonstration repeatable for defenders and attackers alike. That maps cleanly onto Article 3(41) exploitability — potential under practical operational conditions. It does not, without more, prove that a malicious actor has already exploited the vulnerability in a real system without the system owner’s permission (Article 3(42)).
Recital 68 steers good-faith testing, investigation, correction or disclosure away from mandatory notification. FAQ 5.2’s bug-bounty example sits in that neighbourhood: ethical discovery with no evidence of previous malicious exploitation is not mandatory Article 14 — see Article 14 for zero-day vulnerabilities. Severity and exploitation forecasts that often sit next to PoC badges are covered on the CVSS / EPSS guide.
PoC in your SBOM feed is still triage
When a scanner marks a CVE in your SBOM as “exploit available,” that is a third-party signal about exploitability of a known vulnerability — not proof that the vulnerable code is reachable in your shipped SKU, or that malicious exploitation has occurred. Guidance point 218 (not binding) still addresses not-reachable / not-exploited-in-your-product shapes — see Article 14 for third-party components. Catalogue and status dashboards that sit next to PoC flags are covered on the CVE / NVD, OSV / GHSA, EUVD, CISA KEV, SBOM, and VEX / CSAF guides. When you do file, ENISA’s platform asks for CVE ID and EUVD ID where available — identification metadata, not a PoC field that creates the duty; see the SRP fields checklist.
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, a complete forensic package, or a board memo. A new public PoC is a reason to start that clock-starting assessment, not a reason to treat the GitHub commit timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.
The trap: PoC as the reporting rule
Two failure modes. First: playbooks say “exploit available → file CRA” and burn the 24-hour clock before version match, reachability and exploitation evidence are checked — flooding the SRP and confusing CSIRTs. Second: teams treat “no public PoC” or “only a research write-up” 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: PoC/source URL, product/version scope, reachability, exploitation evidence relied on, and when reasonable certainty was reached.
Decision table
| Fact pattern | Article 14 AEV? |
|---|---|
| Public PoC / Metasploit / nuclei; wrong version / not shipped in your SKU | No Art 14(1) for that product (still watch other SKUs) |
| Public PoC; vulnerable code not reachable (point 218 shape) and no contrary exploitation evidence | Usually not mandatory Art 14; keep justification + reassess |
| Private researcher / bug-bounty PoC; no evidence of prior malicious exploitation (FAQ 5.2 / Recital 68 shape) | Usually not mandatory Art 14; Art 15 voluntary still open |
| Authorised red-team / pen-test used exploit code; no malicious actor exploitation | Recital 68 testing shape — not automatic Art 14 |
| Contained + assessment reaches reasonable certainty of active malicious exploitation (PoC published or not) | Yes — start 24h / 72h AEV chain from awareness |
| Reliable exploitation evidence; no public PoC yet | Can still be Art 14(1) — missing PoC ≠ safe harbour |
Questions people ask
- Does a public GitHub PoC mean we must file Article 14 within 24 hours?
- 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 public proof-of-concept shows that someone demonstrated how the flaw can be used — usually an Article 3(41) exploitability signal. It does not by itself prove malicious in-the-wild exploitation of your product.
- What about a Metasploit module, nuclei template or Exploit-DB entry?
- Same legal ladder. Weaponised or packaged exploit code is strong evidence that the vulnerability is exploitable under practical conditions (Article 3(41)). Article 3(42) still asks whether a malicious actor has already exploited it without the system owner’s permission. Treat the module or template as a reason to start the immediate initial assessment (Commission guidance C(2026) 5252 points 213–214, not binding), not as an automatic SRP early warning.
- Does the CRA mention PoC, Metasploit or exploit databases?
- No. Regulation (EU) 2024/2847 never names proof-of-concept, Metasploit, nuclei, Exploit-DB or similar. The legal tests are Article 3(40) (vulnerability), Article 3(41) (exploitable), Article 3(42) (actively exploited) and Article 14(1) (contained in the product). Industry exploit artefacts are assessment inputs, not substitute decision rules.
- A researcher sent us a private PoC through our bug bounty. Automatic filing?
- Usually not on that fact alone. FAQ 5.2’s worked example: a zero-day discovered by ethical hackers, with no evidence of previous malicious exploitation, disclosed through a bug-bounty programme (see Recital 76), is not an actively exploited vulnerability subject to mandatory reporting. Recital 68 steers good-faith testing, investigation, correction or disclosure away from mandatory notification. Article 15 voluntary notification remains open. Walkthrough: our zero-day guide.
- Our own red team / pen-test used a PoC against our product. Is that Article 3(42)?
- Authorised good-faith testing or investigation is the Recital 68 shape — it is not mandatory Article 14 merely because exploit code ran in a controlled test. If the same session (or later telemetry) produces reliable evidence that a malicious actor has exploited the vulnerability in a system without permission, that is a different fact pattern and can meet Article 3(42).
- No public PoC means we never have to report?
- No. Absence of a public PoC is not a safe harbour. Customer telemetry, researcher reports of in-the-wild abuse, your own detection, a CISA KEV listing, or other reliable exploitation evidence can meet Article 3(42) with no public exploit code. Missing PoC ≠ reporting holiday.
- 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)). PoC-driven triage feeds that live reporting duty — it is not postponed to the December 2027 Annex I conformity package.