EPSS Explained: What the Score Means — and Should You Ignore a Low EPSS Score?
The Nisura Team ·
Open almost any vulnerability report today and you'll find an EPSS score next to each CVE — a number between 0 and 1 that looks reassuringly precise. It's also one of the most misread numbers in security. The most common mistake is the tempting one: “EPSS is 2%, so we can ignore it.” Sometimes that's right. Often it's exactly backwards. Here's what the score actually is, and when a low one is safe to deprioritise — straight from FIRST, the body that publishes it.
What EPSS actually is
The Exploit Prediction Scoring System (EPSS) is, in FIRST's own words, “a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days.” It's maintained by the EPSS Special Interest Group at FIRST, with scores generated by Empirical Security and published free and openly — every day, for every CVE — via CSV, API, and a GitHub repo. The exploitation signals come from partners including VulnCheck KEV, the Shadowserver Foundation and LevelBlue (AlienVault OTX).
Two properties matter more than anything else:
- It's a calibrated probability, not a severity. An EPSS of 0.20 is a real, testable claim: “vulnerabilities that look like this one are observed being exploited about 20% of the time within 30 days.” That is a fundamentally different thing from CVSS, which rates how bad exploitation would be, not how likely it is.
- It's population-level, not about you. EPSS has no idea what's in your environment, whether an attacker can reach it, or what it would cost you if they did. It scores the vulnerability, not your exposure.
Each score also ships with a percentile — the percent of all CVEs at or below that score. Percentile and probability are not the same number, and conflating them is misuse #1 (more below).
And it's a real model, not a rubric. Per FIRST, EPSS is an XGBoost classifier trained on ~120 million rows × ~2,850 features against 1.6 million+ observed daily exploitation events, now in its fifth generation. The features include exploit-code and tooling signals (public PoCs, Nuclei templates, Shodan), “chatter” across security sources, the individual CVSS metrics (the model uses the metrics but ignores the CVSS score), and the vulnerability's age. Critically, the output is calibrated: a score of 0.05 means CVEs like this are exploited about 5% of the time, and 0.30 means about 30% — a testable claim, not a vibe.
EPSS, CVSS and KEV — three different questions
- CVSS — how severe is it if exploited? A technical impact score. It leaves you with thousands of “criticals” and no ordering.
- EPSS — how likely is exploitation in the next 30 days? A forward-looking probability.
- CISA KEV — has it actually been exploited? A record of confirmed, in-the-wild exploitation. History, not forecast.
They're complementary, and the interesting cases live where they disagree.
The distribution nobody has intuition for
Here's the fact that breaks most people's instinct about “low” scores. In any given 30-day window, FIRST tracks exploitation activity for only about 1.5%–3% of published vulnerabilities. The mean EPSS score is ~2.8%; the median is ~0.7%. It is a long-tailed distribution — the vast majority of CVEs sit near zero, and that is correct, because the vast majority are never exploited. FIRST puts it starkly: of ~350,000 published CVEs, only roughly 10,000 see exploitation activity in a given 30-day window — so a perfectly calibrated model would score about 97% of all CVEs at 0%. For reference, CISA KEV lists only ~0.5% of published CVEs.
So the school-grade intuition — “90–100% is the A-grade, that's the critical band” — is badly wrong. Per FIRST, a threshold at 90% selects just the top 0.2% of scored vulnerabilities. And “50% feels like the top half” is nonsense: with a base rate near 2%, a 0.5 threshold deprioritises 98.8% of everything. On this scale, a “low” 4% score is already around the 90th percentile — roughly the effort-equivalent of a CVSS-Critical filter, per FIRST's own translation.
So — should you ignore a low EPSS score?
Not on its own. A low EPSS score is a deprioritisation signal, never an all-clear. FIRST is explicit that “thinking small probabilities are safe” is a misuse. Three things override a low score:
1. Small probabilities add up across a portfolio
A 5% score sounds ignorable until you have a thousand of them. Because EPSS scores are calibrated probabilities, you can aggregate them — and FIRST spells out the maths. The probability that at least one of n vulnerabilities is exploited is 1 − ∏(1 − p). For 100 vulnerabilities each scoring 0.05, that comes to ~99.4%, with an expected 5 of them exploited in 30 days. “1 in 20” stops feeling safe at scale. (That saturating formula is exactly how a serious risk engine combines vectors — it's the same “an attacker only needs one to work” logic behind Nisura's likelihood model.)
2. If it's on CISA KEV, the EPSS score is irrelevant
A low EPSS on a KEV-listed CVE is not a contradiction: KEV records that exploitation happened, EPSS forecasts the broader population signal. FIRST's rule of thumb is blunt: “when a vulnerability appears on CISA KEV, treat it as actively exploited and prioritise accordingly, regardless of EPSS score.” Confirmed, recent exploitation beats a forecast every time. (This is why our CVE radar lets KEV outrank a quiet EPSS — a 2022 firewall bug at low EPSS but on KEV is still a live door.)
3. EPSS doesn't know your environment — localise it
FIRST prescribes three checks to turn a population score into a real decision:
- Presence — do you actually run the affected thing? A 97% EPSS on software you don't have is a non-event.
- Reachability — is it internet-facing, unauthenticated, uncompensated? A low-EPSS bug on an exposed edge appliance can matter more than a high-EPSS one buried behind three controls.
- Consequence — what does exploitation cost you? The same CVE on a crown-jewel asset versus an isolated test box carries completely different weight.
Remediation pays off most where high EPSS × confirmed presence × reachability × high consequence all line up. Drop any one and the urgency falls — regardless of the score. That “consequence” axis is the one EPSS can never give you, and it's the one Nisura prices in euros.
4. A low score on a brand-new CVE can be cold-start, not safety
On disclosure day, a CVE often has thin signal — no chatter, no public exploit, no observed activity yet — so EPSS scores it low because the evidence hasn't accumulated, and it updates as that changes. FIRST is explicit that a low early score “should not be mistaken” for safety. The flip side is one of EPSS's most counter-intuitive findings: age is the single strongest vulnerability feature — CVEs older than two years are exploited at roughly five times the rate of ones under a month old. So a persistently low EPSS on an old, exposed edge bug is a meaningful signal; a low EPSS on a fresh one is provisional. (More on why old CVEs dominate real attacks in this piece.)
The common misunderstandings (per FIRST)
- “Score laundering.” Don't multiply EPSS × CVSS and call it a “risk score.” EPSS is a calibrated probability; CVSS is an ordinal ranking with no empirical calibration. The product has no interpretable meaning.
- Percentile ≠ probability. A 0.94 percentile means “higher than 94% of CVEs,” not “94% chance of exploitation.” They're different axes; report the one you mean. (For scale: a 10% probability currently sits around the 95th percentile.)
- “Critical CVSS but low EPSS” is not a contradiction. FIRST states the two are empirically uncorrelated — high CVSS severity is “slightly better than random” at predicting exploitation. A bug can be both genuinely severe if exploited and genuinely unlikely to be exploited. Don't let a red CVSS badge override a low exploitation probability (or vice-versa) — they answer different questions.
- It's not a live attack feed. Exploitation activity trains the model but isn't a same-day lookup — a fresh KEV entry or a trending headline doesn't instantly move the score. Use KEV for “happening now”; use EPSS for the forward probability.
- Don't judge it on one CVE. A single surprising score says nothing about a system scoring hundreds of thousands daily. Judge the model against realistic alternatives, not perfection (the “nirvana fallacy”).
- Don't pick a threshold that “feels right.” Intuition anchors (50%, 90%) are wildly off given the ~2–3% base rate. Start from the coverage/effort tradeoff and tune over time.
- “I just don't trust predictions.” Every fixed rule — “patch all Criticals,” “patch all KEV” — is itself a prediction about future exploitation. EPSS just states its claim explicitly and measures whether it holds.
How to use EPSS well
FIRST's practical translations are a good starting point for a program migrating off CVSS: matching a CVSS-Critical workload is roughly the 90th EPSS percentile (≈ 0.04); matching CVSS-High-and-above is roughly EPSS ≥ 0.008. A flat 0.10 (10%) threshold is widely cited but, in FIRST's own words, “carries no special authority from EPSS” — there's no universal cutoff; tune yours to your remediation capacity via the coverage/effort/efficiency framework. Then layer the signals in the right order:
- On KEV? → treat as actively exploited, fix it, ignore the EPSS.
- Otherwise, rank by EPSS as a continuous probability — not a hard cliff — for everything KEV doesn't cover (the large majority).
- Localise the top of that list by presence, reachability and consequence before you spend an engineer-hour on it.
That is precisely the logic Nisura's engine automates. We pull live EPSS (the same free FIRST feed) alongside CISA KEV, exploit maturity and edge-exposure signals, let confirmed exploitation override a quiet score, combine per-vector probabilities with the same 1 − ∏(1 − p) saturation FIRST uses — and then add the axis EPSS can't: consequence in euros, mapped to NIS2, GDPR and DORA liability. A low EPSS never disappears silently; it's weighed against what the exposure would actually cost you.
Want to see it on your own estate? Run a free passive scan to find your externally-exposed, EPSS-scored vulnerabilities, then quantify the risk in euros — prioritised by exploitation likelihood and financial impact, not raw severity.
Sources
- FIRST — EPSS home (definition, data access, maintainers)
- FIRST — Using EPSS (thresholds, KEV interaction, aggregation formula, the common-misuses list)
- FIRST — How EPSS Works (XGBoost model, ~2,850 features, calibration, known limitations)
- FIRST — Why EPSS? (the empirical case, calibration, the age effect, coverage/effort/efficiency)
- FIRST — EPSS FAQ (percentile vs probability, CVSS/KEV comparison, thresholds, base rate)
Frequently asked questions
What is an EPSS score?
EPSS (the Exploit Prediction Scoring System, maintained by FIRST.org) is a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a 0–1 probability plus a ranking percentile for every CVE, updated daily, and is free and open via CSV, API and GitHub. Crucially it is a calibrated probability of exploitation — not a severity score like CVSS — and it is population-level, so it says nothing about your specific environment.
Should you ignore a low EPSS score?
Not on its own — a low EPSS score is a deprioritisation signal, never an all-clear. FIRST explicitly lists “thinking small probabilities are safe” as a misuse. Three things override a low score: (1) small probabilities aggregate — 100 vulnerabilities each at 5% give a ~99.4% chance at least one is exploited in 30 days (1 − ∏(1 − p)); (2) if the CVE is on the CISA KEV catalog, treat it as actively exploited and fix it regardless of EPSS; and (3) EPSS is population-level, so you must localise it by presence, reachability and consequence in your own environment before dismissing it.
What is the difference between EPSS and CVSS?
CVSS measures how severe a vulnerability is if exploited (technical impact); EPSS measures how likely it is to be exploited in the next 30 days (a calibrated probability). They answer different questions and are complementary. FIRST warns against “score laundering” — multiplying EPSS by CVSS to get a combined “risk score” is meaningless, because EPSS is a calibrated probability while CVSS is an ordinal ranking with no empirical calibration.
What is a good EPSS threshold?
It depends on your coverage/effort tradeoff, but intuition is a poor guide because the base rate of exploitation is only about 2–3% of published CVEs (mean EPSS ~2.8%, median ~0.7%). Per FIRST, matching a CVSS-Critical workload is roughly the 90th EPSS percentile (≈ 0.04, a 4% probability); matching CVSS-High-and-above is roughly EPSS ≥ 0.008. A 50% threshold sounds sensible but actually deprioritises 98.8% of all vulnerabilities. Best practice: patch anything on CISA KEV regardless of score, then rank the rest by EPSS as a continuous probability and localise the top of the list.
Is the EPSS percentile the same as the probability?
No — this is a frequent misunderstanding. The probability is the actual 0–1 likelihood of exploitation in 30 days. The percentile is the percentage of all CVEs at or below that score (a relative ranking). A CVE at the 0.94 percentile is ranked higher than 94% of CVEs; it does not have a 94% chance of exploitation. Every EPSS score is published with both numbers precisely so the two are not confused.