The patch window problem: why known vulnerabilities are still the way in

There is a persistent mental image of how organizations get compromised: a sophisticated adversary, a previously unknown flaw, an attack nobody could reasonably have prevented. It happens. It is not what happens to most organizations most of the time.

What usually happens is that a vulnerability was disclosed, a patch was published, several months passed, and the patch was not applied to one system that was reachable from the internet. The exploit used was public. The scanning that found the system was indiscriminate. Nobody targeted the organization; the organization was simply in the set of things that were still vulnerable when the sweep ran.

This is, in one sense, good news. It means the problem is tractable with operational discipline rather than exotic tooling. In another sense it is worse news, because operational discipline is genuinely hard to sustain and cannot be bought as a product.

Why the patch did not get applied

Nobody decides not to patch. Patches go unapplied for reasons that are individually reasonable and collectively fatal.

• The system was not in the inventory. You cannot patch what you do not know you own. This is the largest single cause we encounter, and it is almost always the same handful of systems: a device installed by a vendor, a virtual machine spun up for a project that ended, a service someone stood up during an incident three years ago.
• Patching required downtime nobody would authorise. The system is business-critical, the maintenance window is contested, and the request gets deferred each month until it stops being requested.
• The patch broke something once. An organization that had a bad patch experience in 2019 is often still running a manual, cautious, slow process designed around that memory.
• Ownership was ambiguous. The application team believes the infrastructure team patches the OS. The infrastructure team believes the application team owns the whole stack. Both are partly right, and the middle layer goes untouched.
• The vendor does not permit it. Appliances, medical devices, industrial control systems and anything with a support contract that voids on modification. This one is real and needs compensating controls rather than willpower.

Prioritising when you cannot patch everything

The naive approach is to sort by CVSS score and work down. This performs badly, because CVSS measures theoretical severity in isolation and says nothing about whether anyone is actually exploiting the flaw, or whether the affected system is exposed in your environment.

A better ordering combines three things.

Is it being exploited in the wild. CISA's Known Exploited Vulnerabilities catalog is the authoritative free source and should be the top of every queue. A medium-severity flaw with active exploitation outranks a critical-severity flaw with no known exploit, every time.

Is it reachable. An internet-facing system with no compensating controls is categorically different from the same software on an internal segment behind authentication. Reachability is the multiplier on everything else.

What does it get them. A flaw that yields remote code execution on a system holding regulated data is a different problem from one that yields a denial of service on a print server.

The edge is where this actually matters

If you take one operational change from this article, make it this. Internet-facing infrastructure — VPN concentrators, firewalls, remote access gateways, file transfer appliances, anything that terminates a connection from the public internet — belongs in a different patching category from everything else.

The reason is arithmetic. These devices are enumerable from outside your network, they are used by a large number of organizations, so a single flaw yields a large target set, and they sit at the trust boundary, so compromising one usually yields authenticated access to the interior. The last several years have produced a steady sequence of exactly this pattern across multiple vendors' edge products.

Treat them as an emergency change category with pre-authorised windows. The maintenance window argument does not apply, because the alternative to a fifteen-minute planned outage is an unplanned outage of indeterminate length with a forensics engagement attached.

Inventory is the prerequisite

Everything above assumes you know what you have. Most organizations do not, and are surprised by the gap when they measure it.

Automated discovery beats a spreadsheet, because a spreadsheet is accurate on the day it is written. Agent-based inventory covers managed endpoints; network discovery covers the things without agents, which is precisely where the forgotten systems live. Reconciling the two is where the interesting findings are — anything that appears in network discovery but has no agent is, by definition, unmanaged.

For external exposure, the check is simpler than people expect. Enumerate what your public IP ranges and domains actually expose, from outside, on a schedule. Every organization we have run this for has found at least one service they did not know was listening. Usually it is a management interface, and usually it has been there for years.

Making it sustainable

The failure mode of patching programmes is not that they are never started. It is that they are started as a project, run well for a quarter, and then decay as attention moves on. Sustaining one requires that it be boring, automated, and measured.

Automate the routine tier completely. Workstation and standard server patching should require no human decision in the normal case. Reserve human judgement for the exceptions, because human attention is the scarce resource and spending it on routine approvals guarantees there is none left for the genuinely difficult cases.

Measure one number and report it monthly: the age of your oldest unremediated known-exploited vulnerability. Not a percentage of compliance, which can look excellent while a single catastrophic gap persists. The oldest one. It is a single figure, it is unambiguous, and it goes up on its own if nobody does anything — which is exactly the property you want from a metric.

The organizations that do this well are not more sophisticated than the ones that do not. They have simply decided that patching is a permanent operational function with a named owner and a reported number, rather than a task that competes for attention with whatever is more urgent this week. It is not glamorous work. It is most of the defense.