The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to remediate vulnerabilities "without delay" (Annex I Part II point 2) and to report actively exploited ones within 24 hours (Article 14(1)), but names no scoring system. CVSS, EPSS, and the CISA KEV catalog are the industry tools used to meet those duties. This page covers what each measures, how to combine them into a defensible prioritisation, and how scoring connects to Article 14 reporting and coordinated vulnerability disclosure.
Summary
- The CRA does not mandate any scoring system. Annex I Part II point (2) requires remediation "without delay" but leaves the operational measurement to manufacturers.
- CVSS measures inherent severity on a 0 to 10 scale: vulnerability characteristics independent of whether exploitation is observed in the wild.
- EPSS measures exploit likelihood on a 0 to 1 scale: probability of observed exploitation within the next 30 days, calculated by the FIRST EPSS Special Interest Group.
- CISA KEV is the binary "actively exploited" signal that most directly informs Article 14(1) reporting decisions, though Article 14(1) is broader than KEV inclusion.
- CVSS, EPSS, and KEV combined give a defensible prioritisation matrix; no single signal is sufficient on its own.
- Article 14 reporting triggers are factual, not score-driven. Active exploitation and severe incident are determined under the legal definitions, with scoring as supporting evidence.
The four numbers that frame CRA severity decisions: inherent severity, exploit probability, the reporting clock, and the penalty ceiling.
What the CRA says about scoring
Read the regulation directly and you will find no mention of CVSS, EPSS, or any other named scoring system. The relevant operational language is in Annex I Part II, which lists the vulnerability handling requirements every manufacturer must meet across the support period:
- Point (2) requires manufacturers to "address and remediate vulnerabilities without delay, including by providing security updates".
- Point (4) requires that, once a security update is available, manufacturers share information about the fixed vulnerability "including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities".
Article 13(8) places these duties under a "handled effectively" obligation across the support period. The phrase "without delay" in Annex I Part II point (2) and "without undue delay" in Article 14 set the temporal standard. Neither phrase is a fixed number of days. Both are subject to interpretation by market-surveillance authorities and, ultimately, by national courts.
Scoring is how manufacturers demonstrate that interpretation in audits and investigations. A manufacturer who can show a documented severity policy, a tracking system that records CVSS and EPSS at intake, an SLA tied to severity bands, and remediation timestamps that respect those SLAs has a defensible "without delay" position. A manufacturer who cannot does not.
For the broader Annex I Part II handling regime, see vulnerability handling. For the Article 14 reporting cadences, see vulnerability reporting.
CVSS: inherent severity
The Common Vulnerability Scoring System, maintained by the FIRST CVSS Special Interest Group, scores a vulnerability on a 0.0 to 10.0 scale. It is the dominant inherent-severity score in the industry and the score most CVE entries publish.
CVSS has three score types:
Captures vulnerability characteristics that do not change over time or across deployments: attack vector, complexity, privileges required, user interaction, scope, and impact on confidentiality, integrity, and availability. This is what most CVE entries publish and what people mean by "the CVSS score".
Adjusts the Base score for time-varying factors: exploit code maturity, remediation level, report confidence. Rarely populated in public CVE entries.
Adjusts the Base score for your deployment context: asset criticality, compensating controls, real-world impact in your environment. This is the score a manufacturer should compute for their own product.
CVSS v4.0 was published by FIRST in November 2023. It refines v3.1 with finer attack-requirement metrics and supplementary metrics for safety, automatable, recovery, and value density. Adoption is gradual: most CVE feeds still publish v3.1, and tooling support for v4.0 is uneven. Ingest both where available and do not treat the transition as a backlog re-baseline.
CVSS alone is insufficient. Empirical research consistently shows that most vulnerabilities scored "high" or "critical" by CVSS are never observed to be exploited. A pure CVSS-driven queue burns engineering capacity on theoretical risk while real exploitation goes unaddressed.
EPSS: exploit likelihood
The Exploit Prediction Scoring System, also maintained by FIRST through its EPSS SIG, predicts the probability that a CVE will be exploited in the wild within the next 30 days. EPSS publishes a probability between 0 and 1 and a percentile rank against all CVEs.
EPSS is calculated by a machine-learning model that ingests CVE attributes (CVSS metrics, CWE, affected vendor and product, age) and public signals (PoC availability, exploitation telemetry from contributing partners, threat-intelligence mentions). Scores are refreshed daily. A new CVE with no public PoC typically scores below 0.05; one with a weaponised PoC can move above 0.5 within days.
EPSS alone is also insufficient. A low EPSS today is not a guarantee for tomorrow: when a researcher publishes a working exploit, the score moves. EPSS must be re-evaluated continuously, not at intake only.
CISA KEV: confirmed exploitation
The Known Exploited Vulnerabilities catalog, maintained by the US Cybersecurity and Infrastructure Security Agency, is a binary "is this currently being exploited" list. A CVE is either in the catalog or it is not. CISA adds a CVE when it has reliable evidence of active exploitation against any target.
KEV is a US-government source, but it is the most authoritative public catalog of confirmed exploitation available to non-intelligence-community defenders. EU manufacturers use it widely because no equivalent ENISA catalog exists today.
For Article 14(1) purposes, KEV inclusion is a strong signal that a vulnerability is "actively exploited" in the regulation's sense. It is not the only signal: Article 14(1) is broader and triggers on any actively exploited vulnerability, including ones detected through customer reports, internal telemetry, or threat intelligence that has not yet reached CISA. A vulnerability that is being exploited against your customers but is not yet in KEV still triggers Article 14(1). The Article 14(1) determination is factual, not list-based.
Combining CVSS, EPSS, KEV into a CRA prioritisation matrix
No single signal is enough. The defensible approach is to combine all three and tie remediation SLAs to the combined band. The diagram below shows why: a CVSS-9.8 with no observed exploitation is lower real-world risk than a CVSS-7 with EPSS 0.95 and KEV listing, even though the first looks worse on a CVSS-only queue.
| Band | Signal combination | Remediation SLA | CRA implication |
|---|---|---|---|
| Emergency | CVSS Critical (9.0+) AND (KEV-listed OR EPSS > 0.5) | Days, not weeks | Article 14(1) reporting candidate if exploitation is against your product |
| High | CVSS High (7.0-8.9) OR EPSS > 0.5 | 30 days | "Without delay" position is at risk above 30 days |
| Medium | CVSS Medium (4.0-6.9), EPSS < 0.5, not KEV-listed | 90 days | Defensible under Annex I Part II point (2) with documentation |
| Low | CVSS Low (< 4.0) | Next regular release cycle | Document the deferral in the vulnerability handling record |
The matrix is the manufacturer's policy, not a CRA requirement. Writing it down gives market-surveillance authorities a documented, repeatable basis for the remediation decisions they will scrutinise after a serious vulnerability becomes public. Authorities will not accept "we patched when we got around to it" as an Annex I Part II point (2) defence; they will accept "our policy bands every CVE on intake, this CVE landed in the High band, we shipped within the 30-day SLA, here are the timestamps".
Mapping severity to Article 14 reporting triggers
Article 14 splits into two streams with the same 24-hour and 72-hour clocks but different final-report deadlines:
- Actively exploited vulnerability (Article 14(1) and 14(2)). 24-hour early warning, 72-hour vulnerability notification, 14-day final report from when a corrective or mitigating measure is available.
- Severe incident (Article 14(3) and 14(4)). 24-hour early warning, 72-hour incident notification, 1-month final report from the 72-hour notification.
Neither trigger is a CVSS threshold. "Actively exploited" is a factual determination: a malicious actor has used the vulnerability against your product. Article 14(5) defines a "severe incident" as one that "negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions" or that "has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user".
CVSS and EPSS support the determination. A CVSS-Critical vulnerability with EPSS > 0.9 and a KEV listing strongly suggests Article 14(1) territory once you have evidence the exploitation is against your product. They do not replace the determination. The 24-hour clock anchors at the moment the manufacturer becomes aware of active exploitation, not at the moment the CVSS score crosses any number.
For the full Article 14 cadence, see vulnerability reporting. For the upstream intake channel that often produces the first signal of exploitation, see coordinated vulnerability disclosure.
Operationalising scoring in your vulnerability process
A working CRA-aligned scoring process has six concrete components:
- Ingest CVSS at scan time. Your SBOM-to-CVE pipeline should attach CVSS Base scores to every finding on first detection. See SBOM for the underlying mapping mechanics.
- Refresh EPSS daily. A nightly job that re-scores open vulnerabilities is the minimum.
- Watch CISA KEV. Subscribe to the KEV feed and auto-escalate any open vulnerability that enters the catalog.
- Set per-band SLAs in your tracking system. Bands and deadlines must be machine-readable so overdue items surface without human triage.
- Escalate on threshold crossings. When EPSS crosses 0.5 for an open finding, when KEV adds one of your CVEs, or when a customer reports active exploitation, the item moves to the emergency band automatically.
- Automate the SBOM-component-to-CVE mapping. Manual mapping breaks at scale and is the most common source of missed vulnerabilities in audit findings.
Onboarding to the ENISA Single Reporting Platform is a separate but related workstream. See ENISA SRP onboarding.
Common pitfalls
- Chasing CVSS-9 while ignoring EPSS-0.95. A CVSS-7 vulnerability with EPSS 0.95 and a public PoC is a higher real-world risk than a CVSS-9.8 with EPSS 0.01.
- Assuming KEV is complete. KEV is the best public catalog, but it lags. Active exploitation against your customers can precede KEV listing by days or weeks.
- Treating CVSS as a deadline. A CVSS Critical does not mean "patch in 24 hours". It means "look at this first". The deadline comes from your policy SLA, the EPSS, the KEV status, and ultimately the Annex I Part II point (2) "without delay" standard.
- Failing to refresh EPSS scores. A vulnerability scored EPSS 0.02 at intake and never re-scored will sit in your low-priority backlog while real exploitation builds outside your view.
- Ignoring CVSS Environmental modifiers. A CVSS Base score of 9.8 against a component your product never instantiates is not a 9.8 in your environment. Document the Environmental score and the reasoning.
- Using CVSS or EPSS as the Article 14 trigger. Article 14(1) triggers on factual active exploitation. A score is supporting evidence, not the determination.
Frequently Asked Questions
Does the CRA require us to use CVSS?
No. The CRA does not name CVSS or any other scoring system. Annex I Part II point 4 requires you to communicate "severity" when you disclose a fixed vulnerability, but it does not specify the scale. CVSS is the industry default and the easiest scale to defend in audit. A custom or alternative scale that produces equivalent operational outcomes is permissible if it is documented and applied consistently.
Is EPSS mandatory under the CRA?
No. EPSS is not mentioned in the regulation. It helps demonstrate the "without delay" standard in Annex I Part II point 2 because it shows that prioritisation tracked real-world exploitation likelihood, not just inherent severity. A manufacturer who ignores exploit likelihood and patches purely by CVSS rank will struggle to justify slow remediation of a high-EPSS finding after the fact.
How does scoring affect the Article 14 24-hour clock?
It does not change when the clock starts. The clock starts at manufacturer awareness of active exploitation, regardless of CVSS. Scoring helps triage which inbound signals reach the awareness threshold, but once exploitation is credibly established the clock runs even if the CVSS score is not yet finalised.
Can we use a custom scoring system?
Yes, provided you can defend it in audit. A scheme that combines internal threat-model context with external signals is acceptable if it is documented, applied consistently, and produces remediation outcomes that align with the Annex I Part II point 2 "without delay" standard. The industry default of CVSS plus EPSS plus KEV is the path of least resistance because every market-surveillance authority will recognise it.
Does the CRA penalise a wrong severity score?
The CRA penalises failure to handle vulnerabilities effectively (Annex I Part II) and failure to report under Article 14. A defensible scoring policy with documented application is what shields the manufacturer. A wrong individual score is not a violation; an absent or inconsistent process is.
Should we use CVSS v3.1 or v4.0?
Both, where available. CVSS v4.0 was published by FIRST in November 2023 and refines v3.1 with finer attack-requirement metrics and supplementary metrics for safety, automatable, recovery, and value density. Adoption is gradual: most public CVE feeds still publish v3.1, and tooling support for v4.0 is uneven. Ingest both signals where the source provides them, and do not treat the v3.1 to v4.0 transition as a backlog re-baseline.