Stop asserting not_affected. Prove it.
The CRA makes you report actively exploited vulnerabilities within 24 hours — and stand behind every component CVE you decide not to report. ProvenVEX works out whether each CVE is genuinely reachable and exploitable in your product, then attaches the evidence. Reachability and exploitation proof, in place of a best guess.
Deserialization of untrusted data in a bundled document-parsing library.
A scan report was never going to be enough.
Regulation (EU) 2024/2847 turns product security into an ongoing obligation with real teeth. Three parts of it decide how much work lands on your desk.
24 hours to first warning
From 11 September 2026 you report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a fuller notification within 72, a final report within 14 days — through the ENISA Single Reporting Platform to your coordinating CSIRT.
Documented, not asserted
The CRA expects triage decisions with a written rationale and machine-readable advisories. A CVE list from a scanner does not clear that bar. When a market-surveillance authority asks why you didn't report something, "we judged it not affected" is not an answer.
€15M or 2.5%
Maximum administrative fines reach €15 million or 2.5% of worldwide annual turnover, whichever is higher. The reporting obligation is the first part of the CRA that a regulator can actually enforce.
Finding the CVEs was never the hard part — the open-source stack does that for free, and the SBOM itself is commodity. The expensive question is which of those CVEs actually matter in your product, and whether you can prove the answer. Industry consensus is that the 24-hour obligation is only half-solvable by tools: the alerting automates, but assessing whether the product is really affected has stayed a human task. That is the task ProvenVEX takes on.
From your SBOM to a decision you can defend.
One pipeline, per product and per version. Cheap checks run first; the expensive exploitation work only fires where it's warranted — which keeps the answer fast and the cost bounded.
Take in the inventory
Ingest an existing SBOM or generate one from your build. CycloneDX, SPDX and SWID, versioned per release and stored immutably.
Correlate against the sources that matter
Match every component to the NVD, the EU Vulnerability Database, OSV and the CISA KEV catalog, with an EPSS and CVSS signal on each finding. Deduplicated, source-attributed, and dated to the snapshot. Nothing is dropped silently.
Check reachability
Is the vulnerable code path actually present, and can it be reached from an entry point? A static pass answers this cheaply and rules out the noise before any heavy work runs.
Prove exploitabilitythe moat
For candidates that are both reachable and under active exploitation, the engine attempts exploitation in your product's context and captures the result. Where it succeeds, you get a proof artifact. Where it fails, that failure is itself the evidence behind a not_affected.
Emit evidence-backed VEX
Each determination becomes a VEX record — not_affected, affected, fixed or under_investigation — carrying its rationale and a link to the evidence, in CycloneDX VEX and OpenVEX. Reportability candidates are surfaced with their proof; the decision to report stays yours. Everything lands in an immutable evidence bundle, retained for ten years.
Everyone can annotate a VEX file. Almost nobody can back it.
This is the whole difference, stated plainly. It's also the difference between a claim a regulator waves through and one they don't.
A human writes it down
Someone reads the CVE, forms a view, and types a status into a VEX document. SBOM and SCA tools help you record that view and export it. They stop at the point that actually matters.
- not_affected
- Justified by judgement. Unverifiable, and hard to reconstruct months later.
- When an authority asks "on what basis?", the honest answer is a signature.
The engine demonstrates it
Every status is the output of a determination, with the artifact attached. The same VEX formats — a different thing underneath them.
- not_affected because the vulnerable path isn't reachable, or exploitation was attempted and couldn't trigger it.
- affected because exploitation was demonstrated, with a captured proof.
- A determination you can hand to an auditor. Not an opinion you'd have to defend.
Less to report. Everything defensible.
The reporting load drops
A CVE proven not reachable in your product carries no reporting obligation — and now that call is backed by evidence, not asserted. The 24-hour clock starts on the things that genuinely qualify, not on inventory noise.
You can answer "on what basis?"
Every not_affected travels with its reachability trace and exploitation attempt. When a reasoned request arrives, the evidence is already assembled.
Audit-ready for a decade
SBOMs, correlations, determinations, VEX records, proofs and triage rationale sit in one immutable, timestamped bundle per product and version — the thing a scan report can never be.
Cost that stays bounded
Static reachability is cheap and runs first. Exploitation runs — the expensive part — fire only on reachable, actively-exploited candidates. No brute-force replay against your whole inventory.
Manufacturers of products with digital elements.
Software vendors, IoT and embedded, connected devices, OT — anyone placing a product with digital elements on the EU market.
Own vulnerability handling for what you ship. See which component CVEs are actually exploitable, and run triage without drowning in the ones that aren't.
Personally accountable under the CRA. Run a defensible programme with a thin team, and hold evidence you can stand behind.
Own the evidence trail, classification and Declaration of Conformity. Get audit-ready documentation and retention, assembled from real evidence.
Small team, no compliance department? See CRA compliance for SMEs →
The CRA, answered straight.
What counts as "actively exploited" under the CRA?
A vulnerability is actively exploited when there is reliable evidence that it has been exploited in the wild — for example, a listing in the CISA Known Exploited Vulnerabilities catalogue or comparable threat intelligence. A public proof-of-concept on its own does not meet that bar, which is exactly why exploitation evidence, rather than a CVE's mere existence, is what should start the clock.
Does a vulnerability scan report satisfy the CRA?
No. The regulation expects documented triage decisions with rationale and structured, machine-readable advisories as evidence. A scanner tells you a component has a CVE; the CRA asks whether that CVE affects your product and what you decided about it.
What is evidence-backed VEX?
VEX (Vulnerability Exploitability eXchange) is the standard way to state whether a known vulnerability affects a product. Evidence-backed VEX means each status is justified by machine-generated evidence — reachability analysis and an exploitation attempt — instead of a human assertion. The format is standard CycloneDX VEX or OpenVEX; what changes is that a not_affected carries proof.
Is the ENISA Single Reporting Platform live yet?
As of mid-2026, the platform is not yet operational and exposes no API. ProvenVEX generates SRP-aligned structured exports and supports dry-runs and tabletop exercises, and will submit directly once an interface exists.
Do we need a notified body?
Most products fall in the default class and self-assess under Module A — no notified body required, though a full technical file and Declaration of Conformity must still be in place and kept for ten years. ProvenVEX assembles that evidence for the self-assessment route, and a preparation package for important and critical-class products.
When are the deadlines?
Vulnerability and incident reporting obligations apply from 11 September 2026. The full baseline — SBOM, secure-by-design, vulnerability handling across the support period, technical documentation, Declaration of Conformity and CE marking — applies from 11 December 2027.
September isn't moving. Neither is the 24-hour clock.
Bring one product. We'll ingest its SBOM, correlate it, and come back with an evidence-backed VEX and a reportability shortlist — so you can see, on your own code, which CVEs you'd actually have to report.
Limited design-partner slots · EU-hosted · no scanner rip-and-replace required