EPSS Guide: use exploitation probability with CVSS and KEV correctly

Severity scores tell you how bad a vulnerability would be if exploited, but not whether anyone is likely to exploit it, so teams that patch by CVSS alone spend most of their effort on flaws attackers ignore. The Exploit Prediction Scoring System (EPSS) from FIRST fills that gap with a daily, data-driven probability that a published CVE will see exploitation activity in the next 30 days. Used well, it shrinks the urgent queue dramatically; used badly, as a risk score or with percentiles mistaken for probabilities, it hides real exposure. This guide explains how EPSS works, how to read probability and percentile, how to set thresholds, how to combine it with CVSS, CISA KEV and asset context, and the common ways it is misused. It is written for vulnerability management leads, security engineers building prioritisation pipelines and analysts who report risk. The wider prioritisation method is in the Vulnerability Prioritisation Guide; this page goes deep on EPSS itself.

Key takeaways

• EPSS measures threat, not risk. FIRST says the score should never be treated as a risk score; it says nothing about your asset's exposure or value.
• Use the probability, show the percentile. The probability is the score; the percentile is a relative rank that can make a low-probability CVE look urgent.
• Thresholds are a trade-off you choose. FIRST publishes no official cut-off; pick one by measuring coverage and effort on your own data.
• KEV beats prediction. A KEV entry is evidence of exploitation; EPSS is a forecast. Treat KEV as a floor and EPSS as a way to rank everything else.
• Scores move daily. Store history and re-evaluate open findings every day, because a proof of concept or campaign can lift a score overnight.

What EPSS is and how the model works

EPSS is maintained by the EPSS Special Interest Group at FIRST, with scores generated by Empirical Security. It publishes, every day, a score for every published CVE. Data and scores are free through a CSV download, an API and a GitHub repository.

• Output: a probability between 0 and 1 that the CVE will see exploitation activity in the wild in the next 30 days, plus a percentile.
• Inputs: vulnerability information such as CVSS data, CWE classification, availability of Metasploit modules, KEV and Google Project Zero listings, and mentions across many sources. Analysts do not set weights by hand; the model learns how each input relates to observed exploitation.
• Ground truth: exploitation activity from data partners using honeypots, IDS/IPS sensors and host-based detection. It records attempted exploitation, not successful compromise. FIRST names partners including VulnCheck KEV, the Shadowserver Foundation and LevelBlue.
• Training: machine learning on 12 months of history, tested on a time-based holdout (train on data from 14 to 2 months ago, test on the most recent 2 months).
• History: available back to 14 April 2021 through the API.

Model versions

Model changes shift score distributions. When a new version is released, re-baseline thresholds and dashboards rather than comparing scores across versions.

Probability versus percentile

Most EPSS probabilities sit in a narrow, low band, so the percentile is often shown to make scores readable. FIRST's guidance is to use the probability as "the" EPSS score and show the percentile alongside it, for example "15.3% (92nd)".

FIRST gives an example: a 10 percent probability sits around the 88th percentile. A team that sets "above the 90th percentile" as urgent is therefore using a threshold of roughly 10 percent probability or more, which may be far more or fewer CVEs than intended, and will drift as the model and the CVE population change.

Aggregating across assets

Because the score is a probability, it can be rolled up. FIRST's user guide shows that 100 vulnerabilities each at 5 percent give a 99.4 percent chance that at least one is exploited (1 minus 0.95 to the power of 100). That supports posture metrics per server, subnet or business unit, but treat it as an indicator: the calculation assumes independence, and exploitation of one CVE on a host does not mean that host is attacked. Report the aggregate alongside the count of open KEV findings, so leaders see both the forecast and the evidence, and so a falling aggregate is not mistaken for the absence of exploited flaws.

Choosing thresholds: coverage, efficiency and effort

EPSS performance is described in three terms. Effort is the share of vulnerabilities you prioritise; coverage (recall) is the share of exploited vulnerabilities you caught; efficiency (precision) is the share of your prioritised set that was actually exploited.

The lesson is not that one number is right. Lower thresholds raise coverage and effort; higher thresholds raise efficiency and miss more. Decide what coverage you need for each asset class and set the threshold that delivers it.

How to set your thresholds

1. Pull history: download daily EPSS files for the past 6 to 12 months and your scanner findings for the same period.
2. Define "exploited" for evaluation: use KEV additions and your own threat intelligence or SOC detections as ground truth.
3. Simulate: for candidate thresholds (for example 0.01, 0.05, 0.1, 0.3), compute effort, coverage and efficiency on your own findings.
4. Pick per tier: internet-facing and identity-critical assets get a low threshold (high coverage); internal low-value assets a higher one.
5. Write it into policy: tie each tier to a remediation SLA. See the Remediation SLAs and Vulnerability Exceptions Guide.
6. Review quarterly and after each model release: repeat the simulation and adjust.

Combining EPSS with CVSS, KEV, SSVC and asset context

FIRST's user guide suggests a simple quadrant using CVSS for severity and EPSS for likelihood. The quadrant is a starting point; KEV and asset context change the answer.

