EPSS, the Exploit Prediction Scoring System, estimates the probability that a given vulnerability will be exploited in the wild within the next 30 days, expressed as a value between 0 and 1. It is a forward-looking likelihood signal, in contrast to severity scoring, which describes potential impact.
Severity scoring on its own produces a queue in which a large share of findings carry a critical label, which makes the label a poor instrument for deciding what to do first. EPSS cuts differently: it identifies the small subset attackers are actually likely to use. Because the distribution is so skewed, a threshold on probability removes far more of a backlog than a threshold on severity, and it removes the part that matters least.
The limit is the limit of any global signal. Exploitation of known vulnerabilities is the leading initial-access vector in the Verizon 2026 Data Breach Investigations Report, at 31 percent of breaches with a known vector. Knowing which vulnerabilities attackers favour worldwide still does not establish whether they exist in a reachable path in a given estate, which team owns the affected assets, or how a fix would be delivered. EPSS narrows the field; something environment-specific has to decide.
EPSS is maintained by the Forum of Incident Response and Security Teams (FIRST) as a data-driven model rather than an expert-judgement scale. It is trained on observed exploitation activity, scores published CVE records against a feature set, and is recomputed daily, so a score reflects current conditions rather than the state of the world at disclosure.
The first three narrow the field. The fourth decides. Each score is published alongside a percentile placing it in the distribution of everything scored, and the percentile is often the more communicable number, because raw probabilities cluster near zero: 0.15 sounds negligible and sits above the 94th percentile.
Consider two vulnerabilities disclosed in the same week. The first is a remote code execution flaw in an internet-facing file transfer appliance. On day one no exploit code is public and the score sits near 0.01. Within four days a working proof of concept is published, matching scanning activity appears in honeypot telemetry, and the score rises above 0.8. Nothing about the vulnerability changed; the evidence about attacker behaviour did, and a severity rating assigned at disclosure would look identical on both days.
The second is a flaw in a Java logging library that an application ships as a transitive dependency but never binds as its logging engine. The global probability is high, because the library is deployed nearly everywhere. Here the vulnerable class is loaded onto the classpath and never called, so exposure is zero. That was the shape of the Log4Shell response in many organizations: presence was near universal, exploitability was not, and a global probability could not tell the two cases apart.
EPSS is published by FIRST, which also maintains the Common Vulnerability Scoring System; the two are documented as complements rather than alternatives. Scores are keyed to identifiers issued through the CVE Program, so a vulnerability with no assigned identifier has no score. Confirmed exploitation is catalogued separately by CISA.
Should EPSS replace CVSS? No. They answer different questions and are strongest in combination: likelihood to filter the queue, severity to weigh the consequence of what survives the filter.
What EPSS threshold is appropriate? There is no universally correct figure. It is a risk-appetite decision, calibrated against available remediation capacity and reviewed as that capacity changes.
Does a low EPSS score mean a vulnerability can be ignored? It means broad exploitation is unlikely in the next 30 days. It does not model a targeted attacker, and says nothing about a flaw on a highly critical asset.
How often do scores change? Daily. Publication of working exploit code can move a probability by an order of magnitude within a few days, so a score captured at ticket creation should not be treated as durable.
