What is the difference between CVSS and EPSS?

CVSS answers how severe the impact would be if a vulnerability were exploited: it scores the flaw's characteristics, such as whether it needs authentication and what it does to confidentiality, integrity and availability. EPSS answers how likely exploitation is, expressed as the probability that a CVE will be exploited in the wild within the next 30 days. One is a severity model, the other a likelihood model, and a full risk picture needs both plus your own exposure.

Should I stop using CVSS?

No. Stop using it alone as a queue-sorting key. CVSS remains the right tool for describing how damaging a flaw is, which matters when deciding what to do about a vulnerability on a critical system. What it cannot tell you is whether anyone will ever attack it, and using severity as a proxy for likelihood is what produces backlogs of tens of thousands of items.

What does an EPSS score of 0.7 mean?

An estimated 70 percent probability that the CVE will be observed being exploited in the wild in the next 30 days. It is published alongside a percentile that shows where that score ranks against every other scored CVE, which is often the more useful figure for setting a threshold, because absolute probabilities across the whole catalogue are low.

How do KEV, EPSS and CVSS fit together?

In that order. If a CVE is on CISA's Known Exploited Vulnerabilities catalogue, exploitation is observed fact and it goes to the front regardless of the other two. If not, EPSS gives the best available estimate of near-term exploitation, which you weight by whether the affected asset is reachable. CVSS then tells you how much damage a successful exploit would do, which decides urgency on your most critical systems even when likelihood is low.

Where do I get EPSS scores?

FIRST publishes them daily for every scored CVE through a public API and downloadable CSV. Most vulnerability management platforms now ingest them automatically. Because the scores change daily, pull them on a schedule rather than recording a single value on a ticket at creation time.

Does a high CVSS score mean a vulnerability is dangerous to me?

It means it would be damaging if exploited on an affected system. Whether it is dangerous to you depends on three things CVSS does not know: whether you run the affected software, whether the vulnerable component is reachable by an attacker, and how much you care about that asset. The environmental metric group in CVSS exists to let you adjust for exactly this, and it is very rarely used.

CVSS vs EPSS: Which Score Should Drive Your Patching

Two scores, both published by FIRST, both attached to the same CVE, routinely treated as competing answers to one question. They are answers to two different questions, and the confusion has a real cost: a queue sorted by the wrong one is a queue nobody can clear.

Scope: CVSS Explained owns the scoring system and how the vectors are calculated. EPSS Explained owns the model. KEV Catalog Explained owns the exploited-in-the-wild list. Vulnerability Management Lifecycle owns the process all three feed. This page owns the head-to-head.

The difference in one table

	CVSS	EPSS
Question	How bad would it be if exploited?	How likely is exploitation soon?
Type	Severity model, calculated from a vector	Likelihood model, machine learning, fitted to observed exploitation
Output	0.0 to 10.0	Probability 0 to 1, plus a percentile
Time	Static unless the vector is rewritten	A 30-day forward estimate, recomputed daily
Knows your environment?	Only through the environmental metrics, which almost nobody sets	No
Best used for	Deciding how much damage to plan for	Deciding what to look at first

What each one actually measures

CVSS decomposes a vulnerability into characteristics: whether it is reachable over a network, how complex the attack is, what privileges are needed, whether a user must interact, and what it does to confidentiality, integrity and availability. Those inputs produce a number.

CVSS v4.0 organises this into Base, Threat, Environmental and Supplemental metric groups. In practice, publishers issue Base scores and consumers use Base scores. The Threat group, which reflects exploit maturity, and the Environmental group, which lets you adjust for your own context, are the parts that would make the number decision-ready, and they are the parts nobody fills in.

That is the honest summary of CVSS in the wild: it is used as the one thing it explicitly says it is not, a standalone risk score.

EPSS is a model, not a calculation. FIRST describes it as estimating "the probability that a published CVE will be exploited in the wild in the next 30 days", published daily as a value between 0 and 1 with a ranking percentile. It is trained on features associated with real exploitation and evaluated against what actually gets exploited.

Two consequences follow from it being a forecast. It changes: a proof of concept published today moves tomorrow's score. And it is about the world rather than about you: a high score means attackers are likely to be exploiting this somewhere, not that they can reach your instance.

Why severity-only prioritisation fails

Sorting by CVSS and treating everything at 7.0 and above as mandatory selects a very large share of every CVE ever published. For a mid-sized estate that is tens of thousands of findings.

Most of them will never be exploited by anyone. Meanwhile a medium-severity flaw with a high exploitation probability on an internet-facing host sits somewhere in the middle of the list, because its impact metrics are unremarkable.

FIRST's own framing of the case for EPSS is that "addressing a small fraction of the population by EPSS score captures a disproportionately large share of realized exploitation". That is the entire argument in one sentence: likelihood concentrates effort where attacks happen, severity spreads it evenly over everything that could theoretically be bad.

The four cases

Reading them together produces four situations, and knowing which one you are in is most of the decision.

High CVSS, high EPSS. Fix now. Damaging and likely to be attacked. If it is also on KEV, treat as an emergency.

Low CVSS, high EPSS. Fix soon, especially if exposed. This is the case severity-only programs systematically miss: unglamorous flaws that attackers actually use, often because they are easy and widespread rather than because they are devastating.

High CVSS, low EPSS. Schedule it. Genuinely serious, currently ignored by attackers. Watch the EPSS score, because a published exploit changes it quickly. On a crown-jewel system, impact may justify moving faster than likelihood suggests.

Low CVSS, low EPSS. Routine cycle. This is most of the catalogue.

What neither knows

Both are properties of the vulnerability. Neither knows anything about you.

Exposure. Internet-facing, internally reachable, or isolated. This changes real risk by an order of magnitude and appears in neither score.
Asset criticality. The same flaw on a test box and on a payment system are different problems.
Compensating controls. A WAF rule, a segment boundary, or a disabled feature can make an exploitable flaw unreachable.
Whether you even run it. Scores exist for software you do not have.

This is why the practical ranking in Vulnerability Management Lifecycle multiplies the scores by facts only you hold. A 0.9 EPSS on an isolated internal system ranks below a 0.3 EPSS on a public one.

How to use all three

KEV first. If CISA lists it, exploitation is observed rather than estimated. Evidence beats models. Internet-facing KEV entries are an emergency.
EPSS next, weighted by exposure. Set a threshold on percentile rather than raw probability, because absolute probabilities are low across the catalogue. Re-pull scores on a schedule.
CVSS for impact. On critical assets, a high-severity flaw justifies action even at low likelihood, because the cost of being wrong is asymmetric.
Your context last and loudest. Exposure and criticality override all three when they conflict.

A worked shape for an SLA:

Condition	Target
On KEV, internet-facing	Days
On KEV, internal	Next cycle, sooner on critical systems
High EPSS percentile, internet-facing	Elevated, ahead of routine
High CVSS on a critical asset	Elevated regardless of EPSS
Everything else	Routine cycle

The verdict

CVSS tells you how much it would hurt. EPSS tells you how likely it is to happen. KEV tells you it already did.

Programs fail by using the first as a substitute for the second. The fix costs nothing: keep CVSS for impact, add EPSS for likelihood, let KEV override both, and multiply all of it by exposure and asset criticality, which are the only inputs you own and the ones that move the answer most.