A tenfold lower EPSS threshold buys 1.54x the coverage for 8.5x the work

A 400-item vulnerability backlog sorted by CVSS severity is a queue with no bottom. The arithmetic takes one screen.

EPSS scores the probability a CVE will be seen exploited in the next 30 days; CVSS scores how bad it would be. On the EPSS score file for 28 October 2026, 4.4% of all 396,966 scored CVEs clear a 10% EPSS threshold and 37.3% clear 1%. In a 400-item backlog that is 18 findings against 149.

Four hundred is a round number laid over a real file. Nothing below was measured on anybody’s systems: every count is arithmetic over the daily CSV that Empirical Security generates for FIRST’s EPSS Special Interest Group, and the command that reproduces it is further down the page.

What EPSS measures that CVSS does not

One is a calibrated probability of observed exploitation over thirty days; the other is an expert severity ranking with no calibration against outcomes. FIRST states the first half in the opening section of Using EPSS:

The EPSS score is a calibrated probability: the estimated likelihood that exploitation activity for a given vulnerability will be observed across EPSS data partners in the next 30 days. Not a “severity” score and not a complete risk score. A probability with testable, empirical meaning.

The second half comes from the people who own CVSS, who are also FIRST. The CVSS v4.0 FAQ, in an entry its changelog dates to v1.9 on 24 June 2026, says “CVSS-B Base scores are not risk”. Six words, from the standard’s own maintainers, who then hand the prioritisation job to CISA’s BOD 26-04.

Calibration licenses every number below. FIRST’s Why EPSS? page puts it as a frequency claim: 500 CVEs scoring near 10% should produce “roughly 50 exploitation events among them in the next 30 days”. The How EPSS Works page says “The window is chosen (without much fanfare) to match practitioner decision cycles”. Hold on to the thirty days. It breaks the plan at the end of this article.

How many of 400 findings clear a 10% probability threshold?

Seventeen point six of them. On the file for 28 October 2026, 17,496 of 396,966 scored CVEs sit at or above 0.10: 4.4074% of the population, and 400 x 0.044074 = 17.63 findings. Drop the line to 1% and 148,122 qualify, 37.3135%, or 149.25 of the same 400. The queue multiplies by 149.25 / 17.63 = 8.47.

curl -sL https://epss.empiricalsecurity.com/epss_scores-current.csv.gz \
  | gunzip -c | awk -F, 'NR>2 && $2>=0.1' | wc -l
# 17496

The NR>2 is load-bearing. That file’s first line is a comment — #model_version:v2026.06.15,score_date:2026-10-28T12:03:13Z — and the second carries cve,epss,percentile. Skip a single line and the column names stay in the data, where awk compares the string epss against 0.1 and counts the row: NR>1 returns 17497. FIRST’s API agrees with NR>2.

Coverage and efficiency are FIRST’s terms, defined five headings down How EPSS Works under “Measuring performance”: “Coverage is the fraction of exploited vulnerabilities a given score threshold captures”, efficiency the matching precision.

Coverage and efficiency in per cent, for four EPSS thresholds on the 28 October 2026 file against a 400-item backlog.

Both columns are expected values from the published scores, not FIRST’s measured performance. Work one row: the 396,966 scores sum to 10,476.92, the 17,496 at or above 0.10 carry 6,094.2 of it, so coverage is 6,094.2 / 10,476.92 = 58.17% and efficiency is 6,094.2 / 17,496 = 34.83%.

The obvious estimate is that work and result scale together: cut the threshold tenfold, do ten times the work, collect ten times as much. The work half holds at 8.47x. The result half comes in at 1.54x. The distribution is the hidden factor: the median published score is 0.00629 against a mean of 0.026392, so the first 58.17 points of coverage cost 17.63 findings, 0.303 a point, and the next 31.68 points cost 131.62 findings, 4.155 a point. Coverage gets 13.7 times dearer on the way down.

Work out the remediation capacity a threshold needs before you set it

Capacity is the input and the threshold is the output, not the other way round. Take a chosen budget of one engineer two days a week: 8 engineer-days a month, and 8 x 8 = 64 hours. Put a chosen 90 minutes on each finding, and 64 / 1.5 = 42.7 findings a month. That is 42.7 / 400 = 10.67% of the queue, and the score selecting 10.67% of the population is 0.0357. Coverage at that line is 7,506.7 / 10,476.92 = 71.65%, the same division as the table. Nobody picked that threshold. The capacity picked it.

