Use EPSS as a changing exploitation forecast—not a complete risk score

Bottom line: EPSS is a dated forecast about observed exploitation activity for a CVE over the next 30 days. It does not know whether you run the product, how a successful exploit would affect you, or whether your controls change the outcome.

Source fact: what FIRST says EPSS measures

The official FIRST EPSS FAQ describes EPSS as a data-driven model that estimates the probability that exploitation activity associated with a publicly disclosed CVE will be observed in the wild within the next 30 days. Scores range from zero to one and are updated daily. FIRST distinguishes the probability from the percentile: probability is the model’s absolute forecast, while percentile ranks a vulnerability relative to the currently scored population.

FIRST explicitly states that EPSS is not a complete risk score. It does not estimate impact, know an organization’s assets, or account for its compensating controls. The FAQ also distinguishes the forward-looking EPSS estimate from CISA’s Known Exploited Vulnerabilities catalog, which records confirmed exploitation, and says direct exploitation evidence should supersede a forecast.

What the source does not establish

A low EPSS score is not proof that exploitation is impossible or that remediation can be ignored. A high percentile can coexist with a modest absolute probability because the score distribution is not uniform. A score changes as inputs change, so an undated dashboard value is weak evidence.

EPSS does not replace vendor severity, CVSS context, contractual deadlines, emergency directives, safety assessment, or environment-specific risk analysis. Combining unrelated scores through an invented formula can create a number without a defensible meaning.

Applicability questions

• Is the exact CVE applicable to an installed, reachable, and consequential asset?
• What EPSS probability, percentile, model information, and date were retrieved?
• Is there authoritative direct evidence of exploitation, including CISA KEV or a vendor or agency statement?
• What would successful exploitation mean for confidentiality, integrity, availability, safety, customers, and recovery?
• Which supported fix or mitigation exists, and what is the operational cost and risk of delay or change?

DSE recommendation: use EPSS as one time-sensitive signal

The following steps are DSE recommendations based on the cited source.

1. Store the CVE, EPSS probability, percentile, retrieval date, and data source. Refresh according to the workflow’s decision cadence and retain history for material decisions.
2. Give confirmed exploitation and binding emergency requirements precedence over a predictive score. Record the authoritative source and date.
3. Confirm product, version, configuration, exposure, and ownership before creating or closing remediation work.
4. Combine the forecast qualitatively or through a documented risk method with impact, asset criticality, exposure, controls, safety, recovery, patch availability, and change risk.
5. Define threshold behavior as a work-queue rule, not a claim that every vulnerability above the line will be exploited or every one below it is safe.
6. Measure the program: review prioritized, deferred, exploited, and false-assumption cases and adjust the workflow transparently.

Verification and evidence

Sample vulnerability decisions across high and low EPSS values. Reconstruct the dated score, applicability, direct exploitation checks, impact and exposure context, owner, remediation or acceptance decision, due date, change evidence, and reassessment. Confirm that a score change or KEV addition can update the queue.

Official references

• FIRST EPSS Frequently Asked Questions — Forum of Incident Response and Security Teams; living definition and limitations
• FIRST EPSS data and API — Forum of Incident Response and Security Teams; official score access
• CISA Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency; confirmed-exploitation catalog