Vulnerability Management Under the CRA: EPSS, CVSS, and VEX
CRA requires manufacturers to handle vulnerabilities without undue delay. Here's how to prioritise using EPSS and CVSS, and how VEX statuses communicate exploitability to your customers.
The EU Cyber Resilience Act's Annex I Part II requires manufacturers to "handle vulnerabilities without undue delay" and to "put in place a coordinated vulnerability disclosure policy." In practice, this means manufacturers need a structured, evidence-based process for evaluating and prioritising security vulnerabilities affecting their products. Two scoring systems — CVSS and EPSS — and a disclosure format called VEX are the tools that make this tractable.
CVSS vs EPSS: Two Different Questions
CVSS (Common Vulnerability Scoring System) measures the intrinsic severity of a vulnerability — how bad could it be if exploited? A CVSS 9.8 vulnerability has a large attack surface, no authentication required, and complete compromise of confidentiality, integrity, or availability. CVSS does not tell you how likely exploitation is; it tells you the worst-case impact.
EPSS (Exploit Prediction Scoring System) measures the probability that a vulnerability will be exploited in the wild within the next 30 days, based on threat intelligence, PoC availability, and historical patterns. A CVSS 9.8 vulnerability with an EPSS score of 0.02 (2%) is severe but not currently being targeted. A CVSS 5.0 vulnerability with EPSS 0.85 (85%) is being actively exploited despite its moderate severity score.
For CRA compliance, the combination matters. The CRA's "without undue delay" standard doesn't mean you must patch every CVE immediately — it means you must have a defensible, risk-based prioritisation process. Using EPSS alongside CVSS lets you make that case: high-EPSS vulnerabilities get immediate attention regardless of CVSS; low-EPSS, low-CVSS vulnerabilities can be batched into scheduled updates with documented rationale.
The EU Vulnerability Database (EUVD)
From September 2026, ENISA will operate the EU Vulnerability Database (EUVD) as the authoritative source for vulnerability data relevant to CRA-covered products. Manufacturers are encouraged to correlate their SBOM components against the EUVD (in addition to NVD and OSV) to identify relevant CVEs.
The EUVD will include both publicly known vulnerabilities and those reported directly to ENISA under Article 14. For manufacturers, this means your SBOM-to-vulnerability correlation workflow needs to query the EUVD once it is operational.
VEX: Communicating Exploitability to Customers
Once you've assessed a vulnerability's applicability to your product, you need a way to communicate that assessment to customers and downstream users. This is where VEX (Vulnerability Exploitability eXchange) comes in.
A VEX document attaches an exploitability status to a CVE in the context of your specific product. The four VEX statuses are:
| VEX Status | Meaning |
|---|---|
| affected | The vulnerability is present and exploitable in this product version |
| not_affected | The vulnerable component is present but the vulnerability is not exploitable (with justification) |
| fixed | A patch has been issued that resolves the vulnerability |
| under_investigation | You are aware of the vulnerability and actively assessing exploitability |
The not_affected status requires a justification. Common justifications under VEX include: the vulnerable code path is never executed in this product configuration, the product uses the component in a way that doesn't expose the vulnerability, or the vulnerable functionality has been disabled.
CycloneDX 1.6 supports VEX data natively within the SBOM format, which is another reason it's preferred for CRA compliance. Your SBOM can carry both the component inventory and the vulnerability assessments in a single document.
Building Your Vulnerability Management Process
A CRA-compliant vulnerability management process should include: automated SBOM generation at each release, continuous correlation of SBOM components against CVE databases, EPSS-enriched triage to prioritise remediation, VEX document generation for each assessed vulnerability, and a documented escalation path to Article 14 incident reporting when an actively exploited vulnerability is discovered.
The Article 14 trigger — reporting an actively exploited vulnerability — is distinct from standard patch management. A vulnerability being exploited in the wild is an incident requiring the 24-hour / 72-hour reporting chain, not just a ticket in your backlog.
Ready to assess your CRA compliance obligations?
Try the Free Applicability Checker