Run the ladder the other way and start from the backlog of 400 findings rather than the budget. EPSS 0.04 is cleared by 9.5099% of the population, which selects 38.04 of them. At 90 minutes each, 38.04 x 1.5 = 57.1 hours. Divide by an eight-hour day: 7.1 engineer-days. Divide again by five and the queue at that threshold is 1.4 working weeks, which against 8 engineer-days a month leaves 0.9 of a day spare.

How much exploitation sits in those 400 findings? Two routes, and they could have disagreed by half. The mean score is every published score over the row count, 10,476.92 / 396,966 = 0.026392, so 400 items at population rates carry 10.56 expected exploitation events in thirty days. The second route never touches the model: the EPSS FAQ says EPSS observes “roughly 2.5-3% of published CVEs with exploitation activity” in a 30-day window, so 400 x 0.025 = 10.0 against 400 x 0.03 = 12.0. The first route lands inside the second’s range.

Apply FIRST’s aggregation rule from the “Aggregating probabilities across vulnerabilities” section of Using EPSS, three headings down past a seven-row risk-framework table: the chance that none of the 400 sees exploitation in thirty days is (1 - 0.026392)^400 = 0.0000226. At least one does, at 99.998%.

The question was never whether something in that backlog gets attacked; the question is which ten.

The threshold we defend is EPSS 0.04, and here is the arithmetic

Set the line at 0.04 and fewer than one in five of the vulnerabilities you patch were going to see exploitation in the next thirty days. Call it the one-in-five line. Efficiency at 0.04 is 19.42% and passes through exactly 20.00% at 0.04158, so the line and 0.04 are the same decision, rounded. A coincidence I should own: 20% is also the number How EPSS Works picks to teach efficiency, 100 exploited out of 500 flagged. I didn’t spot that until the draft was finished.

Two of the three routes to 0.04 know nothing about each other. Efficiency gives 0.04158. FIRST’s own translation gives 0.04: for a programme treating CVSS Critical as its action threshold, the “Choosing a threshold” section of Using EPSS says “the EPSS equivalent effort level is approximately the 90th percentile (≥0.04, or a 4% probability of exploitation).” The third route is the capacity ladder at 0.0357, and its two inputs are numbers I chose, so it converges by less luck than it looks.

FIRST would not thank me for hardening that into a rule, and the EPSS FAQ says as much: “There is no universal threshold. The right threshold depends on your remediation capacity, risk tolerance, and asset context. A threshold of 0.10 (10%) is commonly cited in the field but carries no special authority from EPSS.” A programme could pick 0.10 and still be defensible, as long as it prints the capacity that justifies it. We publish a number anyway: without one a programme ships no decision.

A caution about reading this off a page, not a file. Using EPSS gives the mean as “around 2.8%”, the median “around 0.7%”, CVSS High and above as “approximately the top 48% of published vulnerabilities”. The 28 October file gives 2.639%, 0.629% and 43.57% — all drifted the same way, and I wouldn’t bet an SLA on any without recomputing.

And the boundary has a trap. The filter in FIRST’s REST API parameter table is named epss-gt, and the documentation says it will “Only display CVEs with EPSS score greater or equal than the parameter” — a flag called gt that behaves as gte. CVE-1999-0001 scores exactly 0.04753 here. Ask for epss-gt=0.04753 and it comes back; ask for epss-gt=0.04754 and it doesn’t. Two curls, and it decides who is in the sprint.

Why sorting by CVSS severity alone produces a queue nobody finishes

Because severity and exploitation are empirically uncorrelated, a severity sort buys coverage by volume rather than by aim. The EPSS FAQ is blunt: “High severity scores are slightly better than random at predicting exploitation activity.”

The size of the gap is in the 2023 arXiv paper behind EPSS v3 by Jacobs, Romanosky, Suciu, Edwards and Sarabi, nowhere near the first screen. The paragraph introducing Figure 5 in Section V-E, the last of five evaluation subsections with three more sections after it, costs out remediating everything at CVSS 7 and above:

Such a strategy yields a respectable coverage at 82.1% but at the cost of a higher level of effort, needing to remediate 58.1% or 110,000 of all published CVEs.

The same paragraph reaches 82% coverage with EPSS v3 at 0.088 and above, “needing to only remediate 7.3% or just under 14,000 vulnerabilities”. Divide 58.1 by 7.3: severity costs 7.96 times the work for the same result. Section V-B puts CVSS v3.x base score at a precision-recall AUC of 0.051 against EPSS v3’s 0.7795. Both are 2023 figures for a model two versions old: they measure the gap between methods, not today’s performance.

