What companies patch, and what they don’t

An introduction to vulnerability management, patching progress and exposure based on real world data 

Takeaways

• Companies prioritize fixing critical vulnerabilities.  That is usually where they are most exposed.
• The most vulnerable areas are weak or outdated encryption and other configuration flaws.
• Companies should focus on patching the most exploitable vulnerabilities and addressing legacy gaps.

Vulnerability scanners find far more issues than any team can fix. Whatever is still open in the scanner today is, by definition, what’s left after deciding what to fix first, what to live with, and what to monitor. By comparing what’s left to the full list of all published Common Vulnerabilities and Exposures (CVEs), we can work out what customers actually focus on.

The vulnerability management lifecycle

A vulnerability is a flaw in code, configuration, or a default setting that lets an attacker do something the designer didn’t intend. Vulnerabilities assigned a CVE identifier are primarily specific flaws in hardware or software. These are given a severity score using the Common Vulnerability Scoring System (CVSS) and tracked by every vulnerability scanner.

What follows is a four-step cycle. A scanner finds the issues. A risk model ranks them. A patch or configuration change clears them. A re-scan confirms the fix. The cycle repeats indefinitely, because new vulnerabilities arrive faster than old ones get fixed. The question is not whether to keep up, but which issues to fix first.

What gets patched: the prioritization gap

If customers patched without any priorities, tackling issues in random order, their backlog would match the severity breakdown of all CVEs. But it doesn’t. The chart below compares the unpatched backlog across anonymized and aggregated customer environments scanned by Barracuda’s Managed Vulnerability Security (red) against the severity mix of all published CVEs (grey).

Where the red bar is shorter than grey, customers patched aggressively. Critical-rated CVEs make up roughly a tenth of all published vulnerabilities, but only a small slice of what’s left unpatched, because Criticals get attention. Mediums also shrink, probably because they ride along with the monthly Windows update, which gets applied all at once. The High band swells in the other direction: it’s where customers fix most of the issues but not all of them, and the rest piles up.

What’s hard to patch

Three patterns explain most of the unpatched backlog.

1. Configuration outweighs code.  The most common finding across the customer base isn’t a software bug—it’s an untrusted (usually equivalent to self-signed) Transport Layer Security / Secure Sockets Layer (TLS/SSL) server certificate. The rest of the top ten is similar:

• Weak cipher suites
• Static‑key ciphers
• Self‑signed certificates
• Server Message Block (SMB) signing not required
• Transport Layer Security (TLS) 1.0 still enabled
• Susceptibility to the Browser Exploit Against Secure Sockets Layer / Transport Layer Security (BEAST) attack
• Default Simple Network Management Protocol (SNMP) community names

None of these require a vendor patch. They require configuration hygiene—someone to revisit long‑forgotten settings on long‑running services. That operator action is the real 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-biggest category.

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 National Vulnerability Database (NVD) (grey).

Most years, the red bar sits well below grey, meaning those CVEs were patched over time. The recent end (2024–2026) is the opposite: red towers over grey because those CVEs are too recent to have been patched. The interesting part is the small set of years where red matches or exceeds grey despite age: 1999, 2002, 2011, 2015, and 2016. Those are the survivors. A 1999 SNMP-defaults issue and the 2011 TLS BEAST flaw both still ride along on machines nobody has revisited. Configuration-hygiene CVEs stay around for years because nothing on the host actively prompts anyone to fix them.

What “good” looks like

A healthy vulnerability-management program is built on habits more than on tooling:

• Prioritize by exploitability, not by score alone. Use CVSS to bound severity, the Exploit Prediction Scoring System (EPSS) to estimate the chance of near-term exploitation, and the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV)  catalogue as the deciding signal. A CVE that ranks in all three is the most urgent fix. Everything else can wait.
• Treat configuration hygiene as an ongoing program, not a one-off project. The issues that stay open longest are default credentials, weak ciphers, and stale certificates — not vendor-patch gaps. They need their own scheduled review.
• Measure how fast you fix issues, not the total count. It rarely improves anyway, because new CVEs always arrive. What can improve is how fast you clear the issues that matter.
• 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. If they’re rare in a mature backlog, prioritization is working.
• The High band is where things accumulate. Volume, not severity, is what makes Highs the dominant category.
• Configuration is the overlooked half of the job. The oldest unpatched issues in real environments are almost never software bugs — they’re default settings nobody went back to fix.

Charts are based on an anonymized, aggregated snapshot of customer environments, compared to all published CVEs at the time of writing. Specific counts and customer identities are intentionally left out.