Microsoft’s Record September 2026 Patch Tuesday: What It Means for Your Small Business Windows Fleet

This post contains affiliate links. If you purchase through our links we may earn a small commission at no extra cost to you.

Microsoft’s September 2026 Patch Tuesday is the largest security release the company has ever shipped: 966 flaws fixed in the main release, 974 counting patches issued earlier in the month, 105 of them rated Critical, and two zero-days already being exploited in the wild. If you manage IT for a small business — even a fleet of a dozen laptops — this one is worth treating differently than a routine monthly patch cycle.

The scale, in numbers

The September release breaks down as 438 elevation-of-privilege flaws, 258 remote code execution bugs, 173 information-disclosure issues, 56 denial-of-service flaws, 19 security-feature bypasses, and 16 spoofing vulnerabilities. Of the 966, 105 are Critical severity, and 81 of those are remote code execution — the category attackers weaponize fastest. Microsoft has attributed the unusual scale in part to an AI-powered vulnerability discovery system finding issues at a pace manual review never could.

The two zero-days you can’t wait on

CVE-2026-81963 is a Windows Update Stack elevation-of-privilege flaw caused by improper link resolution before file access — an attacker who already has limited access to a machine can use it to gain full SYSTEM privileges. CVE-2026-85880 is a Windows ALPC heap-based buffer overflow, also leading to SYSTEM-level privilege escalation. Both are confirmed actively exploited, which is what separates them from the other 964 fixes: this pair should jump the queue on every machine you manage, patched-and-restarted before anything else on the list.

Why “just run Windows Update” isn’t the whole plan

For a business running a handful of machines with automatic updates on, this mostly resolves itself within a day or two. The risk sits with anyone running deferred update rings, machines that get skipped because they’re rarely rebooted (a back-office PC, a point-of-sale terminal, a server nobody wants to touch during business hours), or a fleet large enough that “did everything actually update” is a real question rather than an assumption. That’s exactly the gap RMM tooling exists to close — see our what is RMM guide and our Atera vs NinjaOne comparison if you’re patching more than a few machines by hand.

A staged rollout beats “patch everything today”

Even with two active zero-days, blasting a 966-fix update to every device simultaneously is how a monthly patch cycle turns into a helpdesk fire. The safer sequence: patch the two zero-day CVEs everywhere immediately, since those are the ones actually being exploited right now. Then stage the rest — a small pilot ring first (a few non-critical machines, ideally one of each hardware/software configuration you run), a 24-48 hour wait to catch any post-patch breakage, then broad deployment. Most RMM platforms support exactly this ring structure natively; if yours doesn’t, it’s worth asking why.

Back up before you patch, not after something breaks

A record-setting patch batch is also a record-setting chance for something to go sideways — a driver conflict, an application that doesn’t like a particular update, a machine that fails to boot cleanly afterward. Confirm your backup or system-restore point is current *before* the patch window, not as a reaction to a problem. See our small business backup solutions guide if that’s not already automated for every endpoint, not just servers.

Servers need their own pass, not the workstation ring

Don’t lump servers into the same patch ring as workstations. A server reboot mid-business-day has a different blast radius than a laptop reboot, and server patches deserve a scheduled maintenance window with a rollback plan, not an opportunistic overnight push. If you’re running anything on-prem — file servers, a domain controller, a hypervisor host — budget a deliberate, separately-scheduled patch pass for those.

Document what you did, not just that you did it

With a release this size, “we ran Windows Update” isn’t a satisfying answer if a client, an insurer, or an auditor asks what happened in September. A short record — which CVEs were prioritized, which ring patched when, what got tested — takes minutes to write and is worth having if this ever comes up. Our IT documentation and runbooks guide covers a lightweight way to keep this kind of record without turning it into its own project.

Watch for known-issue reports before you deploy broadly

With a release this large, some post-patch issues are close to inevitable — a driver conflict on a specific chipset, a compatibility problem with one line-of-business app, a printer that stops responding. Microsoft tracks known issues for each cumulative update on its release-health pages, and it’s worth a quick check there before pushing from pilot ring to full deployment, not just after a user reports something broken. A five-minute check can save an afternoon of helpdesk tickets if a known issue matches something in your environment.

Have a rollback plan, not just a backup

A current backup protects your data; it doesn’t get a machine back to a working state quickly on its own. Know your actual rollback path before you need it — Windows keeps the previous version available for a limited window after a cumulative update (uninstalling via Settings or WUSA), and a system restore point or full image backup covers the rest. Confirm this works on at least one test machine per hardware configuration before you’re relying on it during a real incident, not the first time something breaks in production.

This is a patching event, not a threat-hunting exercise

It’s worth being precise about what this article is and isn’t. Understanding *how* attackers exploit vulnerabilities like these, and building an ongoing patch-management program rather than reacting to one big release, is a deeper topic — our sister site covers that ground well in patch management for small business and vulnerability scanning for small business. This piece is narrower and more immediate: what actually happened this month, and how to get through it without breaking something in the process.

Recommended hardware and services

• 2TB external SSD backup drive — a fast, cheap way to confirm a local restore point exists before a big patch window
• KVM switch for the server rack — useful when a patch requires hands-on console access instead of a remote session
• 1500VA UPS battery backup — protects against a power blip mid-patch, which is one of the more common ways an update turns into a broken boot

Related SBITG topics

Patch and device management: what is RMM, Atera vs NinjaOne, MDM for small business. Backup: small business backup solutions, how to test a backup restore. Documentation: IT documentation and runbooks.

Key takeaways

• September 2026’s Patch Tuesday is Microsoft’s largest ever: 966 flaws fixed (974 total for the month), 105 Critical, 2 actively-exploited zero-days.
• The two zero-days (CVE-2026-81963, CVE-2026-85880) are both SYSTEM-privilege-escalation bugs — patch these everywhere first, immediately.
• Stage the rest of the update through a pilot ring before broad deployment; most RMM platforms support this natively.
• Confirm backups or restore points are current before the patch window, not after something breaks.
• Patch servers on their own scheduled window, separate from the workstation ring.

FAQ

Do I need to patch every device today? Prioritize the two actively-exploited zero-days everywhere immediately. The rest of the release can follow a normal staged rollout — pilot ring first, broad deployment after a short verification window.

Why did Microsoft ship so many fixes at once? Microsoft has attributed part of the unusual scale to an AI-powered vulnerability discovery system surfacing issues faster than manual review historically has — this is being described as the largest Patch Tuesday release on record.

I only manage a handful of machines with automatic updates on — do I need to do anything special? Probably not much beyond confirming updates actually applied and machines rebooted. The real risk is with deferred update rings, rarely-rebooted machines, and larger fleets where “did it actually apply everywhere” isn’t a safe assumption without checking.