Age does more of the predictive work than anyone expects. The “Data Sources” section of How EPSS Works says “Age contributes more to individual predictions than any other single vulnerability characteristic”, and puts two-year-old vulnerabilities at “roughly five times the rate” of ones less than a month old. Read that as a tendency rather than a rule. Under Known limitations the same page says “there are absolutely vulnerabilities that come out of the gate swinging”, and calls the mechanism behind it “only speculative”. What age does explain is why a years-old bug like the one in a soft hyphen and a patched server outlives every severity queue it lands in.

A low score on an internet-facing asset is not a reason to defer

EPSS predicts exploitation somebody’s sensor will observe, not an attack aimed at you, so the score is silent on whether the box is reachable and what sits behind it. The “Known limitations” block at the foot of How EPSS Works says “A vulnerability widely deployed in your environment without compensating controls may score low.” The training labels carry the same caveat: “The model learns from a sample of actual exploitation, not a census of it.”

Three local checks close the gap, and FIRST names them presence, reachability and consequence. Under “Combining EPSS with other signals”, the intersection of all three with a high score “is where remediation effort produces the most risk reduction”. The inverse sits in the FAQ: a score warranting immediate action on an internet-facing box “may be appropriately deferred in a lower-risk one”.

The regulator left the probability out altogether. Table 1 in Appendix A of CISA Binding Operational Directive 26-04 sets remediation timelines from sixteen rows over four inputs — publicly exposed, in the KEV, automatable by adversary, technical impact. Row 1 (exposed, in the KEV, automatable, total control) is three days plus forensic triage. Row 8, exposed but not in the KEV and not automatable, with partial control, is 60 days. Exploitation probability appears nowhere in the table.

So here is the thing that costs us work. We don’t recommend an EPSS-only programme, and on an internet-facing asset holding regulated data I think CISA’s tree is the better instrument. A score at the published median of 0.00629 on a reachable box might still be the first thing somebody tries: the score describes the world’s sensors, not your exposure. Sort by EPSS inside a tier exposure has already defined; don’t let the score define the tiers.

Do not multiply EPSS by CVSS

The product is not probability times severity and it is not a risk score. The “Common misuses, misapplications, and misunderstandings” section at the foot of Using EPSS is unusually direct:

Do not multiply an EPSS score by an ordinal (such as CVSS) and think that produces a combined “risk score.” EPSS is a calibrated probability; CVSS scores are an ordinal ranking with no empirical calibration.

The FAQ puts it harder still: multiplying the two “does not compute probability × severity and is never a good idea”. Nearly every prioritisation spreadsheet I’ve seen does just that, in a column headed Risk.

One override survives, and it isn’t arithmetic. FIRST treats a CVE on the CISA KEV catalogue as actively exploited “regardless of EPSS score”, and the catalogue “lists roughly 0.5% of published CVEs”. At the same rate in a 400-item backlog, 400 x 0.005 = 2 findings. Those two go first.

Double the backlog or triple the fix time, and the threshold moves to 0.078 or 0.136

Capacity sets the threshold, so the line moves whenever either input moves, and a programme that pins its threshold while its capacity drifts is running a promise it never priced. Double the backlog to 800 and hold capacity at 42.7 findings a month: the affordable share halves to 42.7 / 800 = 5.34%, the score selecting 5.34% is roughly 0.078, and coverage falls from 71.65% to 61.33%. Twice the backlog didn’t buy twice the work. It moved the line.

Now derate the input I have the least confidence in. Ninety minutes a finding assumes no change window, no regression run and no vendor to chase. Multiply by three to 4.5 hours: capacity falls to 64 / 4.5 = 14.2 findings a month, 3.55% of 400, the threshold moves to 0.136 and coverage falls to 54.36%. The decision doesn’t flip. Ordering is what EPSS supplies; the cut point is what capacity supplies. What breaks is the promise: a 1% threshold needs 149.25 findings, and at 14.2 a month that is 10.5 months of work sorted on a thirty-day forecast.

And the thirty days from the first section is where this ends. A CVSS-High-equivalent queue — EPSS at or above 0.008, 174.3 of 400 — takes 174.3 / 42.7 = 4.08 months at the original capacity. A four-week month is 28 days, so 4.08 x 28 = 114 days. How EPSS Works says “EPSS recomputes features for every vulnerability in the corpus” every day, so by the time you reach the bottom the thirty-day window has turned over 114 / 30 = 3.8 times and every row has been re-scored about 114 times. Below roughly four months of queue we’d re-sort monthly and live with it; above that the sort is decoration and the fix is capacity or scope, not a cleverer threshold.

One version boundary before you backtest any of it. The “Historical data” section of Get the Data carries a warning: “each model version produced a score shift on the date it started publishing”, so a backtest spanning March 2025 measured two models and reported one. Picking the threshold and pricing the capacity is security and compliance work, the same date arithmetic as in the end-of-life cliff is a date.