EPSS Score: What It Means and How to Use It

An EPSS score is not severity and it is not risk. The problem is not whether the number is high or low. It is whether your team can turn a 30 day exploitation forecast into a consistent work decision.

EPSS gives you a probability for a CVE and a percentile that ranks that probability against other CVEs. It knows nothing about your installed software, network route, customer data, compensating controls, or patch window.

That makes EPSS useful. It answers one narrow question with empirical data. Trouble begins when a dashboard stretches that answer into claims the model never made.

What is an EPSS score?

EPSS stands for Exploit Prediction Scoring System. FIRST publishes a probability from 0 to 1 for public CVEs. The value estimates the chance that exploitation activity will be observed in the wild during the next 30 days. Scores are refreshed daily.

The current FIRST EPSS frequently asked questions give a concrete interpretation. A score of 0.05 means 5 percent. Across 100 vulnerabilities with scores near 0.05, the calibrated forecast expects observed exploitation activity for about five of them during the next 30 days.

EPSS supplies the threat likelihood input inside a vulnerability prioritization program. Do not call it a risk score. Risk also needs affected state, exposure, consequence, controls, and response facts from your environment.

What is the difference between EPSS probability and percentile?

Probability is the forecast. Percentile is the rank. A vulnerability at the 95th percentile has an EPSS probability at least as high as 95 percent of currently scored CVEs. It does not have a 95 percent chance of exploitation.

FIRST reports that a 0.10 probability currently sits around the 95th percentile. That relationship moves because the full score distribution changes. Store both fields. Label them clearly.

Use probability for expected counts and cost comparisons. Use percentile when capacity requires a relative queue cut. If your team can review the top 5 percent of current findings, percentile can define that lane. The absolute probability at the boundary will move.

The small numbers are not an error. FIRST reports a 30 day observed exploitation base rate around 2.5 to 3 percent and says the CISA KEV Catalog contains roughly 0.5 percent of published CVEs. A 5 percent EPSS probability is above the observed base rate even though it sounds small in isolation.

How should you use EPSS score math?

Suppose 200 validated findings have an average EPSS probability of 0.04. The simple expected count is 200 times 0.04, or eight observed exploitation events across many comparable cases. It does not predict that exactly eight of your assets will be attacked.

Now suppose your patch team can complete 40 remediation actions this month. A threshold that admits 110 actions is not a priority policy. It is an urgent backlog generator. Test probability and percentile cuts against historical capacity, then add direct evidence and local exposure gates.

Expected counts are useful for comparing policy options. Do not add percentiles, average them, or multiply EPSS by a CVSS Base score. Percentile is rank. CVSS Base is an ordinal severity measure. The result of multiplying them has no stable meaning.

How should EPSS work with CVSS and CISA KEV?

CVSS and EPSS answer different questions. CVSS describes technical severity under a stated vector. EPSS forecasts observed exploitation. CVSS v4 Threat and Environmental metrics can enrich severity without turning it into a complete priority.

CISA KEV records confirmed exploitation evidence. CISA says organizations should use the Known Exploited Vulnerabilities Catalog as an input to prioritization. If a CVE is in KEV, follow the evidence. A low forward forecast does not erase exploitation that already happened.

A useful order is simple. Confirm the affected product and version. Check KEV and trusted incident evidence. Read EPSS when direct evidence is absent. Add reachability, service consequence, and controls. Then assign the action and due date.

The detailed comparison of CVSS and EPSS shows why severity and probability belong beside each other, not blended into a mystery score.

What EPSS threshold should a team use?

There is no universal threshold. Begin with the work your owners can finish and the misses your organization cannot tolerate. Test candidate policies against closed findings with the score that existed on the decision date.

Try three policies. One admits validated findings above 0.10. Another admits the top 5 percent by percentile. A third admits KEV plus exposed findings above 0.05. For each policy, count actions created, exploited CVEs covered, urgent work completed, overrides, and analyst hours.

Keep a separate evidence lane for KEV, active incidents, and trusted campaign matches. A prediction threshold should never delay direct evidence. Add a service override for exposures where loss would be unacceptable even if public threat signals remain thin.

Review misses every month. Ask whether the model lacked a public signal, whether local exposure should have forced an override, or whether affected state was wrong. A threshold can improve only when the team knows which layer failed.

How do you backtest an EPSS policy?

Freeze a review period before looking at the answer. Ninety days is a useful start because it contains three separate 30 day forecast windows. Export every validated finding, the remediation action it joined, the service owner, and the action taken.

