After Microsoft’s monthly updates, the scanner returns several hundred new vulnerabilities rated CVSS 7 or higher, and the team will close a fraction of them this month. A queue sorted by CVSS shows what would be most dangerous if someone exploited it, but not what someone is actually exploiting. Whether patching hits real attacks depends on that difference.
EPSS (Exploit Prediction Scoring System) answers that second question: it gives the probability that a vulnerability will be exploited within the next 30 days. For a company’s cybersecurity it is the missing dimension of patch prioritization, but only when you read the score as a probability rather than a grade from zero to a hundred, and check it against what actually runs on the corporate network.
What is EPSS and what exactly does it measure?
EPSS is a data-driven machine learning model that estimates the probability that a published CVE will be exploited in the wild within the next 30 days. That is how FIRST, the forum of incident response teams, defines it: the model is maintained by the EPSS SIG at FIRST, and the scores are generated by Empirical Security and published daily for every CVE.
The key word is “activity”. According to the Using EPSS page, the score is a calibrated probability that exploitation activity for a given vulnerability will be observed across EPSS data partners within 30 days. FIRST states explicitly that it is neither a severity score nor a complete risk score.
That activity comes from malware telemetry, honeypots, IDS/IPS systems and threat intelligence feeds. These sources record attempts, not only successful attacks: according to FIRST, an attempt blocked by an IPS reflects the same attacker decision as one that succeeded.
The 30-day window was chosen on purpose. According to the methodology, it matches practitioners’ decision cycles, anchored for decades by Microsoft’s monthly updates (Patch Tuesday): the score says whether the vulnerability is likely to be exploited before the next patch window closes.
How do you read the EPSS score and percentile?
The EPSS score is a probability between 0 and 1, and the percentile is the proportion of all scored vulnerabilities with the same or a lower score. According to the methodology description, a score of 0.05 means a 5% probability of exploitation within 30 days, roughly one in twenty in a population of similar vulnerabilities.
The percentile is easy to overrate. CVE-1999-0001 has, in the daily file of 22 September 2026, a score of 0.03351, about a 3.4% probability, and at the same time a percentile of 0.88: its score is higher than those of 88% of scored vulnerabilities. A high percentile with a low probability is not an error but the result of a long-tailed distribution.
The numbers show that distribution. According to Using EPSS, in any 30-day period exploitation activity affects between 1.5% and 3% of published vulnerabilities, the mean score is around 2.8% and the median around 0.7%. In the daily file of 22 September 2026, for 377,636 scored CVEs the mean is 2.73% and the median 0.66% (calculated on the file).
The practical conclusion: read the score as a probability and the percentile as a position in the queue.
Where does the model get its data and how is the forecast produced?
The model combines about 2,850 vulnerability features with daily observations of exploitation and learns which combinations of signals precede attacks. According to FIRST’s methodology description, the features cover exploit code and offensive tooling, mentions of the vulnerability on security-related sites, individual CVSS metrics, and the vulnerability’s age and number of references.
The labels, that is, whether a vulnerability was exploited on a given day, come from nearly a dozen data partners. The algorithm is gradient-boosted trees implemented in XGBoost, trained on 12 months of history, and the raw output goes through calibration so that 0.05 corresponds to an actual 5% of exploitation within 30 days.
Two properties of the model have practical consequences. First, the model is not retrained every day: each day the features are recomputed and the same model is run, so an overnight jump in the score means new signals, such as the publication of exploit code. Second, age weighs more in the forecast than any other single vulnerability characteristic, and according to FIRST vulnerabilities older than two years are exploited at roughly five times the rate of those less than a month old.
FIRST lists the limitations itself: the score is population-level, and for newly disclosed vulnerabilities it relies on sparse signals that accumulate over the following days.
Which version of the EPSS model is current?
Since 15 June 2026, FIRST has published scores from version 5 of the EPSS model, labelled v2026.06.15. The Get the Data page lists the earlier versions: v4 (v2025.03.14), published from 17 March 2025, and older ones, with the first scores from 14 April 2021.
The version is visible in the data itself. The daily file of 22 September 2026 begins with the line #model_version:v2026.06.15,score_date:2026-09-22T12:02:55Z, while in the file of 14 June 2026, the day before version 5 launched, the header still showed v2025.03.14.
The version change matters to anyone who keeps score history. FIRST warns that each new version shifted the scores on the date it started publishing, so a time series crossing that boundary reflects a change in methodology, not a change in the vulnerability. An example from the daily files: CVE-1999-0001 had a score of 0.00988 on 14 June 2026 and, already under version 5, 0.03351 on 15 June.
Thresholds set on version 4 scores are therefore worth rechecking before the team mistakes a change in the queue for a change in the threat.
How does EPSS differ from CVSS?
CVSS describes a vulnerability’s characteristics and severity, while EPSS estimates the probability that someone will exploit it, so the two numbers answer different questions. The CVSS scale and metrics are covered in a separate article on the CVSS system; what matters here is how the two systems relate.
EPSS uses CVSS, but not its score. The model takes individual CVSS metrics as features (attack vector, complexity, privileges required, user interaction and the impact metrics), ignores the numeric score and learns from the data how much each metric weighs.
That leads to the most important prohibition in FIRST’s documentation: you do not multiply the EPSS score by CVSS to get a “combined risk score”. EPSS is a calibrated probability and CVSS an ordinal ranking with no empirical calibration, so the product has no interpretable meaning. FIRST calls this score laundering.
The two numbers are used side by side instead: CVSS to assess impact, EPSS to assess probability, as in the queue described in the article on vulnerability prioritization in practice.
How do you set an EPSS threshold in your patch queue?
You set an EPSS threshold locally by weighing coverage against effort, not by the intuition that a high percentage score means “urgent”. FIRST measures the model’s performance with three quantities: coverage is the share of actually exploited vulnerabilities a threshold catches, effort is the share of all vulnerabilities you must act on, and efficiency is the share of the vulnerabilities you acted on that were actually exploited.
Using EPSS gives a reference point for organizations that patch by CVSS today: in terms of effort, a CVSS Critical threshold corresponds roughly to the 90th EPSS percentile, a score of at least 0.04, and a CVSS High-and-above threshold to a score of about 0.008. FIRST notes that this is a starting point for programs moving away from CVSS, not an endorsement of the CVSS categories.
How many vulnerabilities a threshold covers is shown by the daily file of 22 September 2026 (377,636 scored CVEs, calculated on the file):
| EPSS score threshold | Number of CVEs scoring at least this | Roughly one in how many scored CVEs |
|---|---|---|
| 0.008 | 169,811 | one in two |
| 0.04 | 37,476 | one in ten |
| 0.1 | 17,395 | one in twenty-two |
| 0.5 | 4,347 | one in eighty-seven |
| 0.9 | 802 | one in four hundred seventy-one |
The table shows why an intuitive 0.5 threshold fails: it leaves one vulnerability in several dozen in the queue, even though, by the model’s calibration, roughly one in ten vulnerabilities scoring 0.1 gets exploited. Choosing a threshold is a decision about how much work the team will do and how many exploited vulnerabilities it will let through, so the threshold is recorded together with its justification.
How do you combine EPSS with KEV and your own environment?
A vulnerability in the KEV catalog is treated as actively exploited regardless of its EPSS score, and the remaining vulnerabilities are filtered through three questions about your own environment. That is how FIRST frames the rule: KEV records confirmed past exploitation, EPSS forecasts the next 30 days, and a low EPSS score on a KEV-listed vulnerability is not a contradiction.
The three questions concern presence, reachability and consequence. A high score for a vulnerability the company does not have does not matter. A vulnerability that is present but unreachable for an attacker, because it requires authentication or sits behind compensating controls, weighs less. The same vulnerability on a critical system or one handling sensitive data weighs more than on an isolated test server.
This approach fits risk management frameworks. The NIST Cybersecurity Framework 2.0 of 26 February 2024 requires, in subcategory ID.RA-04, that potential impacts and likelihoods of threats exploiting vulnerabilities be identified and recorded, and in ID.RA-05 that these be used to inform risk response prioritization. EPSS supplies the likelihood part; the organization has to assess the impact.
Key takeaways:
- EPSS is the probability that a vulnerability will be exploited within 30 days, not a measure of its severity.
- The percentile shows a position in the queue, not risk: a score of 0.034 can have a percentile of 0.88.
- Version 5 of the model has been current since 15 June 2026, and a score series crossing that date changes methodology.
- A vulnerability in KEV is patched as a priority regardless of its EPSS score.
- A population-level score has to be checked against presence, reachability and consequence in your own environment.
What mistakes should you avoid when working with EPSS?
FIRST’s documentation lists mistakes that each lead to a bad patch queue:
- Multiplying EPSS by CVSS (see the section on how EPSS differs from CVSS).
- Treating a small probability as safe. A score of 0.05 across thousands of vulnerabilities means many exploitation events, because statistically it applies to one vulnerability in twenty.
- Judging the model by a single case. One vulnerability with a surprisingly low score says nothing about a system that scores hundreds of thousands of CVEs every day.
- Acting without checking your environment. The score knows nothing about your asset inventory or compensating controls.
- Expecting the score to react to yesterday’s attack. Exploitation activity is used to train the model but not in the daily scoring, so EPSS is not a live feed of attacks.
One limitation cannot be worked around with any threshold: the model sees only the exploitation its data partners have recorded. FIRST writes that EPSS learns from a sample of actual exploitation, not a complete census of it.
How do you retrieve EPSS scores through the API and the daily file?
You check individual vulnerabilities through the FIRST API and download the full list once a day as a CSV file. According to FIRST, the API at https://api.first.org/data/v1/epss is meant for lookup, not bulk downloads; it lets you request the score from a specific past date and a 30-day history for a single vulnerability, and the “v1” in the address is the API version, not the model version.
# Score on 22 September 2026 for a single vulnerability
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228&date=2026-09-22"
# 30-day score history for the same vulnerability
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228&scope=time-series"For CVE-2021-44228 (Log4Shell), the first query returns a score of 0.99999 and a percentile of 1.0, the top position in the whole set.
For batch work, such as joining scores with an asset inventory, there is a daily file with three fields: the CVE identifier, the score and the percentile. The file archive goes back to 14 April 2021, so you can reconstruct the queue as it stood on the day of a patching decision.
How do you build EPSS into your vulnerability management process?
EPSS enters the process as one of several signals, and each of them answers a different question and leads to a different decision.
| Signal | Question it answers | Where to get it | Decision in the queue | Typical trap |
|---|---|---|---|---|
| KEV catalog | Has exploitation been confirmed? | CISA KEV catalog | priority patching regardless of EPSS | skipping a KEV vulnerability because of a low EPSS score |
| EPSS score | How likely is exploitation within 30 days? | FIRST API or daily file | order among vulnerabilities outside KEV | a threshold set by gut feeling |
| EPSS percentile | How many vulnerabilities score no higher? | the same entry in the EPSS data | estimating effort at a given threshold | reading the percentile as a probability |
| CVSS score | How severe is the impact and what are the attack conditions? | the vulnerability description from the vendor or a CVE database | weighing impact alongside probability | multiplying it by the EPSS score |
| Presence and reachability | Is the vulnerability here and can it be reached? | vulnerability scanner, inventory, network architecture | deprioritizing unreachable vulnerabilities | a population-level score without an environment check |
| Business consequence | What happens after exploitation? | asset register with criticality ratings | raising the priority of critical systems | giving every server the same weight |
| Sum of EPSS scores | How many exploitation events to expect across the set? | sum of probabilities for the vulnerability list | an exposure measure for the whole program | treating it as a precise forecast |
The last row needs a comment. Because EPSS scores are calibrated probabilities, FIRST shows how to aggregate them: for 100 vulnerabilities each scoring 0.05, the probability that at least one is exploited is about 99.4%, and the expected number of exploited vulnerabilities is 5. FIRST notes that these are estimates, not precise forecasts, but they describe the exposure of the whole program rather than a single vulnerability.
How can nFlo help prioritize vulnerabilities?
nFlo deploys vulnerability management platforms in which prioritization does not stop at CVSS. Tenable Vulnerability Management combines vulnerability data with threat intelligence for risk-based prioritization with asset context, and Rapid7 InsightVM calculates an Active Risk Score from CVSS, exploit availability, malware usage, attacker activity and asset criticality.
The ratings of these platforms are the vendors’ own methods, not the EPSS score, but they answer the same question. You can add the EPSS score for vulnerabilities found by the scanner through the FIRST API by matching the CVE identifiers from the scan report.
The vulnerability management knowledge base collects the wider context. If you want to put your company’s patch queue in order, talk to us.
What else is worth knowing about EPSS?
Does EPSS replace CVSS?
No. CVSS describes the severity and characteristics of a vulnerability, while EPSS gives the probability that it will be exploited within 30 days. FIRST recommends using both systems side by side and warns against multiplying the EPSS score by the CVSS score.
How often does the EPSS score change?
Every day. Each day the features of every vulnerability are recomputed and the same model is run, so a change in the score means new signals, such as the publication of exploit code. The model itself is retrained only when monitoring shows its performance drifting.
Does a low EPSS score mean a vulnerability is safe?
No. A low score is still a probability, and across a large population of vulnerabilities even low probabilities add up to real exploitation. A vulnerability in the KEV catalog is treated as actively exploited regardless of its EPSS score.
Does EPSS take your environment into account?
No. The score is population-level and knows nothing about your asset inventory or compensating controls. Before deciding, check whether the vulnerability is present in your environment, whether an attacker can reach it and what its exploitation would cause.
Where do you get EPSS scores?
From the FIRST API for individual vulnerabilities or from the daily CSV file for the full list. The archive of daily files goes back to April 2021, and access to the data requires no registration.
