EPSS provides an empirical estimate of which CVEs are likely to attract exploitation activity in the near term. Trouble starts when a team turns that probability into an SLA before deciding what the program is trying to accomplish.
A threshold is not just a data setting. It controls how much work enters the urgent queue, how much likely exploitation the program covers, and how often engineering teams are interrupted. Choosing it is a risk and capacity decision.
Use EPSS for the question it answers
The Exploit Prediction Scoring System estimates the probability that exploitation activity for a published CVE will be observed in the next 30 days. It does not measure:
- Whether the vulnerable product is deployed in your environment
- Whether the affected instance is reachable
- The business consequence of exploitation
- The strength of compensating controls
- Whether remediation is safer than a temporary mitigation
EPSS should therefore enrich an exposure decision, not replace one.
A practical signal stack
I use five questions to structure prioritization:
| Question | Useful evidence |
|---|---|
| Is the finding real and applicable? | Product inventory, version evidence, validation |
| Is exploitation known or increasingly likely? | CISA KEV, EPSS, trusted threat intelligence |
| Can an attacker reach it? | Internet exposure, attack paths, identity boundaries, controls |
| What happens if exploitation succeeds? | Service criticality, data, privilege, safety, financial impact |
| What response reduces risk fastest? | Patch, mitigation, isolation, detection, retirement, acceptance |
CVSS remains useful in that stack, but as a description of technical severity—not as a complete risk score.
Do not inherit someone else’s bins
FIRST publishes probability and percentile; it does not define universal “critical,” “high,” or “low” EPSS bands. Converting a continuous probability into operational tiers can simplify workflow, but it also discards information and creates hard boundaries between nearly identical scores.
That does not make thresholds wrong. It makes them policy. Each organization should be able to explain:
- Why a threshold exists
- How much remediation work it generates
- What share of later-observed exploitation it captures
- Which additional signals can raise or lower the response
- Who can approve exceptions and when they expire
- How model changes trigger revalidation
A low-EPSS vulnerability on a highly exposed, high-consequence asset may still require urgent action. A high-EPSS CVE that is not present does not create exposure in that environment.
As of September 2026, EPSS v5 is the current production model. Any policy tuned to a v3 or v4 score distribution should be reassessed with current data rather than carried forward unchanged.
Choose thresholds with coverage and effort
FIRST recommends thinking in terms of the tradeoff between coverage and effort:
- Coverage: What fraction of vulnerabilities that are later exploited did the policy select?
- Effort: What fraction of the vulnerability population did the policy require the organization to address?
- Efficiency: Of the vulnerabilities selected, what fraction were later observed as exploited?
The right operating point is not necessarily the highest possible coverage. Chasing 100% can reproduce the same unmanageable queue that risk-based prioritization was meant to solve. The decision should reflect the organization’s threat exposure, consequence tolerance, and actual remediation throughput.
Turn a threshold into an operating process
1. Enrich at a defined cadence
EPSS scores change daily. Store the score, percentile, publication date, and model version with the finding. Use the API for small lookups and FIRST’s daily CSV for bulk enrichment, following its published data guidance.
2. Keep KEV as an independent signal
Do not assume a high EPSS threshold will capture every vulnerability already known to be exploited. Check CISA KEV separately and define how known exploitation changes response.
3. Join to asset and control context
At minimum, add service ownership, business impact, external exposure, environment, data sensitivity, and available mitigations. The quality of those inputs often limits the quality of the final priority more than another decimal place in a threat score.
4. Define actions, not just colors
Every tier should map to an owner, a response window, permitted mitigations, an escalation path, and an expiring exception process. If “red” does not change who does what by when, it is decoration.
5. Measure outcomes and burden
Track aged high-risk exposure, exploited vulnerabilities missed by the policy, emergency work generated, exception volume, recurrence, and remediation throughput. Revisit thresholds when the model, threat environment, asset base, or engineering capacity changes.
What to tell executives
Avoid presenting EPSS as an oracle. A useful executive explanation is:
EPSS helps us estimate near-term attacker interest. We combine it with known exploitation, reachability, control strength, and business impact to decide where remediation capacity reduces the most exposure.
That statement is accurate, understandable, and honest about the limits of the model.
The value of EPSS is not that it eliminates judgment. It gives judgment better evidence. A mature program preserves the distinction.
Lessons learned
A useful probability does not become an organizational priority simply because it crossed a convenient line. The line determines workload, coverage, interruptions, and what may be missed. That makes it a policy choice, not a data-engineering default.
Use EPSS as evidence of threat likelihood while keeping applicability, KEV status, reachability, consequence, control strength, and response options in view. Then compare the policy with later-observed exploitation, aged consequential exposure, missed cases, remediation burden, exceptions, and available capacity. Revisit it when either the model or the environment changes.
This is why model lineage matters. The EPSS v4 retrospective explains the governance problem; the v5 production comparison shows how far fixed-threshold populations can move while an integration continues to run normally.
How did your organization choose its EPSS decision threshold, and which outcome—not queue size—would cause you to change it?
Sources and disclosures
- FIRST: EPSS overview
- FIRST: using EPSS
- FIRST: current and historical EPSS data
- CISA Known Exploited Vulnerabilities catalog
This is independent implementation guidance based on public FIRST and CISA material and the author’s vulnerability-management experience. It is not affiliated with or endorsed by FIRST or CISA. The article defines no universal EPSS threshold and describes no private scoring implementation.
