EPSS Explained: Scoring How Likely a Vuln Is to Be Exploited

Most vulnerabilities are never exploited. That single fact is the reason EPSS exists. If you patched strictly in CVSS order you would spend enormous effort on severe-looking flaws that attackers ignore, while a quietly weaponised medium-severity bug waited its turn.

EPSS, the Exploit Prediction Scoring System, is an open, data-driven model maintained by a FIRST special interest group. It answers the question CVSS was never built to answer: how likely is it that this specific vulnerability will actually be exploited soon.

What the score means

Every CVE with an EPSS entry gets a probability between 0 and 1 that it will be exploited in the wild within the next 30 days. A score of 0.85 means the model estimates roughly an 85 percent chance of observed exploitation activity in that window. A score of 0.001 means it is very unlikely.

Alongside the probability, each CVE gets a percentile, from 0 to 100, showing how it ranks against every other scored CVE. A CVE in the 99th percentile is among the most likely to be exploited of all known vulnerabilities. The percentile is what most teams sort and threshold on, because it stays interpretable even as the absolute probabilities shift when the model retrains.

How the model works

EPSS is machine learning, not a rubric. The model is trained on a large set of features drawn from real vulnerability data and correlated with observed exploitation. The inputs include things like:

• Whether public exploit code exists, and where (exploit databases, frameworks like Metasploit, published proof-of-concept).
• References and tags on the CVE, and the affected vendor and product.
• The age of the vulnerability and its activity over time.
• Signals of exploitation observed across a wide sensor network.

The model is retrained continuously and scores are refreshed daily. Because it learns from what attackers actually do, its judgements shift as the threat landscape shifts. A CVE can be low-probability on Monday and jump on Wednesday when a working exploit is published. This is a feature. Severity is static, and exploitation risk moves with the world.

A useful mental model is that EPSS is estimating a base rate and then adjusting it with evidence. The base rate is low, because across the whole population of published CVEs, only a small fraction are ever exploited in the wild. The model starts from that reality and raises a specific CVE above the crowd when its features resemble those of vulnerabilities that historically drew exploitation: a public proof of concept appearing, the flaw affecting widely deployed software, references accumulating, or sensor telemetry showing early probing. Nothing in the model is a human opinion about how dangerous the bug looks. Every lift comes from a pattern the model has learned separates the exploited from the ignored.

This is also why EPSS avoids a trap that catches severity scoring. A flaw can be technically severe and still be uninteresting to attackers because it is hard to reach, needs an unusual precondition, or affects software few organisations run. Severity has no way to express that disinterest. EPSS does, because the same features that make a flaw unattractive to attackers keep its score near the population base rate.

Reading a score in context

The raw probability is most useful when you group it into bands rather than reacting to every decimal place. A rough working scheme that many teams adopt treats scores in loose tiers: a very low band where the flaw sits near the population base rate and can safely age in the backlog, a middle band that warrants watching for movement, and a high band where the model is signalling meaningful exploitation likelihood and the flaw earns a place in the active queue. The exact cut points are yours to set, and the percentile is the more durable way to draw them, but thinking in bands stops you from over-reacting to tiny fluctuations that carry no real meaning.

Context from your own environment sharpens the read further. The same EPSS score means something different on an unauthenticated, internet-facing service than it does on an internal component behind several layers of access control. EPSS gives you the population-level odds, and your exposure data tells you how much those odds matter for your specific systems. The score is the starting point of the conversation, and reachability, asset value, and existing compensating controls finish it.

One more reading habit pays off repeatedly: pay as much attention to the direction of travel as to the level. A CVE that has sat at a low score for months and suddenly climbs is telling you that the model just saw new evidence, most often a public exploit or a burst of sensor activity. That movement is frequently the earliest structured warning you will get that a flaw is about to be a problem, which is why keeping yesterday's scores to compare against today's is worth the small storage cost.

Why EPSS and CVSS answer different questions

It is worth being precise about the division of labour, because conflating the two is the most common mistake in vulnerability management.

Signal	Question it answers	Changes over time
CVSS	How bad is it if exploited	Base score is fixed
EPSS	How likely is exploitation soon	Updated daily
CISA KEV	Is it being exploited right now	Grows as CISA confirms

CVSS measures impact and difficulty. EPSS measures probability. Neither replaces the other. A vulnerability with a 9.8 CVSS and a 0.02 EPSS is dangerous in theory and quiet in practice. A 6.5 CVSS with a 0.94 EPSS is a lower ceiling but an active threat. If you can only work one this week, the second is usually the right call.

For the definitional companion to this guide, see CVSS Explained.

Reading EPSS well

A few habits separate teams that get value from EPSS from teams that just add another column to a spreadsheet:

