KEV Catalog Coverage Gaps and Blind Spots

The Known Exploited Vulnerabilities catalog, run by CISA since November 2021 under Binding Operational Directive 22-01, tells federal civilian agencies which vulnerabilities are being actively used in attacks and sets a deadline to fix them. KEV works precisely because it refuses to list everything. That refusal is also why the catalog cannot show the full exploitation picture, and any organization that treats it as complete has built a blind spot into its own defense.

What excludes vulnerabilities from KEV: the three selectivity gates

Every entry on KEV has to clear three separate filters before CISA will list it. Each filter throws out a different slice of real-world risk, and the three compound each other in ways that make the total exclusion bigger than any single gate would suggest.

The first gate is a CVE ID. No CVE, no entry, no matter how bad the bug is or how many attackers are already using it. That excludes zero-days under active exploitation before NVD assigns them a number, end-of-life systems that never got CVEs, and entire classes of vulnerability that were never built to fit into the CVE system.

The second gate demands a patch or a documented mitigation, and this is the one that excludes the category that arguably matters most: vulnerabilities under active exploitation for which no fix exists yet. During that window, KEV goes silent, and defenders are left with compensating controls and little else. This gate is a choice CISA made about what "known exploited" has to mean. VulnCheck runs its own exploitation catalog with no patch-availability requirement at all, proof that the CISA design is a policy call, not an inevitability.

The third gate is federal relevance, the fourth criterion under BOD 22-01. A vulnerability can be actively exploited and heavily weaponized against consumer software, gaming platforms, or other non-federal technology and still never touch KEV, because the directive exists to protect federal civilian networks, not to catalog exploitation everywhere it happens. That gate creates blind spots wherever exploitation concentrates outside federal civilian infrastructure.

The gates stack. A novel zero-day, unpatched, with narrow federal relevance, can sit under mass exploitation in the wild and fail all three tests simultaneously. That combination is real enough to plan around.

How large the coverage gap is between KEV and observed exploitation

The numbers make the gap concrete, and they are moving the wrong way. In 2025, CISA added 245 CVEs to KEV. VulnCheck identified 883 newly exploited CVEs that same year. The catalog captured fewer than one in three CVEs known to be under active exploitation. In 2024 the comparable figures were 185 on KEV against 717 identified by VulnCheck, so both the raw shortfall and the ratio have gotten worse year over year, not better.

Smaller-scale telemetry tells the same story at a different resolution. Proofpoint identified 12 distinct CVEs in 2026 under active exploitation in network-facing attacks, and only 8 of those had a KEV entry at the time. Four CVEs, real exploitation, no formal listing. VulnCheck and other researchers keep turning up exploited CVEs missing from KEV entirely, some lagging by months, some by years. The catalog is accurate about what it lists. It stays incomplete about what it leaves out, and the omission keeps growing rather than closing.

Why the timing problem is as damaging as the coverage gap

Coverage is half the issue. Speed does the other half of the damage, and arguably the worse half, because a late warning still fails the organization at the moment it needed the information most.

VulnCheck data shows that in roughly two out of three cases, its own catalog flagged a CVE as known-exploited before CISA added it to KEV. Mean lead time across all CVEs was 28.13 days; narrowed to just the cases where VulnCheck moved first, the average lead widened to 41.64 days. That's over a month, on average, of a vulnerability already in use against real targets while the federal catalog hadn't caught up yet.

Some entries never had a chance to be timely. Among KEVs added in 2025, 28.96% were already being exploited on or before the day their CVE was publicly disclosed, up from 23.6% the year before. In those cases there was no window in which CISA's confirmation process could have gotten ahead of attackers, since exploitation and disclosure landed at roughly the same moment. Separately, 28.3% of exploited vulnerabilities overall were weaponized within 24 hours of disclosure. KEV requires confirmed exploitation and an available patch before it lists anything, so by its own rules it cannot flag these cases during the exact window defenders need the warning most.

Zero-days sharpen the point further. Google's Threat Intelligence Group counted 90 zero-days exploited in the wild in 2025, with enterprise technology reaching an all-time high share at 48% of that total. None of those had a patch at the moment of exploitation, which disqualifies every one of them from KEV until well after the first attack waves have already run their course.

The older-vulnerability paradox: attackers favor what KEV already knows about

Attackers are not, for the most part, racing to weaponize the newest vulnerabilities. VulnCheck's KEV data shows that 81% of CVEs first exploited in 2025 were disclosed before 2025 even started. Attackers go back to older ground instead, often vulnerabilities already sitting on KEV, that remain unpatched somewhere in a target's environment. The catalog's biggest blind spot isn't what it's missing, it's what security teams do with what it already caught.

Treating "what did KEV just add" as the urgent signal misses where the chronic risk actually sits, in entries CISA listed months or years ago that never got remediated. CISA's own additions show how far back this reaches. Early in 2026, the agency added a Microsoft Office PowerPoint vulnerability from 2009 to KEV, confirming successful attack payloads built around a flaw now well over a decade old.

Vulnerability exploitation is now reported as the number-one initial-access vector in breaches, at 31%. That exposure comes from the entire catalog backlog stretching back years, still sitting unpatched in production, rather than from this year's fresh CVEs.

OT and ICS environments where KEV signal is thinnest

