Articles 3(40)–(42) and 14(1) — status 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 VEX/CSAF row that says a CVE is affected (or that a component is exploitable) without Article 3(42) evidence is a handling and customer-communication problem (and may be Article 15 voluntary later) — not an automatic 24-hour early warning. Related traps: SBOM / CVE-in-SBOM ≠ automatic AEV, CVE / NVD ≠ automatic AEV, OSV / GHSA ≠ automatic AEV, EUVD ≠ automatic AEV, CISA KEV ≠ automatic AEV, CVSS / EPSS ≠ automatic AEV, public PoC / exploit code ≠ automatic AEV, zero-days / FAQ 5.2, and AEV vs severe incident.
What VEX and CSAF actually are (outside the CRA text)
Vulnerability Exploitability eXchange (VEX) is an industry pattern for asserting the status of a specific vulnerability in a specific product — commonly not_affected, affected, fixed, or under_investigation, with a justification. CSAF can carry VEX-style product status inside a machine-readable security advisory. Neither format appears in Regulation (EU) 2024/2847. They sit beside the SBOM inventory story in Article 3(39) and Annex I Part II, point (1) — process / transparency tooling for vulnerability handling, not a CSIRT filing form. Calendar and substitution traps: Article 14 vs Article 13 vulnerability handling and Article 14 and SBOM.
Article 14(8) separately requires manufacturers to inform impacted users (and where appropriate all users) in a timely manner after becoming aware of an actively exploited vulnerability or severe incident, including via a website and, where feasible, in a structured, machine-readable format. Teams often choose CSAF for that customer channel — see informing users under Article 14(8). Publishing a CSAF/VEX advisory does not file the 24-hour early warning, and an SRP filing does not complete Article 14(8).
Supplier VEX is triage — your product still owns Article 14
When a component vendor publishes VEX saying a CVE is exploited in their SKU, that is a third-party signal about their product assessment. For your integrated product, guidance point 218 (not binding) still addresses not-reachable / not-exploited-in-your-product shapes — see Article 14 for third-party components. Upstream notice under Article 13(6) (mostly from 11 December 2027) is not an SRP substitute. Catalogue and score dashboards that sit next to VEX are covered on the CVE / NVD, OSV / GHSA, EUVD, CISA KEV, and CVSS / EPSS guides. When you do file, ENISA’s platform asks for CVE ID and EUVD ID where available — identification metadata, not a VEX 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 VEX export, or a board memo. A new VEX/CSAF status change is a reason to start that clock-starting assessment, not a reason to treat the advisory timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.
The trap: VEX as the reporting rule
Two failure modes. First: playbooks say “VEX affected / supplier exploited → 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 a not_affected badge, an empty VEX feed, or “CSAF programme starts with Dec 2027 SBOM” 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: VEX/CSAF status and issuer, product/version scope, justification, exploitation evidence relied on, and when reasonable certainty was reached.
Decision table
| Fact pattern | Article 14 AEV? |
|---|---|
| VEX/CSAF affected; wrong version / not shipped in your SKU | No Art 14(1) for that product (still watch other SKUs) |
| VEX not_affected / not reachable (point 218 shape) and no contrary exploitation evidence | Usually not mandatory Art 14; keep justification + reassess |
| Supplier VEX says exploited; your assessment has not reached reasonable certainty for your product | Triage signal only — not automatic 24h early warning |
| Contained + assessment reaches reasonable certainty of active exploitation (VEX published or not) | Yes — start 24h / 72h AEV chain from awareness |
| Reliable exploitation evidence; no VEX/CSAF document yet | Can still be Art 14(1) — missing VEX ≠ safe harbour |
| CSAF published to users under Art 14(8) only | Customer notice ≠ SRP filing (still run Art 14(1)–(2) if AEV) |
Questions people ask
- Is every VEX “affected” status 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 VEX (or CSAF VEX) status of affected means the issuer asserts the product is impacted by a known vulnerability — usually an Article 3(40)/(41) shape. It does not by itself prove active malicious exploitation or that you have reached reasonable certainty of Article 3(42) in your product.
- Does the CRA require VEX or CSAF?
- No. Regulation (EU) 2024/2847 never names Vulnerability Exploitability eXchange (VEX) or the Common Security Advisory Framework (CSAF). Article 3(39) and Annex I Part II name the SBOM for vulnerability-handling inventory (mostly from 11 December 2027). Article 14(8) requires informing impacted users in a timely manner and, where appropriate, all users — including via a website and, where feasible, in a structured, machine-readable format — but it does not prescribe CSAF or VEX. Industry practice often uses CSAF for that customer channel; that is not an ENISA Single Reporting Platform filing.
- Our VEX says not_affected / fixed. Does that cancel Article 14?
- A well-founded not_affected or fixed assertion is strong triage evidence for your assessment — especially the guidance point 218 shape where vulnerable code is not reachable or the vulnerability has not been exploited in your product. It is not a statutory safe harbour. If later reliable evidence shows the vulnerability is contained in the product and actively exploited in the Article 3(42) sense, Article 14(1)–(2) still run from awareness after your assessment. Keep the VEX justification, version scope and reassessment trigger in the evidence log.
- A supplier published a VEX saying our component is exploited. Automatic SRP filing?
- Not on the supplier document alone. Treat it as a third-party signal that starts the immediate initial assessment (Commission guidance C(2026) 5252 points 213–214, not binding). You still need reasonable certainty that an actively exploited vulnerability is contained in your product. Upstream VEX / CSAF status is not a substitute for your Article 14 awareness call — and publishing your own VEX to customers is not a substitute for the SRP either.
- What should a new VEX / CSAF status change trigger?
- Immediate initial assessment, not an automatic SRP early warning. Guidance point 213: when a third party or other signal brings a potential vulnerability to your attention, 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 status flip from under_investigation to affected, or a new exploited claim in a supplier advisory, is a reason to start that assessment — not to treat the advisory timestamp as awareness without product confirmation.
- No VEX programme yet means we never have to report?
- No. Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)), whether or not you publish VEX/CSAF. Customer telemetry, researcher reports, your own detection, a CISA KEV listing, a CVE/NVD, EUVD, OSV/GHSA, SBOM match or other reliable exploitation evidence can meet Article 3(42) with no VEX document. Absence of VEX is not a reporting holiday.
- When did this duty start?
- Article 14 has applied from 11 September 2026 (Article 71(2)). Annex I Part II SBOM / vulnerability-handling duties generally apply from 11 December 2027 with the rest of the essential cybersecurity requirements (FAQ 7.1). VEX-driven triage feeds the live reporting duty — it does not postpone Article 14 to the conformity package, and it does not replace the SRP.