On September 8, 2026, Microsoft shipped the largest Patch Tuesday in its history: 964 vulnerabilities fixed in a single batch, 104 of them rated critical, according to Tenable’s count. Two were already being exploited in the wild before the fix shipped.
For an operation with a few hundred machines, rolling out everything over a weekend is a hassle, but doable. For whoever runs a few thousand endpoints, spread across sites and departments, on a network that doesn’t talk freely to the internet, patching everything at once stopped being a realistic plan.
The question left standing isn’t “are we patching”. It’s what goes first, in what order, and how you prove, later, that it actually landed on every machine it was supposed to.
A volume manual triage can’t keep up with
September wasn’t a one-off spike. Microsoft itself closed July 2026 with 570 fixes and August with 400, according to BleepingComputer, which tracks every monthly release. September’s batch more than doubled the average of the two prior months.
Of the 964 fixes, Tenable counted 104 critical ones — 81 remote code execution, 20 elevation of privilege, among other categories. And two flaws, CVE-2026-81963 and CVE-2026-85880, both elevation-of-privilege bugs in the Windows core, were already being used in attacks before the patch existed.
No team applies 964 fixes overnight, across thousands of machines, without breaking something along the way. The question stopped being whether to patch everything. It became deciding, with a method, what goes up first.
What decides the order of the queue
- Active exploitation: is someone already using the flaw, or is the risk still theoretical?
- Real exposure: does the machine talk to the internet, or sit behind a controlled segment?
- Asset criticality: is it an analyst’s workstation, or the server the operation runs on?
- Attack path: does the flaw need physical access to the machine, or just one remote click?
Fixing everything, at once, for everyone, stopped being a plan. It became a wish.
Without that method, a large fleet patches on a first-in, first-out basis — or whatever feels urgent that day. That’s how an already-exploited flaw, like the two from September, ends up waiting behind something harmless, just because its package landed first in the team’s queue.
That’s the kind of open window that, if an attacker gets in before the fix arrives, leaves the same question that comes up after a paid ransomware demand: what exactly happened, on each machine touched, while the flaw sat open?
On a segmented network, the queue outgrows the CVE list
Getting the method right solves half the problem. The other half is logistics: how the fix leaves the repository and reaches every workstation without stopping whoever is using it.
On a large corporate network, that means scheduling by group — one site at a time, one shift at a time —, throttling bandwidth so the rollout doesn’t compete with the system the business runs on, and expecting a fair number of connections to drop mid-transfer and need to resume where they left off, not start over.
That’s the operational reality behind on-premise fleet management: rollout has to fit inside the network you actually have, not the one a vendor assumes. What fit in one overnight window a year ago now takes days with today’s fleet.
And there’s a detail the CVE list alone doesn’t show: how many of those thousands of stations are actually compatible to receive the package without manual intervention first. Rolling out blind to that number just moves the delay from the schedule to the help desk.
The queue closed. Who proves it actually did?
Microsoft’s advisory closes the vendor’s obligation. It doesn’t close the obligation of whoever runs the fleet.
Internal audit, the insurer, and, in some sectors, the regulator, don’t ask whether September’s Patch Tuesday existed. They ask whether every machine on the list received the fix — and, if not, since when it’s been exposed.
Without a per-machine record, like the one the Tz0 Deploy update screen keeps, the answer turns into a guess. At today’s volume, “most of them should have updated” is no guarantee at all — it’s the definition of what’s still left to fix.
How Tz0 Deploy handles the fix queue
Tz0 Deploy organizes that queue in five steps: package the fix, define the target by group — department, site, machine type —, schedule the window, distribute, and check who installed it, with automatic rescheduling for whoever failed.
Installation runs silently, without interrupting whoever is using the machine. The window can be overnight, weekend, or immediate, with bandwidth throttling so it doesn’t compete with a critical system, and automatic resume when the connection drops mid-transfer — the usual scenario on a large, segmented network.
The same process covers desktops, laptops, and servers, on Windows, Linux, and Android, with a catalog of over 12,000 ready-to-distribute packages. The dashboard shows, per machine, what’s pending and what’s a security fix — the answer ready for when audit asks whether September’s queue actually closed.
The next queue is already on its way
September 2026 wasn’t an exception. It was the third straight month the fix count climbed, and nothing suggests October will reverse that.
The question isn’t whether the next Patch Tuesday is coming. It’s whether, when it does, your operation knows which machine already got what — or is guessing.
Request a Trauma Zer0 evaluation and see where your fleet’s fix queue actually stands today.