Most enterprise patch programs still run on a rule written a decade ago: criticals and highs inside 30 days, mediums inside 90, lows when someone gets around to it. The sort key for all of it is a CVSS base score. I think that rule is now actively harmful, and I'll go further: any patch-prioritization process that starts with severity instead of exploitation evidence is optimizing the wrong variable, and 2026 is the year the data made that undeniable.
CVSS answers one question: how bad would it be if this vulnerability were exploited? It says nothing about whether it will be. Those are different questions with wildly different answers, and the gap between them is where patch programs go to die. NVD's own documentation is blunt about this: CVSS is not a measure of risk. We took a technical severity metric and quietly promoted it into a scheduling algorithm. Nobody who publishes the standard ever asked us to do that.
The arithmetic stopped working
Start with volume. The CVE ecosystem published over 48,000 new CVEs in 2025, and the pace is still accelerating: NIST reports that submissions grew 263% between 2020 and 2025, with early-2026 volume running about a third higher again. Zafran's analysis of the 2025 numbers puts it at a record year even after you control for reclassification noise.
Now the killer stat. Across the entire history of the CVE program, only about 5% of published vulnerabilities are ever observed being exploited in the wild. That's not vendor marketing; it's the finding of the Cyentia Institute and FIRST's joint study of exploitation data, the people who run EPSS. Meanwhile, more than half of all scored CVEs land at CVSS 7.0 or above.
Put those together and the math is brutal. FIRST publishes a direct comparison of remediation strategies: a "patch everything CVSS 7+" policy forces you to remediate 57.4% of all scored CVEs to catch 82.2% of the ones that get exploited, and only about 4% of what you patched urgently ever sees exploitation activity. Ninety-six percent of your emergency effort is spent on vulnerabilities attackers never touch. An EPSS-driven threshold on the same data catches a comparable share of real exploitation for a fraction of the effort.
In an enterprise, that wasted effort isn't abstract. Change windows are the scarcest resource in operations. Anyone who has scheduled an FTD upgrade through an HA pair, or coordinated an ISE patch across a deployment that authenticates every switchport in the building, knows a maintenance window is a negotiated, finite, politically expensive thing. Spending one on a CVSS 9.1 that has no exploit, no proof of concept, and no exposure, while a "7.2 with active exploitation" waits its turn in the 30-day queue, is malpractice by spreadsheet.
2026 is the year the bill came due
If severity-sorted patching worked, we'd see it in breach data. We see the opposite.
The Verizon 2026 DBIR reported that exploitation of vulnerabilities is now the number one initial access vector in breaches, at 31% of initial access, up from 20% the year before. That's the first time in the report's 19-year history that exploitation has beaten credential abuse and phishing for the top spot. The same report's remediation numbers are worse: organizations took a median of 43 days to remediate known-exploited vulnerabilities, up from 32, and only 26% of KEVs were fully remediated at all, down from 38%.
Read that again. The industry is getting slower at patching the small set of vulnerabilities we know attackers are using, while drowning in a queue sorted by a number that doesn't predict attacker behavior.
The attacker side of the ledger is moving the other direction. VulnCheck's 2026 exploit intelligence reporting found that 28.96% of vulnerabilities known to be exploited in 2025 were exploited on or before the day their CVE was published, up from 23.6% in 2024. Google's Mandiant team measured average time-to-exploit going negative across vulnerabilities disclosed in 2024: on average, exploitation now begins before disclosure. Against that reality, a tiered SLA of "criticals in 30 days" isn't a control. It's a ritual.
Even the institution at the center of the scoring pipeline has conceded the point. In April 2026, NIST announced that the NVD will no longer attempt to enrich every CVE. It now prioritizes enrichment for CVEs in CISA's Known Exploited Vulnerabilities catalog (targeting one business day) and for critical federal software; everything else is marked lowest priority. The organization that assigns the scores triages its own workload by exploitation evidence. Your patch program should take the hint.
The steelman: what CVSS defenders get right
The strongest objection to evidence-based prioritization is that evidence is a lagging indicator. By the time a CVE lands in CISA's KEV catalog, someone has already been compromised with it, and if a third of exploitation starts at or before disclosure, waiting for confirmation means you're structurally late. That's true, and it's the best argument in the room.
But it cuts against CVSS too, and harder. A base score computed on day zero can't distinguish the 9.8 that will be mass-exploited within 48 hours from the 9.8 that will never be weaponized; both sit identically in your queue. Exploitation evidence at least converges on the truth as signals arrive: vendor advisories confirming in-the-wild activity, public proof-of-concept code, EPSS movement. EPSS v4, released in March 2025, exists precisely to close the lag problem, producing a daily-updated probability of exploitation for every published CVE before confirmation ever arrives. It's imperfect and probabilistic, and it still beats a static severity number at the only question that matters for scheduling: what happens next.
Two more objections deserve honest answers. First, compliance: plenty of audit frameworks and customer contracts are written in CVSS SLAs, and you can't unilaterally ignore them. Fine. Report in CVSS, prioritize by evidence; the two are not in conflict, because the evidence-driven queue will comfortably beat a severity SLA on the vulnerabilities auditors actually care about. Second, EPSS and KEV know nothing about your environment. Also true. No global score does, including CVSS. Exposure and asset criticality are your inputs, and they were always your job.
Where CVSS genuinely earns its keep is as an impact term. Once exploitation likelihood puts a vulnerability on the urgent list, severity helps decide whether the response is "next window" or "wake people up." That's a demotion from sort key to tie-breaker, and it's the right job for the metric.
What to run instead
Here's the structure I'd defend for a typical enterprise stack, the Cisco FTD/FMC/ISE, Windows Server, MECM, VMware world I work in:
Tier 0, out-of-band, days not weeks: anything on your stack that appears in the KEV catalog, in a vendor advisory confirming active exploitation, or that is internet-facing with a high EPSS score. This list is small by construction. The entire KEV catalog held 1,655 entries as of late July 2026, accumulated over five years, across every vendor on earth. Filtered to one organization's products, a KEV match is a rare, unambiguous, drop-everything signal. Federal agencies are already required to work this way under BOD 22-01; the due dates ship free with the catalog.
Tier 1, current cycle, pulled forward: elevated EPSS, or public PoC plus reachable exposure. Watch the trajectory, not the snapshot; a score jumping an order of magnitude overnight is telling you something.
Tier 2, the monthly wave: everything else rides your normal cadence. This is where the long tail gets handled, and it's why evidence-based prioritization isn't an excuse to stop routine patching. MECM doesn't care about your opinions on scoring; a healthy monthly baseline quietly remediates most of the 95% that never gets exploited, without ever consuming an emergency window.
Special case: edge devices. Firewalls, VPN concentrators, anything with a management plane near the internet. The last two DBIRs document attackers converging on exactly this class, and these are the boxes where "we'll patch next month" has repeatedly meant "we were exploited last week." If an edge product you run lands on KEV, that's a Tier 0 event with a same-week window, HA pair or not.
The tooling cost of all this is close to zero, which removes the last excuse. The KEV catalog is a public JSON feed; EPSS scores are a free daily CSV. I run a small script each morning that diffs the KEV feed against the product list I'm responsible for and flags anything new, and building it took less time than a single well-attended CAB meeting. You do not need a risk-based vulnerability management platform to start, although the good ones are essentially selling this exact join at scale.
Severity tells you how hard the punch would land. Evidence tells you a punch is coming. Only one of those should decide what your team does this weekend.
I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com
Adam Lewandowski is a network and security engineer (CompTIA Security+, CCNA, CCNP, VMware VCP-DCV) with several years of hands-on enterprise operations across Cisco FTD/FMC/ISE, Windows Server, MECM, and VMware. He builds automation that takes the repetitive judgment calls out of security operations — without taking the humans out of the loop. Find him on LinkedIn.
Top comments (0)