EPSS was built to answer one narrow question: given everything FIRST’s model knows about a CVE today, what is the probability that it will be exploited in the wild in the next 30 days. That is a useful, well scoped question, and the model answers it better than CVSS ever could for triage ordering. But “everything the model knows” is the operative phrase, and the training signal behind EPSS has structural gaps that do not show up in the score itself. A team that routes patch priority through EPSS alone will eventually get burned by one of these gaps, usually the ones nobody warned them about before the incident review.
What EPSS Actually Scores
EPSS is a supervised model trained primarily on evidence of exploitation activity harvested from internet telemetry: honeypots, IDS and IPS signature hits, scanning services such as GreyNoise and Shodan, and vulnerability intelligence feeds that aggregate exploit code availability, CVE metadata such as CWE category, vendor, age and reference counts, and social chatter. The output is a probability, refreshed daily, that ranks CVEs against each other far better than a raw CVSS base score does. That ranking quality is real and worth using. The problem is what the training data structurally cannot see, and that blind spot maps closely onto the highest consequence attacks in most environments.
Telemetry Bias: EPSS Sees Scanners, Not Intruders
Most of the exploitation signal feeding EPSS comes from internet-facing sensors that log automated scanning and opportunistic exploitation: mass botnets probing for known RCEs, credential stuffing bots, cryptominer droppers. That traffic is real and worth defending against, but it is a specific slice of the threat landscape, noisy, broad, and financially motivated. A targeted intrusion against a specific organization looks nothing like that traffic. An operator who already has a foothold and is exploiting a local privilege escalation bug to move from a low privilege shell to SYSTEM does not generate an internet-facing signature. EPSS was never built to see that activity, so a CVE used almost exclusively in post-compromise operations will carry a persistently low score even when it is the exact bug ransomware crews chain after initial access.
The Internal-Asset Gap
This bias compounds for anything that is not reachable from the internet by design: internal file shares, domain controllers, ICS and OT protocols, internal APIs sitting behind a VPN. EPSS has almost no way to observe exploitation of a vulnerability that only matters once an attacker is already inside the perimeter, because there is no internet sensor sitting on that segment. Active Directory CVEs, SMB relay bugs, and internal RPC vulnerabilities routinely score low on EPSS for years, right up until they show up as step three or four in a published attack chain. If a scoring pipeline treats EPSS as the gate for patch prioritization, internal-only assets will systematically lose the queue to internet-facing noise, which is backwards from an attacker’s actual path once they are past the edge. This is exactly why exposure context has to sit next to the exploitation-probability score rather than behind it: a CVE on an asset your attack surface management data confirms is internet reachable is a different risk conversation than the same CVE on an air-gapped segment, regardless of what EPSS says.
Cold Start: Brand New CVEs Have Almost No Features
EPSS rescoring runs daily, but a CVE published this morning has almost none of the signal the model relies on: no observed exploitation yet, a thin or empty reference list, no exploit-kit inclusion, sometimes not even a finalized CVSS vector from NVD. The model has to fall back on coarse features like CWE category and vendor, which produces a score close to the population baseline rather than a meaningful estimate for that specific flaw, and that baseline sits low. So for the first days to weeks after disclosure, exactly the window where a proof of concept is most likely to appear and mass exploitation is most likely to spike, EPSS is the least informative it will ever be for that CVE. Treating a two day old critical CVE as low priority because its EPSS score has not caught up yet is one of the most common ways teams get caught by a fast moving exploitation wave.
Targeted and APT-Grade Exploitation Generates No Noise
Nation-state and other well resourced operators exploit deliberately, against a small number of targets, often with custom tooling and without the mass-scanning behavior that feeds EPSS telemetry. A zero-day used against a handful of high value targets, or an n-day exploited quietly by a small access broker before it is weaponized broadly, will not move an EPSS score, because the model has nothing to observe. Log4Shell is the exception that proves the rule: it became a headline case specifically because it triggered mass internet scanning almost immediately, which is the one condition EPSS is built to detect well. Most targeted exploitation looks nothing like Log4Shell, and EPSS has no lever to pull for it.
Low-EPSS CVEs That Landed in KEV Anyway
CISA adds a CVE to the Known Exploited Vulnerabilities catalog on the basis of confirmed, in the wild exploitation reported by an agency, vendor, or incident responder, independent of what EPSS says at the time. Looking back through KEV additions and checking what their EPSS score looked like on the day CISA added them, a recurring pattern shows up: the vulnerabilities that surprise a scoring pipeline the most are the internal pivot bugs, the low and slow targeted exploits, and the recently disclosed CVEs still sitting in the cold start window described above. These are not random misses, they are the same three blind spots this article has walked through, converging on the same set of CVEs. That convergence is the practical argument for never treating EPSS as a standalone gate: KEV membership and EPSS measure different things, confirmed exploitation versus predicted probability, and they diverge in predictable, explainable directions rather than randomly. Systems that ingest both feeds automatically, SITEY among them, can flag that divergence, a CVE newly added to KEV while its EPSS score is still low, the moment the KEV update lands, instead of leaving an analyst to notice the mismatch during a manual spreadsheet cross-reference weeks later.
Compensating for the Blind Spots
None of this means EPSS is a bad model, it means it is one input, not a verdict. A workable scoring pipeline treats EPSS as one axis among at least three.
- Exposure. Is the affected asset internet reachable, VPN-only, or fully internal, and how many hops separate it from something that is internet reachable. This is exactly the context an attack surface management view exists to supply, since it tells you which internal CVEs deserve the urgency EPSS structurally cannot assign them.
- Asset value and blast radius. A domain controller, a CI or CD credential store, or a database holding regulated data changes the calculus regardless of EPSS, which is why criticality tagging inside your asset inventory needs to feed the same prioritization step rather than living in a separate spreadsheet.
- KEV membership as an override. Any CVE on the KEV list gets treated as confirmed exploited regardless of its EPSS number, full stop, because KEV is ground truth and EPSS is a forecast.
A practical threshold set that holds up in most environments: patch anything in KEV immediately regardless of EPSS; treat an EPSS score above roughly 0.1 combined with internet exposure as next cycle priority; and for anything published in the last fourteen days with a CVSS base score at or above 7, do not wait for EPSS to catch up, score it on exposure and asset criticality alone until the model has accumulated enough signal to be useful. Platforms that automate this triage step, such as SITEY, pull EPSS and KEV feeds alongside live exposure data from the scan itself so a CVE’s score is never evaluated in isolation from whether the affected asset is actually reachable and how much it is worth to the business. The same logic applies downstream: once a fix ships, the only way to know a supposedly closed finding will not resurface in next month’s scan is to track it through its full lifecycle rather than closing the ticket the moment a patch command returns exit code zero.
The deeper lesson is architectural rather than statistical: no single score, EPSS included, was designed to answer whether you should patch something right now. EPSS answers how likely broad exploitation is, CVSS answers how bad it is if it fires, and KEV answers whether it has already been used. Prioritization has to combine all three with exposure and asset context, and a pipeline that skips that combination in favor of one convenient number will keep getting the internal, targeted, and freshly disclosed cases wrong in the same predictable pattern described above. Teams building this into an automated triage stage generally get better mileage from treating EPSS as a re-ranking signal applied after exposure and asset value have already narrowed the queue, rather than as the first filter that decides what gets looked at at all.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.