Opinion / Commentary

Patch Tuesday Is Not a Patching Programme — It's Proof We've Accepted Defeat

Microsoft patched 167 vulnerabilities in a single Tuesday. We treated it as routine. That reaction — more than the vulnerabilities themselves — is what should concern every security leader.

James Calloway · Head of Vulnerability Management, Global Financial Services
4 min read

One hundred and sixty-seven. That is how many vulnerabilities Microsoft patched this Tuesday. Eight of them were Critical. Two were zero-days. One had been under active exploitation before anyone knew the patch existed.

I have been running vulnerability management programmes for eleven years. When I started, a 100-CVE Patch Tuesday was a big deal. People wrote blog posts. CISOs sent emails. There were emergency calls. Now 167 comes out, my team runs the query, we sort by CVSS, we prioritise the usual categories, and we move on. We’ve built systems specifically to absorb this volume without anyone having to panic.

That’s the problem. We’re very good at absorbing it.

We’ve Optimised for the Wrong Outcome

The security industry has spent a decade building better patch management tooling, better vulnerability prioritisation frameworks, better SLA tracking, better exception processes. We’ve made patching faster, more automated, more measurable. And we’ve applied all of that operational excellence to a problem we should have refused to solve.

The implicit agreement in every Patch Tuesday cycle is this: vendors will ship broken software at scale, and security teams will quietly absorb the cost of fixing it. The cost shows up in analyst hours, in patching SLAs, in change management risk windows, in emergency maintenance notifications, in the occasional breach that happens in the three days between the CVE drop and when your estate is fully patched. It never shows up on the vendor’s balance sheet.

When we built better patching programmes, we made that arrangement more sustainable. When we made it more sustainable, we removed any incentive to fix the underlying problem.

The 2009 CVE Is the Real Story

This week CISA added CVE-2009-0238 — a seventeen-year-old Microsoft Office vulnerability — to its Known Exploited Vulnerabilities catalogue. A 2009 CVE. On an active exploitation list. In 2026.

That is not a surprising data point. That is a data point that has been guaranteed to arrive by choices made a decade ago. Somewhere, in thousands of environments, there are machines running Office versions that have never received a patch cycle. Nobody knows they exist. They’re not in the asset inventory. They’re running a legal contract or a finance spreadsheet or a factory floor terminal, and someone plugged them into the network because it was convenient, and nobody ever unplugged them.

Our patching programme didn’t fail those machines. The patching programme was never designed to reach them. The asset inventory process failed them. The network segmentation process failed them. The “we’ll sort this out later” decision made in 2012 failed them. Patching is the last line of defence against a vulnerability — and last lines of defence fail at the frequency you’d expect from last lines of defence.

What “Secure by Design” Actually Means for Us

CISA and its international partners have been pushing secure-by-design principles for two years now. The framing is usually directed at software vendors — build memory-safe languages, eliminate entire vulnerability classes, stop shipping SQL injection in 2026. That framing is correct, but it lets the rest of us off too easily.

Secure by design also means: don’t build systems that require you to patch 167 vulnerabilities a month to remain secure. It means segmenting networks so that one unpatched endpoint cannot pivot to your domain controllers. It means designing applications that degrade gracefully when they fall behind on patches rather than catastrophically. It means having an asset inventory that actually reflects your estate.

The vendors need to ship better software. But we also need to stop designing environments where perfect patching coverage is the only thing standing between us and a breach.

A Challenge for Next Month

When the May Patch Tuesday drops, I’d like to suggest an experiment. Before you prioritise the CVEs, spend thirty minutes on a different question: how many of the April Critical CVEs did you actually remediate to 100% of affected assets? Not 98%. Not 99.7%. One hundred.

If the answer isn’t one hundred, the question isn’t “how do we patch faster?” The question is “what did we discover about our estate that we didn’t know before?” That answer — the shape of the gap — is more valuable than any individual CVE fix.

167 vulnerabilities this month. The number will be different next month. The question of what we do with that number will be exactly the same.