Correlation · deep dive

EPSS vs. CVSS vs. KEV: three signals, three questions

Three scores get treated as if they measured the same thing. They don’t. CVSS is severity, EPSS is probability, KEV is observed exploitation. Read them as one number and your queue ranks theory over reality. Read them as three and you prioritise what actually matters for the CRA.

Updated 7 Jul 2026·~5 min read·For product security engineers

Every vulnerability queue has to be ordered somehow, and most are ordered badly — because the three numbers teams reach for measure three different things, and using any one of them alone gives a misleading ranking.

Three questions, not one

SignalQuestionScaleSource
CVSSHow severe if exploited?0–10FIRST / NVD
EPSSHow likely to be exploited soon?0–1FIRST
KEVIs it being exploited now?yes / noCISA

CVSS — how bad it would be

The Common Vulnerability Scoring System rates the impact and exploitability characteristics of a flaw on a 0–10 scale. It answers "if this were exploited, how bad is it?" It says nothing about whether anyone will, or is. A CVSS 9.8 is a loud number, but on its own it's a statement about a hypothetical.

EPSS — how likely it is

The Exploit Prediction Scoring System estimates, as a probability between 0 and 1, how likely a vulnerability is to be exploited in the near term. It's data-driven and updated over time. EPSS is the axis CVSS is missing: it separates the severe-and-likely from the severe-but-ignored. It is still a prediction, though — useful for triage, not proof of anything.

KEV — whether it's actually happening

The CISA Known Exploited Vulnerabilities catalogue is different in kind: it isn't a score, it's a record. An entry means there is evidence the vulnerability has been exploited in the wild. KEV replaces prediction with observation, which is precisely why it, and not the two scores, is the signal tied to the CRA's reporting trigger.

Reading them together

Used together they turn a flat list into a real priority order. A rough hierarchy: KEV-listed and reachable in your product sits at the top — that's a candidate for the reporting clock. Then high EPSS, especially with high CVSS, as the things most likely to become KEV entries. CVSS then breaks ties on impact. What you never do is sort by CVSS alone and work down — that buries an exploited 6.5 under a stack of theoretical 9s.

Severity is how bad it would be. EPSS is how likely. KEV is that it's happening. Only the last starts a CRA clock.

Where all three sit in the flow from SBOM to a filed report is covered in the correlation pillar; which one legally starts the clock is in what counts as actively exploited.

Frequently asked

What is the difference between EPSS and CVSS?

CVSS scores how severe a vulnerability would be if exploited, from 0 to 10. EPSS estimates the probability that it will be exploited in the near term, from 0 to 1. Severity and likelihood are different axes: a high-CVSS vulnerability can have a low EPSS, and vice versa.

Should I prioritise by CVSS?

Not alone. CVSS ignores whether a vulnerability is likely to be, or is being, exploited. A CVSS 6.5 in the KEV catalogue is a higher operational priority than a CVSS 9.8 nobody is exploiting. Combine severity with EPSS and KEV.

Which signal triggers CRA reporting?

Only KEV-style evidence of active exploitation. CVSS and EPSS inform prioritisation but do not start the CRA clock — the clock starts on reliable evidence that a vulnerability affecting your product is being exploited in the wild.

Design partners

Rank by real risk, not theoretical severity.

See a matched CVE set scored by CVSS, EPSS and KEV together — and then narrowed to what actually reaches your product.