How EPSS Works Under the Hood: From Signals to Score

How EPSS works is not mysterious. The problem is that teams treat its output like a verdict instead of a probability built from changing public signals.

EPSS predicts whether exploitation activity for a CVE will be observed in the wild during the next 30 days. It does not predict whether your server will be breached. It does not know whether you run the affected software. It does not measure business loss.

That distinction matters. A score can improve the order of a queue, but only an operating process can turn the score into a safe remediation decision.

How EPSS works in plain language

EPSS stands for Exploit Prediction Scoring System. FIRST publishes a score from zero to one for public CVEs. A score of 0.05 means the model estimates a 5 percent chance that its data partners will observe and share exploitation activity for similar cases during the next 30 days.

Think in groups, not promises about one CVE. Across 100 vulnerabilities scored near 0.05, a calibrated model expects exploitation activity for about five of them. It cannot tell you which five in advance.

FIRST's EPSS probability and percentile guidance says the observed 30 day base rate sits around 2.5 to 3 percent. A 5 percent score is therefore not trivial. The same guide says a 10 percent probability sits around the 95th percentile because most scores cluster near zero.

Use EPSS inside a larger vulnerability prioritization framework. It supplies a threat likelihood input. Exposure, consequence, controls, and change readiness still come from your environment.

What outcome does the EPSS model learn?

The target is binary for a given observation period. Exploitation activity was observed, or it was not. The model learns which combinations of vulnerability facts and public activity tend to appear before that outcome.

Historical exploitation is used as the label during training. It is not a direct switch in daily scoring. That choice is important. If a private exploitation feed directly changed tomorrow's public score, EPSS could expose information that a data partner did not permit FIRST to publish.

The design also keeps the forecast useful before public confirmation exists. Once trusted evidence proves current exploitation, stop asking a prediction model. Follow the evidence. A CISA KEV entry or a confirmed incident should override a low EPSS value.

Which features feed the model?

EPSS turns public information into model features. The documented families include individual CVSS metrics, weakness and vendor information, references, published exploit code, security tool coverage, and activity across monitored sources. The score itself is not a weighted average that an analyst can reproduce in a spreadsheet.

Interactions carry much of the value. Public exploit code may mean something different for a remote code execution flaw than for a local denial of service issue. A vendor name can also interact with product reach, reference volume, and available tooling. Static point systems usually miss those combinations.

A signal is not proof. A GitHub repository can contain a nonworking demonstration, a scanner signature, or a copied advisory. The model learns average relationships across many records. Your analyst still needs to verify a specific exploit and the affected state.

Why does EPSS use machine learning?

EPSS began with logistic regression. FIRST's current documentation says the model uses binomial XGBoost because it fit the observed outcomes better than the tested alternatives. XGBoost builds many small decision trees, then combines their corrections.

You do not need to understand every tree to use the output. You do need to understand the trade. A flexible model captures interactions that a fixed formula misses, but an individual score is harder to explain as a short list of weights.

The right trust question is not, “Can the model explain this CVE exactly?” Ask whether it is calibrated, whether it separates likely exploitation from the base rate, and whether performance holds on CVEs and time periods excluded from training.

How is an exploit prediction tested?

A model tested on its training rows can look brilliant and fail tomorrow. FIRST describes using held out CVEs and held out time periods. That simulates two real problems: a newly published vulnerability and a future period the model has never seen.

Calibration asks whether predicted probabilities match observed frequencies. If 1,000 records are scored near 0.10, about 100 should later show the defined outcome. Ranking asks whether exploited vulnerabilities concentrate near the top of the queue. Both matter. A well ranked score with poor calibration is dangerous in cost math.

Coverage and efficiency answer an operator's question: how many exploited vulnerabilities would a chosen threshold catch, and how much work would that threshold create? No threshold wins everywhere. The answer depends on capacity and the cost of a miss.

How should a team set EPSS thresholds?

Begin with work capacity and miss cost, not a borrowed percentage. Pull 90 days of finding history. For each day, preserve the EPSS value that was available then, the affected assets, the action taken, and exploitation evidence that appeared later. Replaying today's score against old decisions creates hindsight bias.

Test several policies. One might admit every validated finding above 0.10. Another might admit the top 5 percent by percentile. A third might require either KEV, a trusted campaign match, or EPSS above 0.05 on an exposed service. Count findings admitted, exploited cases covered, changes created, and hours consumed.

Suppose the first policy admits 240 changes per month while the team can complete 80. That threshold is not protective because 160 changes simply age in an urgent lane. Raise the prediction cut, add exposure gates, or create a mitigation lane. Make the displacement visible when a new urgent item enters.

Keep at least two lanes. A prediction lane handles likely exploitation without direct proof. An evidence lane handles KEV, active incidents, and trusted campaign matches. A high threshold should never delay the evidence lane.

Review the misses, not just the wins. When an exploited CVE fell below the cut, ask which signal was absent, whether local exposure should have created an override, and whether the model could reasonably know. That separates a prediction miss from a broken operating policy.

