On 8 September 2026, Microsoft shipped a mandatory security update, KB5124008, days after publicly warning users not to delay their updates because of rising AI-assisted threats. The update broke Windows Subsystem for Linux, Remote Desktop Services, File History backups, and caused Explorer.exe crashes. Among the casualties: Claude's own desktop file access, which greeted affected users with a line that could serve as this article's epitaph: "Reinstalling won't fix this." Anthropic wasn't exaggerating. Neither, this time, was Microsoft's own support documentation, which quietly confirmed the same underlying fault.
It's a small irony, but it's the right size to open on, because it captures the whole argument in one sentence. The institutional claim is that patching promptly keeps you safe. The operational reality, this year, has repeatedly been that the patch is the incident.
This isn't a one-off. Pull the last twenty-two months of Windows 11 cumulative and feature updates and a pattern sits right there on the surface: not occasional friction, but a recurring failure mode, several of them on updates marked mandatory.
January 2025 broke USB DAC audio and built-in webcam detection in the same update, then locked BitLocker settings on TPM-equipped managed PCs. February brought a spinning-cursor bug and broke Adobe Premiere Pro's timeline on multi-monitor setups. March managed two failures in one month: an update that quietly uninstalled the Copilot app for some users (more on that irony shortly), and a separate mandatory patch, KB5053598, that caused install loops and outright BSODs, not properly fixed until April. April's update broke Windows Hello's IR camera login for anyone using a privacy shutter, which is to say, anyone who'd taken the sensible security step of physically covering their webcam. May froze File Explorer for some users and broke CJK font rendering for others. Through the summer, monthly cumulative updates degraded gaming performance in Fortnite and CS:GO, root-caused only in July. June's update generated false Windows Firewall errors, and Microsoft's own July "fix" for the false errors was itself confirmed false by independent testing before a real fix eventually shipped.
August broke "Reset This PC" and the recovery path itself, on the very feature you'd reach for when an update goes wrong, needing an emergency out-of-band patch. September caused DRM video jitter. October's mandatory update broke WinRE keyboard and mouse input and, separately, broke localhost connections for every developer running anything locally, while falsely flagging File Explorer's preview pane as a security risk. November's Task Manager bug spawned duplicate background processes that Microsoft itself confirmed could degrade performance on lower-end hardware. December broke File Explorer's dark mode and hid the Windows Hello password fallback icon.
Then 2026 opened with black screens and frozen Outlook accounts in January, on the same update cycle that also caused shutdown and hibernation failures on Windows 11 Enterprise and IoT devices, plus wider remote desktop authentication failures across several Windows versions, requiring its own emergency patch within days. And now September 2026's KB5124008, above.
Remote Desktop alone has broken in three separate update cycles in this window. That's not an unlucky year. That's a component nobody's actually testing before it ships.
None of this would matter as much if switching costs were low. They aren't, and Microsoft made that decision, not the market. Windows 10 reached end of mainstream support on 14 October 2025. Windows 11's hardware requirements, TPM 2.0 chief among them, are still locking a meaningful share of the fleet out entirely. ControlUp's own tracking, across more than 1.1 million enterprise-managed Windows endpoints, finds 13% needing hardware replacement to run Windows 11 at all, no workaround available, a figure that's held roughly steady even as migration has progressed. That's the enterprise-managed slice ControlUp can actually see; extrapolated across Windows' full installed base the exclusion plausibly runs into the hundreds of millions of machines, but nobody's produced a verified global count, so that extrapolation stays a plausible order of magnitude rather than a citable figure. For that population the choice isn't Windows 10 versus Windows 11. It's pay for Extended Security Updates, buy new hardware, run an abandoned OS, or leave.
A measurable number are leaving. StatCounter's own figures put global Linux desktop share at roughly 2.76% in July 2022, rising to around 4.7% by the end of 2025, with the US crossing 5% for the first time in June 2025. Worth qualifying honestly: StatCounter measures web traffic, not installed base, and its monthly figures bounce around a good deal, partly because a growing "Unknown" category, driven by privacy tools masking browser fingerprints, is absorbing traffic that may itself skew Linux-heavy. The direction is real; the exact monthly figure isn't something to hang a sentence on. Steam's own hardware survey is cleaner: Linux passed 3% of surveyed gamers for the first time in October 2025 (3.05%), then spiked to a record 5.33% in March 2026 before pulling back to 4.52% in April and settling further from there. Valve's survey samples a shifting subset of users and swings by a point or more most months, so treat the March figure as a high-water mark rather than a stable level, but the year-on-year trend, roughly doubling between April 2025 and April 2026, holds regardless of which month you pick. Every account of the shift names the same three drivers: hardware exclusion, the Windows 10 deadline itself, and fatigue with Microsoft's Copilot-first direction, which brings us to the second half of this piece.
Windows 11's stability record would be one story on its own. What makes it a governance story is that the same eighteen months produced a parallel pattern: features that install themselves, reinstall themselves, or repair themselves, with the user's actual consent treated as optional.
Windows Recall is the clearest case. Announced in May 2024 as the flagship Copilot+ PC feature, screenshotting the screen every few seconds and indexing it for natural-language search, it was immediately called a privacy nightmare and delayed past its original ship date. Microsoft's response to the backlash was to make it opt-in, add a biometric gate, and keep storage local, changes real enough that Signal built its own countermeasure into its Windows app specifically because, in its own words, Microsoft had "given us no other option." Even after the overhaul, researcher Alexander Hagenah, who'd broken the original Recall in 2024, published a new proof-of-concept tool in April 2026, TotalRecall Reloaded, showing that malware could ride along with a legitimate Windows Hello authentication and extract everything Recall had captured once the data was decrypted for display. Independent researcher Kevin Beaumont corroborated it within days, reporting he could read the database as a standard user process with no AV or EDR alert triggered. Microsoft's response, through security VP David Weston, was that this was "consistent with intended protections" and not a vulnerability at all. The claim that Recall had been fixed didn't survive someone actually looking, and Microsoft's answer to that finding was to redefine what counts as fixed.
Then there's Copilot itself, which manages the rare trick of being both accidentally deleted and impossible to delete on purpose. The March 2025 update that uninstalled it for some users was followed by a patch to force it back onto affected machines. Meanwhile, a persistent, unresolved complaint thread running from late 2025 into 2026 documents the opposite problem: users who deliberately uninstall Copilot find it silently reinstalled by the next cumulative update or the Microsoft Store, prompting Microsoft to add a dedicated Group Policy, RemoveMicrosoftCopilotApp, generally available from April 2026. Its conditions are narrow enough to undercut the fix: it only applies where Microsoft 365 Copilot is also installed, the standalone app wasn't user-installed, and it hasn't been launched in 28 days, a bar Copilot's own auto-start at sign-in makes hard to clear. Even where it applies, Microsoft's own documentation confirms the user can simply reinstall it afterwards.
Quick Machine Recovery is the more interesting case, because it isn't a bug, it's the stated fix. Introduced after the 2024 CrowdStrike outage as the centrepiece of Microsoft's Windows Resiliency Initiative, QMR watches for repeated boot failures, and when it finds one, boots into WinRE, contacts Microsoft's cloud remediation service on its own, and downloads and applies whatever fix that service returns, with no admin review before it touches a production machine. Microsoft's own documentation is explicit that it doesn't affect files, apps, or settings, so the risk here isn't data loss, it's process: an unreviewed, cloud-sourced patch applied automatically to a machine that's already in a failure state. The detail that actually matters for a governance argument is the default split. QMR ships enabled by default on Windows 11 Home, the population least equipped to evaluate what got pushed to their machine, and disabled by default on Pro and Enterprise, the population with the tooling and the obligation to review it. If the goal were genuinely to put automated remediation where it does the least harm, the defaults would run the other way.
Taken together: Microsoft can delete a feature from your PC by accident and restore it without asking, can fail to remove a feature you've explicitly uninstalled, and now automatically fetches and applies unreviewed fixes to the population least able to audit them. None of that is a stability failure. It's a design position about who's actually meant to be in charge of the machine, and it isn't you.
None of this is an argument to switch overnight, and if your business runs specialist accounting, CAD, or legal software that only exists on Windows, that alone can end the conversation before it starts. But for the ordinary SME desktop, the practical objections that used to be real have mostly aged out, and it's worth being specific about which ones.
Printing used to be the single biggest reason a small office wouldn't touch Linux. That's largely gone. Most network printers made since around 2012 support IPP Everywhere, a self-certified driverless standard, the same one behind AirPrint and Mopria, so CUPS discovers them over the network and prints to them with no vendor driver involved. CUPS 3.x, current now, leans further into that by design. The genuine exception is older USB-only printers or manufacturer-specific extras like ink-level reporting, where you may still need a vendor driver or a "Printer Application" bridge on newer CUPS. Worth checking your fleet's actual printers against OpenPrinting's compatibility database before committing, rather than assuming.
Wi-Fi and Bluetooth have had a similar trajectory. Intel, Broadcom, and most Realtek chipsets from the last several years are supported directly in the mainline kernel now, no driver disc, no manual compilation. The rough edge that's left is the very newest silicon: a brand-new Wi-Fi 7 or Bluetooth 5.4 controller can lag a kernel cycle or two before mainline support lands, so check a specific model's chipset before buying rather than assuming. On hardware that's a generation or two old, which describes most of an SME's existing fleet, it generally just works.
On software, the honest picture: browser-based line-of-business tools, which now cover most SaaS accounting, CRM, and practice-management platforms, don't care what's underneath them. LibreOffice handles day-to-day document and spreadsheet work for most ordinary office use, though heavily macro'd spreadsheets and elaborately templated Word documents are where it can still show seams. For the odd Windows-only legacy application, Wine or a Windows VM covers some cases, not all, and that remaining gap is a genuine reason a migration can stall.
None of this needs a flag day. The sensible way to test it is a spare machine, a live USB stick, or one willing department running Linux Mint or an Ubuntu LTS release, both deliberately laid out to feel familiar coming from Windows, for a few weeks alongside the existing fleet, not a company-wide switchover on a Friday afternoon. It's not a leap into unsupported territory either: Canonical, SUSE, and Red Hat all sell commercial support contracts aimed at exactly this size of business, so "who do we call when it breaks" has an actual answer if that's the sticking point.
This isn't hypothetical for me, either. My first MacBook Air, a 2015 Intel model, hit the point where Apple decided it was too old for further macOS support years before the hardware itself had anything wrong with it. Linux Mint is what's kept that machine useful since, running perfectly well on hardware its original vendor had already written off. Worth being clear that this isn't a Microsoft-specific complaint: any vendor that ties ongoing software support to a hardware cutoff eventually leaves you standing exactly where that laptop sits, and Linux is routinely what's waiting on the other side of that cliff edge for anyone who'd rather not buy new hardware just because a vendor decided to move on.
The fair version of this argument isn't "Linux has caught up in every respect." It's that the specific objections an SME would have raised five years ago, printing, Wi-Fi, driver hunting, are mostly solved for mainstream hardware bought in the last few years, and the friction that's left is narrower and more predictable than it used to be. Worth trying on something that isn't your whole fleet before deciding either way.
The standard rebuttal to any of this is that Linux isn't inherently more secure, it just has fewer eyes on it, and that a hardened Windows box is just as defensible as a hardened Linux one. That claim doesn't survive contact with what SELinux actually is or does.
SELinux was originally developed by the NSA. It implements mandatory access control at the kernel level: every process, file, and socket carries a security context, and access is denied by default unless policy explicitly permits it, regardless of ordinary file ownership or the discretionary permissions Windows relies on. It's not a niche add-on. It's been the default on RHEL, Fedora, and their derivatives for two decades, ships in Debian and Ubuntu, and runs on essentially every Android phone in the world. And it isn't standing still: openSUSE Tumbleweed switched SELinux to enforcing by default in February 2025, with Leap 16 following, meaning new installs no longer get a choice about whether to run hardened, they simply are, by default, out of the box.
Windows' nearest equivalents, WDAC and AppLocker, are opt-in, largely confined to Enterprise SKUs, and require deliberate, ongoing configuration to approach SELinux's default-deny posture. "Windows can be hardened too" is true in the abstract and irrelevant in practice, because it isn't what ships turned on.
I'm not arguing this from a manual. I run Tumbleweed. Bringing up a Mastodon lab environment on it this year, I hit SELinux enforcing head-on: containers refusing to write to correctly-owned, bind-mounted data directories, twenty minutes of head-scratching before the actual cause turned up, a security context mismatch on the mount, fixed with a single chcon call. The instinct in that moment is to disable the thing that's in your way. The correct move, and the one that's actually defensible in an audit, is to ask why it's in your way, fix the context, and leave enforcement on. setenforce 0 is duct tape over a check engine light. I wrote the whole episode up at the time; it's linked below.
That's the actual contrast worth making. Not "Linux never breaks", it does, and SELinux denials are real friction. The contrast is that one operating system makes hardening the default you have to deliberately weaken, and the other makes convenience the default and treats hardening as an enterprise upsell, while also reserving the right to install, delete, and repair things on your machine without asking which side of that trade you'd have picked.
Editor's note: this piece sits alongside "Patched On Time Is Not the Same as Patched Safely", which covers the same September 2026 update from the compliance-timing angle rather than the OS-choice angle covered here.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy, with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.