• KEV first: CISA adds a CVE to KEV only with reliable evidence of active exploitation and clear remediation guidance. A KEV entry should go to the top regardless of its EPSS score. See the CISA KEV Catalogue Guide.
• CVSS v4 threat metrics: the CVSS v4 Exploit Maturity metric (Attacked, Proof-of-Concept, Unreported, Not Defined) is populated by the consumer from threat intelligence, and Not Defined is scored as Attacked. One defensible rule is to set Attacked for KEV entries and your own confirmed detections, and use EPSS only as supporting evidence when choosing between Proof-of-Concept and Unreported; document whichever rule you use. See the CVSS v4 Guide.
• SSVC: CISA's SSVC decision tree uses exploitation status as a decision point; EPSS can inform that point where no direct evidence exists. See the SSVC Guide.
• Asset context: FIRST lists asset accessibility, weakness type, asset purpose and value, and network context as factors the asset owner must add. An EPSS of 0.4 on an isolated test box is less urgent than 0.05 on an internet-facing VPN appliance.
• LEV: NIST CSWP 41 (May 2025) proposes a Likely Exploited Vulnerabilities metric, estimating the likelihood that a vulnerability has already been observed exploited, which the authors say may augment EPSS and help measure how complete KEV lists are. Treat it as a research proposal for now.

Limits worth explaining to stakeholders

• New CVEs: a CVE published today has little history, so its first scores rest mostly on descriptive data. Treat early low scores on exposed products with caution and re-check daily for the first two weeks.
• Visibility bias: ground truth comes from partner sensors. Exploitation of products that sensors rarely see, such as niche OT devices or internal-only applications, may be under-represented.
• Attempts, not success: the model learns from attempted exploitation, so a high score says attackers are trying, not that attempts work against your configuration.
• Chained attacks: FIRST notes that the effect of chaining several low-scoring flaws needs further research; a chain on one asset can matter more than any single score.

Building EPSS into the pipeline

1. Ingest daily: pull the full daily CSV or query the API (base URL https://api.first.org/data/v1/epss, with parameters such as cve, date, scope=time-series, epss-gt and percentile-gt). Store each day's score with the model version.
2. Join to findings: attach the current probability and percentile to each open finding by CVE in the scanner, vulnerability management platform or data lake.
3. Flag movement: alert when an open finding crosses your threshold or rises sharply day on day, so it is re-prioritised without waiting for the next report.
4. Overlay KEV and asset tier: compute a priority from KEV status, EPSS band, CVSS and asset criticality; keep the rule simple enough to explain to auditors.
5. Handle gaps: findings without a CVE (misconfigurations, vendor-only advisories) and newly published CVEs with little data need a fallback rule, usually CVSS plus asset tier.
6. Pilot and roll back: run the new priority in shadow mode for a month beside the current CVSS-based queue, compare what each would have caught against KEV additions, then switch. Keep the old rule available for rollback.

Decision guidance by organisation size

• Small teams: use the EPSS value shown by your scanner or patch tool, patch KEV first, then anything above a single threshold on exposed assets. Avoid building a custom model.
• Mid-size teams: ingest daily EPSS into the vulnerability platform, set two or three tiers, and report coverage monthly.
• Large teams: store full history, simulate thresholds on your own data, include EPSS in risk-based scoring with asset and identity context, and measure the model's performance against your own detections. See the Risk-Based Vulnerability Management Guide.

Detection and measurement

• Coverage of exploited CVEs: percentage of CVEs added to KEV in the period that were already above your threshold before the KEV listing.
• Effort: percentage of open findings in the urgent tier; if it climbs above your capacity, the threshold is too low or asset tiers are wrong.
• Efficiency: percentage of urgent-tier CVEs later seen exploited (KEV or your own detections).
• Time to remediate by tier: median days for KEV, high-EPSS and other findings on exposed assets.
• Score latency: hours from EPSS publication to the score being visible on findings; it should be under one day.
• Aggregate exposure: the probability that at least one urgent finding is exploited, per business unit, tracked over time as a trend.

Where identity fits

The flaws that score highest are often in edge devices and remote access services, and their exploitation usually ends in credential or session theft rather than a single compromised host. When a high-EPSS or KEV vulnerability affects a product that stores tokens, keys or service account passwords, the remediation ticket should include rotating them. The CitrixBleed case shows the gap: the flaw was added to KEV on 18 October 2023, a public proof of concept followed on 25 October, mass exploitation began, and stolen session cookies stayed valid after patching. See the Leaked Credential Response Playbook.

Framework mapping

Common failure patterns

• Using EPSS as a risk score: FIRST is explicit that it is not one. A low score on a critical, exposed asset can still be the top risk.
• Thresholding on percentile: percentiles drift with the CVE population and model versions, and imply urgency that the probability does not support.
• Ignoring KEV because EPSS is low: a forecast does not override evidence. Exploited CVEs can have modest scores, especially soon after disclosure.
• Scoring once: taking the EPSS value at ticket creation and never refreshing it misses CVEs that rise after a proof of concept or campaign.
• Reading low as zero: the user guide notes a lower score means lower threat, never no threat; the model observes attempts, not successes, and only for monitored activity.
• Comparing across model versions: trend charts that span a model release mix two different distributions.

Practitioner checklist

• Ingest EPSS daily with model version and store history.
• Display probability as the score, with the percentile as context.
• Put every KEV entry in the top tier regardless of EPSS.
• Set thresholds per asset tier from a simulation on your own findings.
• Add asset exposure, value and identity context before setting SLAs.
• Alert on open findings that cross the threshold between scans.
• Define a fallback rule for findings without a CVE or EPSS score.
• Report coverage, effort and efficiency monthly.
• Re-baseline thresholds after each EPSS model release.
• Rotate credentials held by products affected by high-EPSS or KEV flaws.

Standards and references

• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: EPSS User Guide
• FIRST: The EPSS Model
• FIRST: Probability, Percentiles, and Binning
• FIRST: EPSS API
• CISA: Known Exploited Vulnerabilities
• FIRST: CVSS v4.0 Specification Document
• NIST: CSWP 41 Likely Exploited Vulnerabilities

Related NHI Mgmt Group resources: Vulnerability Prioritisation Guide · CISA KEV Catalogue Guide · SSVC Guide · CVSS v4 Guide