What is the difference between probability and percentile?

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

Expected counts and cost comparisons need probability. If 400 current findings each carry an average probability of 0.04, the simple expected count is 400 times 0.04, or 16 observed exploitation events across similarly scored cases. That is not a forecast that exactly 16 of your assets will be attacked.

Percentile suits queue cuts when the team can handle a fixed volume. A top 5 percent rule creates a relative work lane. Its probability threshold will move as the distribution changes.

Why does an EPSS score change every day?

Daily scoring reruns current feature values through the deployed model. A new exploit repository, a scanner signature, more references, or changed public activity can move a score. Old signals can disappear too.

Model updates are different. They retrain the relationships and can move many scores at once. Pin the model version and score date in every decision record. Otherwise a reviewer cannot reproduce why yesterday's threshold admitted a finding.

Treat a model release like a policy dependency. Run the old and new outputs side by side before the cut when beta scores are available. Measure which CVEs enter or leave the active queue, which services gain urgent work, and whether owners can absorb it. Save the comparison with the approval record.

The Verizon 2026 Data Breach Investigations Report, published May 19, 2026, says vulnerability exploitation reached 31 percent of breach entry points, up 55 percent from the prior report. It also gives a 43 day median for full resolution of a critical vulnerability. Prediction matters because attack pressure and remediation capacity do not move at the same speed.

What changed in EPSS v5 in 2026?

FIRST put EPSS v5 into service on June 15, 2026. The July 15, 2026 release note cites a general refresh, updated GitHub exploit detection, improved calibration, VulnCheck KEV data, and GitHub popularity metrics. Downstream API consumers did not need to change their integration.

This is the recent detail most older explainers miss. A stable field name does not mean stable model behavior. Compare queue volume, coverage, and overrides before and after a model cut. Do not silently let a new model redefine your remediation workload.

How do you retrieve EPSS scores correctly?

FIRST provides a free CSV archive and API. This query asks for one CVE and keeps the score, percentile, and date together:

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

The parameter syntax follows the official FIRST EPSS API documentation. Store decimal values as numbers, not formatted percentage strings. Cache the source date. Treat an empty result as missing evidence, not a zero.

For a fleet, join EPSS by CVE after you have validated the software and version. One CVE score copied across 8,000 scanner instances is still one threat signal. Group work by the remediation action the owner can deploy.

Reject malformed CVE identifiers before the request. Log API status, source date, and record count. If the service is unavailable, keep the last known score with a stale marker rather than substituting zero. A prediction pipeline that quietly converts missing data to low risk will fail exactly when upstream data has a problem.

How should a team operate EPSS?

1. Validate the affected product, version, and running state.
2. Load EPSS probability, percentile, score date, and model version.
3. Override prediction with trusted evidence of active exploitation.
4. Add reachability, control, and business consequence evidence.
5. Map the decision to an owner, action, due date, and proof.
6. Recalculate when the score, route, software, or control changes.

Compare that flow with the vulnerability risk scoring model guide and the SSVC decision framework. EPSS predicts. SSVC categorizes an action. Your operating record has to connect the two.

An older endpoint vulnerability detection guide explains why package presence alone is weak evidence. Prediction is useful only after the affected state is credible.

Which EPSS mistakes create bad priorities?

The first mistake is calling EPSS a risk score. It does not contain local exposure, asset value, probable loss, or control evidence. The second is reading percentile as probability. The third is treating a low score as permission to ignore known exploitation.

Static thresholds also age badly. A team may patch everything above 0.50 because that once fit its capacity. Six months later the same cut may admit twice the work or miss a changed distribution. Track the number of findings admitted, exploited cases caught, overrides, and time to verified closure.

Most ranking articles cover definitions, score ranges, and comparisons with CVSS. They rarely show how labels differ from daily signals, how calibration affects math, or how a model release changes queue volume. Those are the parts an operator must own.

Frequently asked questions

Is EPSS a risk score?

No. EPSS estimates the chance of observed exploitation activity for a CVE in the next 30 days. Risk also needs local exposure, consequence, controls, and response facts.

Does a 90th percentile EPSS value mean 90 percent probability?

That interpretation is wrong. It means the score ranks above 90 percent of currently scored CVEs. Read the separate probability field for the model's absolute forecast.

Should CISA KEV or EPSS win?

KEV wins when it confirms active exploitation. A prediction is useful before direct evidence exists, not after trusted evidence settles the question.

How often should EPSS data be refreshed?

FIRST publishes daily. Refresh daily for active queues, retain the score date and model version, and recalculate decisions when material inputs change.

Executive takeaway

Stop using EPSS as a colored badge. Store the probability, percentile, date, and model version. Test one threshold against 90 days of closed work, then measure coverage and queue cost. Pair the forecast with current endpoint proof and business consequence. Artemes applies deep endpoint context with AI driven analysis to that local evidence, but the decision rule and owner should remain visible.