The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to triage vulnerabilities, remediate them on time, and report active exploitation when they become aware of it. The reporting duty in Article 14 applies from 11 September 2026; the vulnerability-handling, remediation, and disclosure duties in Article 13 and Annex I apply from 11 December 2027. The CRA does not name CVSS, EPSS, KEV, or any other scoring system. This page covers what each signal measures, how to combine them into a defensible prioritisation, and how scoring supports vulnerability reporting and coordinated vulnerability disclosure.
Summary
- The CRA does not mandate any scoring system. It requires timely remediation 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 a binary active-exploitation signal that can inform reporting decisions, though the CRA trigger is broader than KEV inclusion.
- CVSS, EPSS, and KEV combined give a defensible prioritisation matrix; no single signal is sufficient on its own.
- Reporting triggers are factual, not score-driven. Active exploitation and severe incidents are determined under the legal definitions, with scoring as supporting evidence.
The four signals that frame CRA severity decisions: inherent severity, exploit probability, the reporting clock, and the date the reporting duty applies.
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 duties are simpler: manufacturers need a vulnerability-handling process that works across the support period, remediates vulnerabilities without delay, and publishes clear severity information when a fix is available.
- Remediation. Address and remediate vulnerabilities without delay, including by providing security updates.
- Public disclosure. Once a security update is available, share a description of the fixed vulnerability, the affected products, the likely impact, the severity, and clear remediation guidance.
Those phrases set a standard, not a fixed number of days. They are interpreted 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 vulnerability-handling regime, see vulnerability handling. For the reporting cadences under the incident-notification regime, 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 v3.1 has three score types:
| Score type | What it measures | CRA use |
|---|---|---|
| Base score | Inherent vulnerability characteristics: attack vector, complexity, privileges required, user interaction, scope, and confidentiality, integrity, and availability impact. | Use as the intake baseline because it is the score most CVE entries publish. |
| Temporal score | Time-varying public context: exploit code maturity, remediation level, and report confidence. | Use when available, but do not depend on it because public CVE entries rarely populate it. |
| Environmental score | Your product context: asset criticality, compensating controls, reachable code paths, and real-world deployment impact. | Use to document why the manufacturer raised, lowered, or deferred a remediation priority. |
CVSS v4.0 was published by FIRST on 1 November 2023. It keeps the Base and Environmental groups, replaces the v3.1 Temporal group with a narrower Threat group focused on exploit maturity, and adds a Supplemental group (including safety, automatable, recovery, and value density) that records context without changing the final score. Adoption is gradual: many 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 exploitation activity against a CVE will be observed 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, observed exploitation activity 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 rise materially, depending on the model's other inputs.
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 list of vulnerabilities with reliable evidence of active exploitation. A CVE is either in the catalog or it is not. CISA adds a CVE when it has reliable evidence that the vulnerability has been exploited against a real target.
KEV is a US-government source. EU manufacturers use it widely because of its broad tooling support. Since 13 May 2025, ENISA also operates the European Vulnerability Database (EUVD), which publishes exploitation status and a dedicated view of exploited vulnerabilities; treat it as an additional EU prioritisation signal alongside KEV. Both are separate from the CRA Single Reporting Platform (Article 16), and neither is itself the Article 14 reporting trigger.
For the early-warning reporting trigger, KEV inclusion is a strong signal that a vulnerability may be "actively exploited" in the regulation's sense. It is not the only signal: the trigger is broader and reaches 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 can still trigger the duty. The determination is factual, not list-based, and requires reliable evidence that a malicious actor exploited the vulnerability without permission.
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 | KEV-listed OR confirmed active exploitation OR (CVSS Critical 9.0+ AND EPSS > 0.5) | Days, not weeks | Urgent reporting review if exploitation may involve 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 with documentation and timestamps |
| 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 a market-surveillance authority a documented, repeatable basis for the remediation decisions it may scrutinise after a serious vulnerability becomes public. A documented policy that bands every CVE on intake, records which band this CVE landed in, and shows it shipped within the matching SLA with timestamps is far easier to defend than "we patched when we got around to it".
Our take: a CVSS-only queue is becoming the audit red flag
The sections above are operational mechanics. The box below is our reading as practitioners, not legal advice.
The current Regulation does not name a scoring system, and we do not expect it to. But the direction of travel is clear. Now that ENISA's EUVD publishes an exploited-vulnerabilities view alongside CISA KEV, exploitation-aware evidence is getting harder for authorities to ignore: "we prioritised by CVSS and missed the one that was being exploited" is a weaker answer every quarter. We expect market-surveillance authorities and CSIRTs to read an EPSS-and-KEV-aware process as the floor of a competent vulnerability-handling regime, not an advanced option. Build for where enforcement is heading, and you are scoring for exploitation likelihood, not just severity.
Mapping severity to reporting triggers
Reporting is not score-driven. The incident-notification regime splits into two streams with the same 24-hour and 72-hour clocks but different final-report deadlines:
- Actively exploited vulnerability. 24-hour early warning, 72-hour vulnerability notification, 14-day final report from when a corrective or mitigating measure is available.
- Severe incident. 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: there is reliable evidence that a malicious actor exploited the vulnerability without permission. A severe incident is one that can affect the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or that can lead to malicious code being introduced or run in the product or in a user's networks and information systems.
CVSS and EPSS support the determination. A CVSS-Critical vulnerability with EPSS > 0.9 and a KEV listing should trigger an urgent reporting review once you have evidence that exploitation may involve 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 reporting 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, re-band it (High, or Emergency if CVSS is also 9.0+). When KEV adds one of your CVEs, or 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 expected without-delay remediation 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 reporting trigger. The reporting duty turns 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. The disclosure obligation 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 can work 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 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 24-hour clock?
It does not change when the clock starts. The clock starts when the manufacturer becomes aware of an actively exploited vulnerability, 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 final.
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 "without delay" standard. The industry default of CVSS plus EPSS plus KEV is the path of least resistance because it is widely recognised.
Does the CRA penalise a wrong severity score?
Not directly. The penalty risk is failure to meet the vulnerability-handling requirements or failure to report active exploitation. A wrong individual score is not automatically a violation, but an absent or inconsistent scoring process can become evidence that vulnerability handling was not effective.
Should we use CVSS v3.1 or v4.0?
Both, where available. CVSS v4.0 was published by FIRST on 1 November 2023. It keeps Base and Environmental, replaces the Temporal group with a narrower Threat group focused on exploit maturity, and adds a Supplemental group (including safety, automatable, recovery, and value density) that records context without changing the score. Adoption is gradual: many public CVE feeds still publish v3.1. Ingest both signals where the source provides them, and do not treat the v3.1 to v4.0 transition as a backlog re-baseline.
When do these reporting obligations start applying?
Article 14, which contains the reporting obligations described on this page, applies from 11 September 2026. The CRA's vulnerability-handling, remediation, and disclosure duties in Article 13 and Annex I apply from 11 December 2027, and the bulk of the Regulation applies from that later date. Build the scoring and reporting-readiness process now so it is operational before September 2026.
What counts as "becoming aware" for the 24-hour clock?
The 24-hour early-warning clock starts when the manufacturer becomes aware of an actively exploited vulnerability. That means credible knowledge that a malicious actor has exploited the flaw against a real target, not a private vulnerability report or a working proof-of-concept on its own. A CVSS or EPSS score does not start the clock; the factual determination of active exploitation does.
How should we use the ENISA EUVD alongside CISA KEV?
Since 13 May 2025, ENISA operates the European Vulnerability Database (EUVD), which publishes exploitation status and a dedicated view of exploited vulnerabilities. Use it as a prioritisation signal alongside CISA KEV. Neither catalog is the Article 14 reporting trigger, and both are separate from the CRA Single Reporting Platform under Article 16.
Does VEX change CRA severity or reporting?
No. A VEX (Vulnerability Exploitability eXchange) document does not change the reporting trigger or the inherent severity of a vulnerability. It is a machine-readable way to record whether your product is actually affected by a known vulnerability (affected, not affected, under investigation, or fixed) alongside your SBOM. That makes it strong supporting evidence for an environmental down-scoring or a documented deferral.
Should we use SSVC instead of a CVSS matrix?
You can. SSVC (Stakeholder-Specific Vulnerability Categorization), published by CISA with Carnegie Mellon's SEI, is a decision-tree alternative that reaches a remediation decision (Track, Track*, Attend, Act) from inputs such as exploitation status, exposure, and mission impact. The CRA does not require it. It is a recognised, defensible framework if you prefer a decision tree to the CVSS-plus-EPSS-plus-KEV matrix on this page.