Operational technology and industrial control systems sit where KEV's visibility runs thinnest, and the stakes run higher here because these are the systems that run physical infrastructure, not just data.

Many vulnerabilities affecting critical OT and ICS devices fall outside standard tracking frameworks, leaving asset owners and network administrators with no clear signal of what's actually exposed. Of published ICS advisories, 75% carry a high or critical severity rating, and in 2025 that figure climbed to 82%. That's a large, growing population of dangerous vulnerabilities sitting mostly outside KEV's field of view.

Some of what gets missed doesn't fit anywhere near KEV's data model. OT and ICS security firms like Dragos have documented deep control-plane compromises that never registered as an endpoint infection in mainstream EDR telemetry; this attack pattern falls outside KEV's evidentiary framework by design. The CVE gate compounds the problem, since a lot of ICS gear runs on proprietary protocols and vendor-specific firmware that never generates a CVE record, even when the vulnerability is well understood inside the vendor's own engineering team.

How KEV's data substrate, CVE records and NVD enrichment, propagates its own gaps

KEV sits on top of the CVE and NVD ecosystem, so whatever gaps exist in that underlying data pass straight through into KEV. Call it structural inheritance rather than an occasional glitch, because the flaw sits one layer below the catalog itself and appears in every entry built on top of it.

Programs that lean on a database's product-matching scheme alone are blind to a large share of the vulnerability population. VulnCheck's analysis of 2024 CVE data found NVD CPE coverage is just 41%, meaning well over half of CVEs lack the structured matching data automated tools need just to connect a CVE to the software it affects.

Enrichment lag makes the problem worse. In the first half of 2025, 26.9% of newly added KEVs were still awaiting analysis by NIST, so the CVSS scores and prioritization data defenders normally rely on simply weren't there yet for over a quarter of new entries. CISA's own August 2026 Vulnerability Review, covering FY2024 and FY2025, flags persistent gaps in the CVE records themselves: missing CVSS fields, absent CWE weakness-type attribution, incomplete descriptions. CISA's own language on the effect: these gaps "slow triage, undermine security automation workflows, and increase risk across the ecosystem."

The trend runs toward more sparseness, not less. NIST formally moved NVD to a triage model on April 15, 2026, committing to fully enrich only an estimated 15% to 20% of incoming CVEs going forward. The foundation KEV rests on is thinning by design, and the gaps described here aren't a temporary backlog to be cleared later. They are becoming the structure itself.

The severity heterogeneity inside KEV that flat prioritization ignores

Treating every KEV entry as equally urgent is a mistake distinct from the coverage and timing gaps already covered. The catalog isn't uniform, and flattening it into one priority tier throws away signal that's already sitting there for the taking.

As of January 14, 2026, the catalog held 1,488 entries. Under CVSS filtering, an analysis run using the KEVology framework found only 483 of those, 32%, applicable to immediate initial access. The rest, over a thousand entries, represent post-exploitation activity: lateral movement, privilege escalation, persistence mechanisms. Those matter, but not in the same way or at the same moment as an initial-access flaw sitting on an internet-facing service, and treating both categories identically wastes response effort exactly where it counts least.

EPSS, a model that scores likelihood of exploitation, adds a second layer of disagreement. 135 KEV entries are listed as confirmed exploited while their EPSS score sits below 0.01, so the probabilistic model assigns them only a small chance of exploitation in the next 30 days despite the exploitation having already happened. A defender leaning on EPSS alone to triage would deprioritize exactly the entries the empirical record says matter most. Across the catalog, EPSS scores vary widely, with some entries scoring very low in predicted probability while others reflect commodity exploit code already in wide use. Flat treatment of KEV wastes effort on the first cluster and produces alert fatigue everywhere else.

CISA's own Vulnerability Review adds a third distinction: some CWE classes carry more exploitation risk than others, even within a catalog already filtered down to confirmed exploitation.

Three organizational failure modes that create blind spots even when KEV is correct

Even when every KEV entry is accurate and timely, organizations still miss the findings that matter to them, and the reasons have nothing to do with CISA's process.

Inventory blindness comes first, and it's the most basic. A KEV program is only as good as an organization's own record of what software is actually deployed. Incomplete SBOMs (software bills of materials), stale configuration management databases, and unmanaged shadow IT all mean KEV can flag a vulnerability correctly and the organization still misses it, simply because nobody knew the affected component existed in the environment.

Transitive dependency blindness comes second. Plenty of KEV entries affect popular libraries buried deep inside software dependency trees rather than sitting at the top level where they're easy to spot, and software composition analysis tools that only check a few levels of depth miss them. The xz-utils incident is the case everyone points to: CVE-2024-3094 itself was never added to the CISA KEV catalog, yet the underlying pattern, critical exposure hiding several layers deep in a dependency tree, keeps recurring regardless of whether any single instance ever earns a KEV entry.

Supplier neglect comes third, and it's the one most programs underrate. Most KEV findings involve third-party commercial or open source software an organization consumes rather than builds, so vulnerability programs built around internally developed applications end up missing the largest share of their actual KEV-relevant exposure. The code an organization wrote itself accounts for a smaller share of that exposure than the commercial and open source components it merely runs. Network appliances accounted for 35% of all new KEV entries in 2025, a category frequently managed outside traditional vulnerability programs entirely, and that pattern makes supplier neglect one of the most consistent blind spots on this list.