1. Threshold on percentile, revisit the number. Something like "everything above the 90th percentile enters the expedited queue" is a durable rule. Absolute-probability cutoffs drift as the model updates.
2. Watch the deltas, not just the level. A CVE whose EPSS jumped ten points overnight is telling you something changed in the world, often that an exploit went public.
3. Never drop the impact axis. EPSS says nothing about what a flaw damages. A high-probability, low-impact bug still needs the CVSS impact view before it jumps the queue.
4. Confirm against KEV. If a CVE is on the KEV catalog, exploitation is no longer a prediction. Treat it as urgent regardless of the EPSS number.

Seeing it live

EPSS is free to query, but the value shows up when you plot it against severity and confirmed exploitation. Our Exploit Intelligence dashboard joins live NVD, FIRST.org EPSS and CISA KEV data into one view: a CVSS-by-EPSS risk matrix, plus the time from a CVE's publication to its KEV listing. It is the fastest way to see which severe flaws are also probable, and which are all bark.

EPSS will not tell you what to do. It gives you the one number a severity score cannot: the odds. Combine those odds with impact and with confirmed exploitation, and a patch backlog of thousands becomes a shortlist of the few that genuinely deserve tonight's change window.

A worked triage walkthrough

The clearest way to feel what EPSS buys you is to run a backlog through it. Imagine a monthly scan returns eight hundred open findings across your fleet. Sorting by CVSS alone, you might see two hundred flagged as high or critical. That is more than any team can patch in a single cycle, so the CVSS-only sort has failed at the one job you needed from it: telling you what to do first.

Now layer EPSS on top. Pull the current score and percentile for each CVE from the FIRST.org API and add two columns to the scan export. Sort first by percentile, descending. The list reorganises immediately. The severe-looking flaws with almost no public exploit interest sink toward the bottom. A smaller cluster rises to the top: CVEs that are both damaging if exploited and estimated as likely to be exploited soon.

Walk the top of that reordered list one row at a time. The first CVE might carry a CVSS of 8.1 and an EPSS in the 99th percentile with a probability of 0.92. That combination is unambiguous. It is a serious flaw the model believes is being actively weaponised, and it belongs in tonight's change window. The next row might show a CVSS of 9.8 and an EPSS in the 20th percentile with a probability of 0.004. High ceiling, quiet in practice. It stays on the list, because a public exploit could change that overnight, and you review it again next cycle when the score refreshes.

Further down you find the inverse case that CVSS-only triage always mishandles: a CVE with a moderate 6.4 severity and an EPSS percentile of 97. On a severity-only sort this bug sat in the middle of the pile, ignored for months. EPSS surfaces it because the model sees the exploitation signals that severity is blind to. This is the exact row that a likelihood-aware program patches and a severity-only program misses.

How to operationalise EPSS

Querying a score is easy. Building a program that reacts to scores is where the value compounds. A few concrete practices turn EPSS from a lookup into a workflow.

Cache the full daily model output rather than querying one CVE at a time. FIRST publishes the entire scored set daily, and holding a local copy lets you compute deltas, run thresholds across your whole asset inventory in one pass, and avoid rate limits. The daily refresh is the cadence to build around, since scores can move meaningfully between one day and the next when exploit code goes public.

Join EPSS to asset context before you act on it. A high percentile on a CVE that affects an internet-facing, unauthenticated service is a different priority from the same score on a flaw in an internal tool reachable only by trusted admins. EPSS estimates the likelihood of exploitation in the wild across the whole population of systems, so pairing it with your own exposure and reachability data sharpens it from a global signal into a local one.

Set the threshold as a policy, not a one-off decision. A written rule such as "any open finding at or above the 90th EPSS percentile enters the expedited queue, and anything on CISA KEV is promoted to the top regardless of score" gives your team a durable, auditable standard. It also survives model retraining, because a percentile cutoff stays interpretable even as absolute probabilities shift.

Track how your queue moves over time. If you plot the EPSS distribution of your open backlog month over month, a healthy program shows the high-percentile band staying small and getting cleared quickly, while the long low-percentile tail is allowed to age. A backlog where high-EPSS items linger is a resourcing problem the chart makes visible.

Common misconceptions

A handful of misreadings show up again and again, and each one quietly undermines the value of the signal.

The first is treating EPSS as a severity score. It is not. A high EPSS says a flaw is likely to be exploited, and says nothing about what happens if it is. A high-probability bug that only crashes a non-critical service is a real signal, but it does not automatically outrank a lower-probability flaw that grants full remote code execution on a core system. Keep the impact axis in the picture at all times.

The second is reading the probability as a promise. An EPSS of 0.80 does not mean the CVE will be exploited. It means the model estimates roughly an eighty percent chance of observed exploitation activity in the next thirty days across the population it was trained on. Some high-scoring CVEs will see no activity, and some low-scoring ones will be hit. The score is a calibrated estimate over many vulnerabilities, and it earns its keep in aggregate over a backlog, not as a guarantee about any single row.

