What customers patch — and what they don’t
An intro to vulnerability management, read backwards from the backlog. We look at what’s still unpatched across a few dozen customer environments and ask the inverted question: given what’s left, what did people prioritize?
Last updated: 15 May 2026 11:10 UTC
A vulnerability scanner finds far more issues than any team can fix. Whatever’s still open in the scanner report today is, by definition, the residue of choices already made — what to fix first, what to live with, what to monitor. By comparing that residue to the universe of all published CVEs, we can back into a picture of what customers actually prioritize.
The vulnerability management lifecycle
A vulnerability is a flaw — in code, in configuration, or in a default setting — that an attacker can use to do something the system’s designer did not intend. Each is assigned a CVE identifier, scored by severity, and tracked by every defensive scanner.
The discipline that follows is a four-stage cycle: discover (the scanner finds issues), assess (a risk model ranks them), remediate (a patch or configuration change clears them), verify (a re-scan confirms the fix). The cycle repeats indefinitely — new vulnerabilities ship faster than old ones get closed. The question is not whether to keep up, but which issues to chase first.
What gets patched: the prioritization gap
If customers patched without prioritizing — tackling issues in whatever order they happened to appear — their backlog would mirror the severity mix of CVEs at large. It doesn’t. The chart below compares what’s currently unpatched across a few dozen environments (red) to the severity mix of every CVE ever published (grey).
What’s hard to patch
Three patterns explain most of the residue.
1. Configuration outweighs code. The single most prevalent finding in the customer base isn’t a software bug at all — it’s an untrusted TLS/SSL server certificate. The rest of the top ten reads similarly: weak cipher suites, static-key ciphers, self-signed certificates, SMB signing not required, TLS 1.0 still enabled, the BEAST attack still possible, default SNMP community names. None of these require a vendor patch. They require an operator to revisit long-forgotten settings on long-deployed services, and that operator action is the actual bottleneck.
2. Operating system vs applications. Microsoft-tagged issues (Windows OS patches, Office, Edge) dominate the customer footprint — reflecting both endpoint counts and the volume of Microsoft’s monthly release cadence. Linux is essentially absent from the backlog, which has two equally honest explanations: many Linux servers auto-update via the package manager, and the customer base is simply Windows-heavy. Browser apps (Chrome, Edge) and the occasional Adobe Acrobat / Java install are the next-most-visible layer.
3. Old CVEs age out — with exceptions. The second chart traces every unpatched CVE by the year it was first published, as a share of the backlog (red) versus its share of the whole NVD universe (grey).
What “good” looks like
A healthy vulnerability-management programme is built on habits more than on tooling:
- Triage by exploitability, not by score alone. Use CVSS to bound severity, EPSS to estimate the probability of near-term exploitation, and the CISA KEV catalogue as the override signal. A CVE that ranks in all three is the most urgent fix; everything else is a queue.
- Treat configuration hygiene as a programme, not a project. The longest-lived items in any backlog are default credentials, weak ciphers, and stale certificates — not vendor-patch gaps. They need their own scheduled review.
- Measure remediation rate, not raw count. Total count rarely improves — new CVEs always arrive. What can improve is the rate at which the issues that matter get cleared.
- Outsource what can’t be staffed for. Managed Detection and Response (MDR) providers monitor scanner output continuously and correlate it with live attacker activity — a feedback loop most in-house teams can’t sustain alongside their day job.
Three things to remember
- Critical CVEs do get patched. Their under-representation in any mature backlog is the clearest signal that prioritization is working.
- The High band is where things accumulate. Sheer volume — not severity — is what makes Highs the dominant backlog category.
- Configuration is the unsung half of the job. The oldest unpatched issues in real environments are almost never code bugs; they are defaults nobody revisited.
Charts derived from an aggregated snapshot of a few dozen customer environments, compared to the NVD universe at the time of writing. Counts and customer identities are deliberately not disclosed.