CVSS vs EPSS: severity is not the same as risk

What CVSS measures

The Common Vulnerability Scoring System (CVSS) is FIRST’s specification for the intrinsic severity of a vulnerability. In CVSS v4.0, the base score is assembled from exploitability metrics – attack vector, attack complexity, attack requirements, privileges required, user interaction – and impact metrics covering confidentiality, integrity and availability. Nothing on that list is about your network. It describes the flaw.

The design is right for describing consequence and wrong for deciding sequence. A Base score describes intrinsic characteristics and can be corrected when information changes: it does not know whether a working exploit exists, whether the component is reachable, or whether anyone has ever attacked it. CVSS v4.0 does define a supplemental metric called Automatable, but supplemental metrics sit outside the base score, so they never move the number your scanner sorts on.

What EPSS measures

The Exploit Prediction Scoring System (EPSS) is maintained by the EPSS Special Interest Group at FIRST, with scores generated by Empirical Security and published free. It answers one question: what is the estimated likelihood that exploitation activity for a given vulnerability will be observed across EPSS data partners in the next 30 days? It is recomputed daily.

The load-bearing word is calibrated. FIRST states it plainly: CVEs scoring near 5% are exploited approximately 5% of the time in aggregate, and CVEs scoring near 30% are exploited approximately 30% of the time. CVSS offers no equivalent guarantee – it is an ordinal ranking, so 9.8 sits above 4.9 but is not twice anything.

Underneath, EPSS is an XGBoost classifier over approximately 2,800 to 2,850 features, trained on roughly 120 million rows of historical data against more than 1.6 million daily observations of exploitation activity. Training is positive-unlabeled: a CVE with no observed exploitation is treated as unknown, not as confirmed not-exploited. The implementation and training schedule change over time; consult FIRST’s current model documentation.

EPSS is not a live attack feed. Exploitation activity trains the model but is not used in the daily scoring. A score of 0.6 does not mean an attack is under way; it means vulnerabilities that look like this one are exploited about 60% of the time in a 30-day window.

The two scores side by side

“Severity versus probability” is too coarse to settle an argument. What decides a policy is the time horizon, the scale type and the population each score selects.

CVSS and EPSS compared

	CVSS	EPSS
What it measures	Intrinsic severity on a 0–10 scale	Probability that exploitation activity is observed in the next 30 days
Time horizon	Intrinsic characteristics; update when evidence changes	Rolling 30 days, recomputed daily
Scale type	Ordinal ranking, no empirical calibration	Calibrated probability
Maintained by	FIRST – CVSS v4.0 specification	EPSS SIG at FIRST; scores generated by Empirical Security
Knows about your environment	Base: no; Environmental metrics can add local context	No
Population it selects	High and above ≈ top 48%; Critical just over 10%	≥0.04 (90th percentile) selects a Critical-sized population

Translating a CVSS threshold into an EPSS threshold

The numerical thresholds below are examples from the cited FIRST guidance, not permanent percentile mappings or universal remediation deadlines. Check the current score distribution before using them. The usual objection to EPSS is procedural, not technical: our policy says fix Critical, and EPSS has no Critical. FIRST answers with an effort equivalence. If your programme currently treats CVSS Critical as the action threshold, the EPSS equivalent effort level is approximately the 90th percentile – a score of 0.04 or higher, a 4% probability of exploitation.

That equivalence is what makes the switch sellable. Over the last 12 months about 61,000 CVEs were published and just over 10% were rated CVSS Critical, so a 90th-percentile EPSS filter selects a population of roughly the same size – the same volume of work, on a set chosen by threat data.

The same translation exists one rung down: if your programme acts on CVSS High and above – approximately the top 48% of published vulnerabilities – the equivalent EPSS threshold is around 0.008, or 0.8%.

Low absolute scores are normal. In any given 30-day period FIRST tracks exploitation activity on between 1.5% and 3% of published vulnerabilities; the mean EPSS score is around 2.8% and the median around 0.7%. Against that base rate, 0.04 sits well above the middle.

Probabilities also aggregate in a way ordinal scores cannot. Take 100 vulnerabilities each scoring 0.05. If their exploitation events were independent, the probability that at least one is exploited in the next 30 days would be approximately 99.4% – 1 − ∏(1 − p) – and the expected number exploited is five. Real vulnerabilities can have correlated exploitation events, so 99.4% is an illustrative independence calculation, not a calibrated estimate for your backlog or an attack on your organisation.

When the two scores disagree

Severity and estimated exploitation probability describe different dimensions. The combinations below suggest triage questions, not automatic remediation deadlines. Confirm affected versions, reachability, asset impact and binding requirements before deciding.

Severity against probability

	Low EPSS	High EPSS
High CVSS	High technical severity with a lower forecast. Check exposure and impact promptly; a low EPSS score does not establish difficult exploit conditions or justify delay by itself.	High severity and an elevated forecast warrant prompt investigation. Prioritise applicable, reachable instances and act according to impact and policy.
Low CVSS	Review applicability, exposure, chained effects and policy; keep scores current. Two low scores do not prove that a system is safe.	Lower technical severity with an elevated forecast. Check business impact and possible attack chains; urgency still depends on the affected environment.

Score laundering: the mistake FIRST names

One way of combining them looks sophisticated and destroys the information in both. FIRST gives it a name.

Do not multiply an EPSS score by an ordinal (such as CVSS) and think that produces a combined “risk score.” EPSS is a calibrated probability; CVSS scores are an ordinal ranking with no empirical calibration. The product has no interpretable meaning.– FIRST, Using EPSS

A blended score of 6.4 cannot be checked: you cannot say what it predicts, and two findings with the same number can carry very different probabilities of attack. Keep them as separate columns – probability to select what enters the queue, severity to describe the consequence. “Twelve findings above the 90th EPSS percentile, four with total technical impact” is a sentence an executive can act on.

Neither score knows your network

Both scores describe the vulnerability, not your instance of it. FIRST frames the missing context as three questions. Presence: do you run the affected component and version? Reachability: can an attacker reach and exploit it, given exposure, authentication and compensating controls? Consequence: what is the asset worth?

The intersection of a high EPSS score with confirmed presence, confirmed reachability, and high consequence is where remediation effort produces the most risk reduction.– FIRST, Using EPSS

That intersection is the entire job, and no public score can do it for you. Our prioritisation playbook turns it into a routing table with clocks attached, so the three questions become fields on a ticket rather than a meeting, and the triage tool walks one finding through them.

Where KEV fits

The third input in most triage stacks is not a score. FIRST draws the line cleanly: KEV lists vulnerabilities with confirmed exploitation; EPSS is a forward-looking probability estimate for the next 30 days. One is a record of history, the other a forecast.

So a low EPSS score on a CISA KEV entry is not a contradiction. When a vulnerability appears on KEV, retain the known-exploitation evidence regardless of EPSS. One nuance belongs in the tooling: the signal degrades with age, and an entry added years ago reverts toward the probability its current features would otherwise predict.

What to change first

1. Compare an EPSS-percentile and KEV view with your existing severity queue before changing policy. Retain severity, asset impact and binding remediation requirements.
2. Delete any blended severity × probability score; show two columns.
3. Re-pull EPSS daily. A month-old score forecasts a window that has closed.
4. Record presence and reachability first – a high probability on software you do not run is not a finding.