Using EPSS to Decide What to Patch First

The Exploit Prediction Scoring System (EPSS) gives every published CVE a probability, from 0 to 1, that exploitation activity will be observed in the next 30 days. FIRST recalculates the scores daily and publishes them for free. To use EPSS for patch prioritization, put CISA's Known Exploited Vulnerabilities (KEV) entries first, then vulnerabilities with high EPSS scores on exposed or critical systems, and use CVSS to judge how much damage each one could do. The rest of this post covers how to read the scores, pick a threshold and avoid the common traps.

What is EPSS?

EPSS is a data-driven model maintained by a special interest group at FIRST, the same organization that maintains CVSS. It combines information about each CVE, such as whether exploit code is public and how the vulnerability is described, with observations of real exploitation attempts shared by data partners. The output is a single probability per CVE.

The model has changed over time. The first version, published in 2021, estimated the chance of exploitation in the year after a vulnerability was disclosed. Version 2, released in February 2022, moved to daily scoring and a 30-day prediction window. Version 3 started publishing on March 7, 2023, and is the version behind today's scores.

The scores, the API and the documentation are all free on the FIRST EPSS site.

What does an EPSS score mean?

Each CVE gets two numbers: a probability and a percentile. They answer different questions, and mixing them up leads to bad decisions.

The probability

The EPSS score is the estimated probability that exploitation activity for that CVE will be observed in the next 30 days. A score of 0.20 means roughly a one-in-five chance.

"Exploitation activity" here means attempts detected by EPSS data partners, such as sensors that record attack traffic. It doesn't mean a successful compromise, and it doesn't mean someone is targeting you. It's a measure of whether attackers are using the vulnerability anywhere, which is a strong hint about whether they might use it against you.

The percentile

The percentile tells you how a CVE ranks against every other scored CVE. A CVE at the 90th percentile has a higher score than 90% of all scored vulnerabilities.

Most CVEs have very low probabilities, so the distribution is heavily skewed toward zero. As a result, a probability that looks small can still rank in a high percentile. Use the probability when you're reasoning about likelihood and setting thresholds. Use the percentile when you need to explain relative ranking to someone who finds small decimals confusing.

Why scores change every day

EPSS is meant to move. A score rises when new signals appear: exploit code gets published, detection signatures are released, or partners start seeing attempts. It can fall again when activity dies down.

That's the main advantage over a CVSS base score, which rarely changes after publication. It also means the score you acted on last month may not reflect the situation today.

What changed with EPSS v3?

Version 3 replaced the v2 model on March 7, 2023. It uses more data sources and a larger set of features, and FIRST reported a clear improvement in predictive performance over v2.

The practical consequence is a one-time shift. Many CVEs got noticeably different scores on the day v3 went live, so if you track EPSS history, don't read a jump across that date as a change in threat. If you set thresholds under v2, re-check them against v3 scores before relying on them.

How do you get EPSS scores?

There are three common routes:

• The API. FIRST's endpoint at https://api.first.org/data/v1/epss takes one or more CVE IDs and returns the probability and percentile. It also supports scores for a past date, a 30-day time series for a single CVE, and filters such as epss-gt and percentile-gt. The API documentation lists the parameters.
• The daily file. FIRST links to a daily CSV of every scored CVE. For a small team, downloading it once a day and joining it to scanner output by CVE ID is often the simplest approach.
• Your existing tools. Some vulnerability management tools have started to show EPSS next to CVSS. Check what yours offers, and which date's scores it displays, before building your own integration.

How do you combine EPSS with CVSS and KEV?

Each source answers a different question:

A workable order of operations looks like this:

1. KEV matches on your systems. Confirmed exploitation beats any prediction. Handle these first, starting with internet-facing and business-critical systems.
2. High EPSS and high CVSS on exposed or critical systems. Likely to be exploited and damaging if it is.
3. High EPSS with lower CVSS. Check exposure and whether the flaw could be chained with others, such as an information leak that makes another weakness easier to reach.
4. High CVSS with low EPSS. Schedule these in your normal cycle and watch for the EPSS score climbing.
5. Low on both. Routine maintenance.

Asset context should move items within this list. A high-EPSS vulnerability on an isolated lab machine can reasonably wait behind a moderate one on an internet-facing server.

How do you choose an EPSS threshold?

FIRST doesn't publish a universal threshold, and there isn't a correct one. The right cutoff depends on how much remediation work your team can absorb.

Two measures help frame the choice. Coverage is the share of vulnerabilities that were actually exploited which your policy caught. Efficiency is the share of the vulnerabilities you prioritized that turned out to be exploited. Lowering the threshold raises coverage but lowers efficiency, because you're patching more things that were never going to be used.

A practical way to pick your numbers:

1. Pull current EPSS scores for all your open findings.
2. Count how many sit above a few candidate thresholds, such as 0.01, 0.05, 0.10 and 0.20.
3. Compare each count with the remediation capacity you have in a typical month.
4. Choose a lower threshold for exposed and critical systems and a higher one elsewhere.
5. Add a rule for sharp rises, so a CVE that jumps well above its previous score gets a second look even if it's still under the line.

Revisit the thresholds every quarter, and after any model change.

What are the limitations of EPSS?

EPSS is a useful signal, but it has blind spots you should plan around.

• It isn't a risk score. It estimates the likelihood of exploitation activity. It says nothing about the impact on your business or how the system is deployed.
• It only covers CVEs. Misconfigurations, exposed cloud storage, weak or default credentials and vulnerabilities without a CVE ID never get an EPSS score.
• It only sees what partners see. Exploitation that doesn't show up in partner telemetry won't raise a score, so a low score is not proof of safety.
• New CVEs start with little data. A freshly published vulnerability may score low for a few days and then climb quickly once exploit code or activity appears.
• Scores are time-stamped. Record the date of the score you used for a decision. It will help you explain that decision later, especially to an auditor.

Frequently asked questions

Is a high EPSS score more urgent than a KEV entry?

Not usually. KEV lists vulnerabilities with reliable evidence of exploitation, while EPSS is a forecast. When a CVE is in KEV, treat it as exploited regardless of its EPSS score.

Should we use the EPSS probability or the percentile?

Use the probability for thresholds and decisions, since it has a direct meaning. The percentile is handy for reporting and for comparing CVEs quickly, but it can make low-probability vulnerabilities look more urgent than they are.

How often should we pull EPSS scores?

Daily is ideal for internet-facing systems, since that's how often the scores change. For everything else, a weekly refresh that feeds your normal patch planning is enough for most small and mid-sized teams.

Does EPSS replace CVSS?

No. CVSS describes how severe a vulnerability is, and EPSS estimates how likely it is to be used. You need both, plus your own knowledge of which systems matter.

Next steps

• Join the daily EPSS data to your scanner findings by CVE ID.
• Put KEV matches at the top of the queue, then high-EPSS findings on exposed and critical systems.
• Set separate thresholds for high-value and lower-tier systems, based on real capacity.
• Re-check thresholds now that v3 has replaced v2, and review them each quarter.
• Keep a separate process for misconfigurations and other issues that EPSS can't see.