Articles 3(40)–(42) and 14(1) — inventory 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 CVE (or OSV / GHSA / EUVD / KEV) hit against an SBOM component 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: CVE / NVD ≠ automatic AEV, OSV / GHSA ≠ automatic AEV, EUVD ≠ automatic AEV, CISA KEV ≠ automatic AEV, CVSS / EPSS ≠ automatic AEV, VEX / CSAF ≠ automatic AEV, public PoC / exploit code ≠ automatic AEV, zero-days / FAQ 5.2, and AEV vs severe incident.
What an SBOM actually is under the CRA
Article 3(39) defines a software bill of materials as a formal record containing details and supply-chain relationships of components included in the software elements of a product with digital elements. Annex I Part II, point (1), requires manufacturers to identify and document vulnerabilities and components contained in the product — including by drawing up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies. That is process / conformity evidence under Article 13 and Annex I, not a CSIRT filing form. Calendar and substitution traps: Article 14 vs Article 13 vulnerability handling.
For third-party components listed on the SBOM, guidance point 218 (not binding) addresses not-reachable / not-exploited-in-your-product shapes — see Article 14 for third-party components. Upstream notice to a maintainer under Article 13(6) is not an SRP substitute. Score- and catalogue-driven dashboards that sit on top of the SBOM are covered on the CVSS / EPSS, CVE / NVD, OSV / GHSA, EUVD, and CISA KEV guides.
SBOM rows are not the SRP 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. Matching those IDs to an SBOM component helps prove containment and version; inventing a duty because a scanner painted a red badge on every SBOM row 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, a complete SBOM export, or a board memo. A new CVE-in-SBOM match is a reason to start that clock-starting assessment, not a reason to treat the scanner timestamp as awareness without product confirmation. Walkthrough: becoming aware; clocks in reporting deadlines.
The trap: SBOM as the reporting rule
Two failure modes. First: playbooks say “CVE in SBOM → file CRA” and burn the 24-hour clock on every scanner hit before version match, reachability and exploitation evidence are checked — flooding the SRP and confusing CSIRTs. Second: teams treat “SBOM programme starts Dec 2027” or “component not on our SBOM yet” 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: SBOM component / version (or “not listed yet”), advisory identifier, reachability call, exploitation evidence relied on, and when reasonable certainty was reached.
Decision table
| Fact pattern | Article 14 AEV? |
|---|---|
| CVE matched to SBOM row; wrong version / not shipped in SKU | No Art 14(1) for that product (still watch other SKUs) |
| CVE in SBOM + component in product, but vulnerable code not reachable (point 218 shape) | Usually not mandatory Art 14; assess + handle / upstream |
| New scanner alert on SBOM; assessment has not reached reasonable certainty of active exploitation | Triage signal only — not automatic 24h early warning |
| Contained + reachable + assessment reaches reasonable certainty of active exploitation (SBOM complete or not) | Yes — start 24h / 72h AEV chain from awareness |
| Reliable exploitation evidence; component missing from incomplete SBOM | Can still be Art 14(1) — SBOM gap ≠ safe harbour |
| KEV / Critical CVSS / high EPSS / CVE / EUVD / OSV / GHSA only (see sibling guides) | Same product test — catalogue/score/SBOM row ≠ automatic Art 3(42) |
Questions people ask
- Is every 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. An SBOM row (or a scanner match of a CVE to that row) shows a component inventory hit; it does not by itself prove the affected version is shipped, that the code is reachable, or that you have reached reasonable certainty of active exploitation in your product.
- Does the CRA require an SBOM?
- Yes for the vulnerability-handling package — not as an Article 14 filing form. Article 3(39) defines a software bill of materials. Annex I Part II, point (1), requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies of the product. That sits with Article 13 / Annex I conformity (generally from 11 December 2027 under Article 71(2) and FAQ 7.1). It is not the Single Reporting Platform early-warning duty.
- We already ship an SBOM to customers / authorities. Does that satisfy Article 14?
- No. Sharing or retaining an SBOM is inventory and transparency evidence under the vulnerability-handling track. Article 14 is a separate awareness-triggered duty to notify actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. An SBOM does not file a 24-hour early warning, and an SRP filing does not complete Annex I Part II.
- What should a new CVE-in-SBOM scanner alert 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.
- Our SBOM lists a component with a CVE but the vulnerable code is not reachable. 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.
- No SBOM yet / incomplete SBOM 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 your December 2027 SBOM programme is finished. Customer telemetry, researcher reports, your own detection, a CISA KEV listing, a CVE/NVD, EUVD, OSV/GHSA or other reliable exploitation evidence can meet Article 3(42) with no SBOM row. Absence or incompleteness of an SBOM 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 duties generally apply from 11 December 2027 with the rest of the essential cybersecurity requirements (FAQ 7.1). SBOM-driven triage feeds the live reporting duty — it does not postpone Article 14 to the conformity package.