The third is anchoring on the absolute number instead of the percentile. Because the model retrains continuously, the raw probabilities drift. A cutoff written as "patch everything above 0.5" can silently include far more or far fewer CVEs after a model update. A percentile cutoff is the more stable lever, which is why most mature programs threshold on rank.

The fourth is assuming a low score today means safe forever. EPSS is a thirty-day forward estimate that is recomputed daily. A CVE sitting quietly at the bottom of the list can jump the moment a working exploit is published or a proof of concept spreads. The correct posture is to re-run the whole backlog against fresh scores on a regular cadence, so a rising flaw is caught on the way up.

How EPSS evolved

EPSS did not arrive fully formed. It began as a research effort to bring data to a decision that had been made largely by intuition and by static severity scores. The first published model was intentionally simple, built to prove that observed exploitation could be predicted from features available at scan time rather than guessed from the shape of a vulnerability.

Later model generations widened the feature set and improved calibration. The project moved from a small handmade set of inputs to a much richer model trained on a broad range of vulnerability metadata and on exploitation signals collected across a wide sensor network. Each generation of the model raised how well the top-scoring slice of CVEs concentrated the real exploitation activity, which is the property that makes the score worth sorting by. The practical takeaway for a defender is that EPSS is a living system. The scores you pull today come from a model that has been refined over several versions and continues to be retrained, so the reference to trust is always the current output rather than a number you cached a year ago.

How EPSS compares to other prioritisation signals

EPSS is one input among several that teams use to decide patch order. Seeing them side by side clarifies what each contributes and why combining them beats any one alone.

Signal	What it is	Nature	Best used for
CVSS Base	Severity of a flaw if exploited	Static, set at publication	The impact ceiling
EPSS	Probability of exploitation within 30 days	Data-driven, updated daily	The likelihood axis
CISA KEV	Catalog of confirmed exploited CVEs	Grows as CISA verifies	Hard override to the top
SSVC	Decision-tree triage on exploitation and exposure	Qualitative, human-guided	Structured go or wait calls
Threat intel feeds	Reports of active campaigns and actors	Narrative, timely	Context on who and why

CVSS gives the ceiling on damage. EPSS gives the odds. KEV removes the guesswork once exploitation is confirmed. SSVC wraps those inputs in a repeatable decision tree so that similar findings get similar calls. Threat intelligence adds the story of which actors are moving and against which sectors. A program that reads these together makes better patch-order decisions than one leaning on any single column, and EPSS is the piece that supplies the likelihood the others lack.

Frequently asked questions

Is EPSS free to use? Yes. The model output is published by FIRST and can be queried through the FIRST.org API with no account required, and the full scored set is available as a daily download. There is no paid tier for the core scores, which is part of why EPSS has spread quickly through vulnerability-management tooling.

How often do EPSS scores change? Scores are refreshed daily. The model is retrained on an ongoing basis as new exploitation signals arrive, so a given CVE's score can move from one day to the next, sometimes sharply when a working exploit is published.

Should I patch by EPSS score or by percentile? Threshold on percentile for your standing triage rules, because the percentile stays interpretable as the model retrains and the absolute probabilities drift. Look at the raw score and its recent change when you are examining an individual CVE closely.

Does a high EPSS mean the vulnerability is severe? No. EPSS measures the likelihood of exploitation, not the impact. A high EPSS on a low-impact flaw is still worth attention, but you weigh it against the CVSS impact view before deciding it outranks a more damaging flaw with a lower probability.

What is the difference between EPSS and CISA KEV? EPSS predicts whether a CVE is likely to be exploited soon. KEV is a list of vulnerabilities CISA has confirmed are being exploited. EPSS is a forward-looking estimate, and KEV is a record of confirmed activity that overrides the estimate.

Can EPSS be wrong? Individual predictions can miss in both directions: a high-scoring CVE may see no activity, and a low-scoring one may be exploited. EPSS is calibrated to be accurate across many vulnerabilities rather than to be certain about any single one, so its value shows up when you apply it across a whole backlog.

How does EPSS fit into a vulnerability-management program? It supplies the likelihood axis that severity scoring lacks. Most teams use it as one column alongside CVSS impact, asset exposure, and KEV status, feeding a combined priority that decides which findings enter the expedited patch queue.

Does EPSS cover every CVE? The model scores published CVEs, so coverage tracks the CVE catalog broadly. A brand new vulnerability may take a short time to receive a meaningful score as features accumulate, which is one more reason to recompute your backlog against fresh scores regularly rather than relying on a single snapshot.

Related guides

• CVSS Explained
• The KEV Catalog Explained
• The CVE System Explained
• Vulnerability Management Lifecycle
• Zero-Day Vulnerabilities