Microsoft Just Patched a Record 622 Flaws. Here's the Routine Every Small Business Needs

In July 2026, Microsoft shipped the largest security update in its history: 622 fixes in a single release, more than triple the roughly 200 patched the month before. Buried in that batch were two flaws attackers were already using before Microsoft had a fix ready, one in SharePoint Server that let an outsider take over a system without even logging in, another in Active Directory Federation Services that let an attacker already inside jump straight to administrator. A third bug, in BitLocker, had been publicly disclosed before the patch existed at all.

Most small businesses read a headline like that, feel a flicker of concern, and move on, because 622 is an abstract number and none of it sounds like something a 20-person company needs to act on personally. That reaction is the actual problem. The record month is a symptom. The real risk lives in the ordinary months, the ones where twelve or twenty patches arrive quietly and nobody in the business owns the job of getting them installed.

Why the size of the update matters less than the response time

A "zero-day" simply means attackers found the hole before the vendor did, so there was no patch to install even for someone doing everything right. Those get the headlines. But most breaches do not come from zero-days. Verizon's 2026 Data Breach Investigations Report found that exploiting a known vulnerability, one a patch already existed for, overtook stolen passwords as the single most common way attackers get in, now involved in roughly 31% of breaches. The patch existed. Somebody just had not applied it yet.

That gap matters because attackers move fast once a fix ships. A patch is a public admission of exactly what was broken, and reverse-engineering it to build a working exploit now regularly takes under a week. A business that installs a critical patch within days closes the window before most attackers get there. A business that installs it whenever someone gets around to it, a month later, during the next scheduled maintenance, leaves that window open for exactly the attackers who read Microsoft's advisory and went looking for anyone who had not.

Why patches stall in small businesses specifically

It is rarely a technology problem. It is an ownership problem. Windows Update runs on a laptop and prompts for a restart; the owner or an employee clicks "remind me later" because they are in the middle of something, and three weeks pass. A server update requires a maintenance window nobody scheduled because nobody was assigned to schedule it. A line-of-business application still runs on an old framework version, so the IT person, if there is one, is afraid an update will break it, and delays indefinitely rather than test it properly.

Third-party software makes it worse. Windows and Office updates get some attention because Microsoft nags about them. Chrome, Adobe Reader, a accounting package, a CRM plugin, the router firmware, these rarely get touched at all once installed. Sophos' State of Ransomware 2025 report found unpatched software was the technical root cause behind 32% of ransomware infections, and in most of those cases the software in question was not the operating system.

A managed IT operations service exists specifically to close that gap: someone whose job includes tracking every patch across every system, not just the ones Microsoft happens to prompt about.

What a working patch routine actually looks like

It does not require a big budget or a full-time hire. It requires four things written down and assigned to a specific person, rather than left as a shared assumption that someone is handling it.

First, one person or provider owns patch status across every device and server, not just the ones that happen to prompt for updates on their own. Second, patches get staged: a small test group installs first, the rest follow within a defined window once nothing has broken. Third, that window has real deadlines attached to severity, not "eventually." Fourth, a current backup exists before any major update goes out company-wide, so a bad patch is a rollback, not a crisis.

None of this needs to be complicated. It needs to exist somewhere other than in one person's memory, and it needs someone accountable for checking it actually happened.

What to do about the systems you cannot patch fast enough

Some updates genuinely cannot go out the same day. A critical line-of-business application might need real testing before a Windows update touches the server it runs on, and testing takes longer than the 72 hours a zero-day deserves. That is a legitimate constraint, not an excuse to skip patching altogether, but it does mean the business is carrying risk for longer than it would like.

Two things reduce that exposure while the patch is pending. A Microsoft 365 security assessment checks whether compensating controls, conditional access, multi-factor authentication, restricted admin access, are already in place, so an unpatched system is not also an undefended one. And a tested, working backup and recovery plan means that if the worst happens before the patch lands, the business loses hours, not the business itself.

Neither of those replaces patching. They are the difference between a delayed patch being an accepted, managed risk and being an unmanaged one nobody noticed until it was too late.

What Microsoft patches for you, and what is still your job

This is where a lot of confusion comes from. If your business runs on Microsoft 365 and standard Azure services, Microsoft patches the underlying platform itself, the servers running Exchange Online, the infrastructure behind Teams, the SharePoint Online service. You never touch that layer and you never have to. That is a genuine benefit of moving to cloud services in the first place, and it is real.

But almost no small business runs on cloud services alone. The July 2026 SharePoint flaw that got exploited before a patch existed was in SharePoint Server, the version installed on a company's own hardware, not SharePoint Online. The AD FS flaw hit Active Directory Federation Services, a piece of infrastructure companies run on-premises to connect their own identity systems to cloud logins. Plenty of small businesses still have one or both, often installed years ago by a provider who has since moved on, quietly running in a server room nobody thinks about until something goes wrong with it.

Even where everything is genuinely cloud-based, patching is not fully off your plate. Every laptop, phone, and desktop your staff use still needs its operating system patched, its browser patched, and whatever line-of-business software it runs kept current. Microsoft cannot patch a device it does not manage. That responsibility, and the September, October, and November batches of ordinary, unremarkable updates that follow a record month like July, sits with whoever is responsible for your endpoints. If nobody has been named for that job, nobody is doing it.

Common questions

Do we need to worry about this if we only use cloud services like Microsoft 365?

Less than a business running its own servers, but not zero. Microsoft patches the cloud platform itself. Your laptops, phones, browsers, and any locally installed software are still your responsibility, or your provider's, and those are exactly what the Sophos ransomware research above points to as the usual entry point.

How quickly should a small business actually install a critical security patch?

Within days for anything actively being exploited, ideally within 24 to 72 hours once compensating protections like multi-factor authentication and conditional access are confirmed to be working. For patches rated critical but not yet seen in active attacks, a week is a reasonable outer limit, not a month.

A short checklist for this month

• Name one person, internal or external, who owns patch status across every device, server, and third-party application.
• Confirm when the last Windows, Office, and browser updates were actually installed, not just approved.
• Check that a working backup exists from within the last 24 hours before any company-wide update goes out.
• Set a real deadline for critical and actively-exploited patches, in writing, not "as soon as possible."
• Ask your provider, if you have one, to show you the current patch status across your fleet rather than assume it is handled.