Use the EPSS score that was published on each decision date. Today's score contains signals that were not available then. Applying it to an old queue gives the policy knowledge it could not have had and makes the result look better than it was.

Define success before testing cuts. Count direct exploitation evidence captured, exposed services admitted, actions created, actions completed inside the target, analyst hours, and overrides. Also count urgent actions that displaced other work. A policy that catches more threat but creates five times the team's capacity is not executable.

Compare at least one probability cut, one percentile cut, and one combined rule. For example, test 0.10 probability, 95th percentile, and KEV or exposed plus 0.05 probability. Keep all local gates the same so the difference comes from the EPSS rule rather than changed asset data.

Inspect individual misses after the totals. If a missed CVE had no public signal but a sensitive exposed service, improve the local override. If the CVE was not installed, fix finding validation. If direct evidence arrived after the decision, test whether your evidence lane refreshed fast enough.

Save the test as a policy record. Include the dataset dates, model versions, candidate rules, capacity assumption, exclusions, reviewer, and approval. Repeat the test when a new EPSS model goes live or ownership capacity changes by more than your policy tolerance.

The final output should be a workload choice, not a claim that one threshold is objectively best. If 0.10 admits 64 actions and 0.15 admits 38 while owners can close 40, leadership can see the trade. It can fund more capacity, accept the smaller coverage, or add a sharper exposure gate.

Keep the rejected candidate results too. They show why the approved line exists and stop a future reviewer from mistaking a policy choice for a universal property of EPSS.

How do you retrieve an EPSS score correctly?

FIRST offers a public API and daily CSV files. This command uses the official EPSS API parameters to retrieve the last 30 days of scores for one CVE:

curl -s 'https://api.first.org/data/v1/epss?cve=CVE-2024-3094&scope=time-series' \
  | jq '.data[] | {cve, epss, percentile, date}'

Store `epss` and `percentile` as decimal numbers. Retain the score date and model version. Treat no returned record as missing data, not zero. If the API is unavailable, use the last known value with a stale marker and alert the data owner.

Join scores to validated CVE instances, then group work by remediation action. One CVE found on 4,000 endpoints has one global EPSS probability, not 4,000 independent probability observations.

The deeper guide to how EPSS works covers training labels, features, calibration, model testing, and daily score changes. Operators using the feed should understand those mechanics before building automated thresholds.

What changed in EPSS v5 in 2026?

FIRST put the v2026.06.15 model refresh into production on June 15, 2026. Its July 15, 2026 EPSS v5 update lists refreshed model data, updated GitHub exploit code detection, an improved calibration step, VulnCheck KEV data, and GitHub popularity metrics. API consumers did not need to change field names.

That is the recent detail older EPSS explainers cannot cover. A stable API does not mean stable queue behavior. Record the model version and compare how many actions cross your threshold before accepting a new model in production policy.

Run old and new scores beside each other when beta data is available. Count actions entering and leaving the urgent lane, service owners affected, and known exploited cases captured. A model update should produce a reviewed workload change, not a surprise Monday morning ticket surge.

Which EPSS mistakes create bad decisions?

The first mistake is treating percentile as probability. The second is treating EPSS as local risk. The third is letting a low score overrule KEV or incident evidence. All three come from asking the score to do work that belongs elsewhere.

Static thresholds create another failure. Score distributions, model versions, and team capacity change. A cut that admitted 30 actions last quarter may admit 90 now. Track queue volume and closure, not just score coverage.

Most ranking pages explain the definition, probability, percentile, CVSS, and KEV. Few show how to test a threshold against capacity, handle missing data, preserve historical scores, or review a model update. Those operating controls are what make EPSS safe to automate.

Frequently asked questions

Is a higher EPSS score always more urgent?

It means the model forecasts a higher chance of observed exploitation. Urgency still depends on whether you are affected, exposed, and facing material consequence.

How often does an EPSS score change?

FIRST publishes scores daily. Public exploit code, references, security tool coverage, and other signals can move the forecast.

Can EPSS replace CVSS?

No. EPSS forecasts exploitation probability. CVSS describes technical severity. A useful decision needs both kinds of evidence plus local context.

What should happen when EPSS data is missing?

Mark it missing, keep the last value with its date if policy permits, and use other evidence. Never silently convert missing data to zero.

Executive takeaway

Pick one active queue and store EPSS probability, percentile, score date, and model version. Preserve direct exploitation evidence in a separate lane. Test three threshold policies against 90 days of work, then choose the one owners can finish without missing exposed services. Artemes applies deep endpoint context with AI driven analysis to local state, but EPSS should remain visible as the narrow forecast it is.