Hotpatch takes September and October off—your Windows 11 and Server fleet reboots

The whole point of Hotpatch is that nobody notices patch Tuesday. The security fix lands, the machine keeps running, the user keeps typing. No reboot, no “your PC will restart in 15 minutes” nag, no 3 a.m. maintenance window for the server team.

For September and October 2026, that promise is off. Microsoft has confirmed that Hotpatch-enabled Windows 11 Enterprise and Windows Server devices will need a restart to take the September security release, with a second restart expected in October. Two consecutive reboot months on a feature you specifically deployed to avoid reboots.

It’s temporary. Hotpatch isn’t being killed, walked back, or quietly deprecated. But if you built your patch rhythm around it, you now have two months where the rhythm doesn’t hold — and it’s worth understanding exactly what you’re trading, because the two patch styles aren’t interchangeable.

Two ways to close the same hole

Think of a running application you can’t take down. A hotpatch is like a surgeon operating on a beating heart: the fix is applied to the code already loaded in memory, live, while the process keeps executing. Nothing on disk gets swapped, so nothing needs to be reloaded, so the machine never has to restart.

A cold patch — the normal Windows Update kind — is the opposite. You replace the files on disk and the change only takes effect when those files get loaded fresh. That means a reboot. It’s the difference between changing a tyre at the pit stop versus changing it while the car is still doing 180 down the straight.

Both close the same vulnerability. Same CVEs, same KB content. The distinction is purely how the fix gets into the running system. And that’s why Hotpatch has never been a standalone thing: it runs on top of a periodic baseline — a full cold-patch build that establishes the foundation the in-memory patches attach to. In the normal cadence you get a baseline (reboot) once a quarter, then two hotpatch months (no reboot) after it. Eight quiet months, four noisy ones, per year.

So let’s run these two side by side on the things that actually matter when you’re the one holding the pager.

Round 1 — user and workload disruption

No contest. Hotpatch wins, and it wins by a mile. This is the entire reason the feature exists. A reboot-free security update means a frontline worker’s shift isn’t interrupted, a session host doesn’t drain users, a domain controller or SQL box stays up. On a fleet of Windows 365 Cloud PCs or a farm of session hosts, avoiding a coordinated reboot is worth real money and real goodwill.

Hotpatch 1, Baseline 0.

Round 2 — security parity

Dead heat, and this is the round people get wrong. Skipping the reboot does not mean skipping the fix. A hotpatch month delivers the same security content as the cold equivalent. Nobody is less protected in a hotpatch month than in a baseline month. So when Hotpatch pauses for September and October, you aren’t getting more secure by rebooting — you’re getting the identical protection through a more disruptive delivery method.

Tie. Still Hotpatch 1, Baseline 0.

Round 3 — rollback and predictability

Here the cold patch earns its keep. A reboot is a clean slate: the system reloads from a known set of files on disk, and if something’s wrong, a baseline build is a well-understood unit to remove and reapply. Live in-memory patching is elegant, but “elegant” and “easy to reason about at 2 a.m. during an incident” are not the same sentence. A machine that’s been up for weeks with a stack of hotpatches applied is a more complicated state than one that reboots monthly.

Predictability leans cold too. A scheduled reboot window is a boring, solved problem — every ops team on earth already has one. The “usually no reboot, occasionally a reboot, and sometimes an unplanned extra reboot month” pattern is harder to socialise with change management.

Baseline takes the round. Hotpatch 1, Baseline 1.

Round 4 — September and October 2026 specifically

This round is a walkover, because you don’t get a choice. For these two releases, Hotpatch-enabled devices are on the cold path whether they like it or not. Baseline wins by default.

Two things worth saying plainly. First, Microsoft has not disclosed a technical reason for the pause. Resist the urge — and resist the vendor blog that inevitably invents one — to fill that vacuum with a confident-sounding cause. We don’t know. Second, and this is the bit nobody’s underlining: in the standard Hotpatch calendar the baseline (reboot) months fall quarterly — January, April, July, and October. October is already a reboot month. The disruptive change here is September, a month that should have been reboot-free and now isn’t. October was always going to bounce your machines; it’s just arriving with company.

Baseline 2, Hotpatch 1 — for these two months only.

The verdict

Over a normal year, Hotpatch wins hands down: eight months where users and workloads never feel patch day, at zero cost to your actual security posture. That’s a good deal and one of the better things to come out of the Windows servicing team in a while.

For September and October 2026, the crown goes to the plain old reboot, because you’re getting one regardless. Plan for it like any other maintenance month: schedule the windows, set the deadlines and grace periods, warn the humans. The one case where you’d still lean on the Hotpatch mindset even now — session hosts, Cloud PCs, and always-on servers where an uncoordinated restart is damaging — is exactly where you should be tightening your reboot orchestration this month, not loosening it.

When does the quiet return? Microsoft hasn’t committed to a firm date. The reasonable expectation is that the reboot-free experience resumes after this pause — November is the natural candidate given the quarterly baseline structure — but treat that as unconfirmed and don’t build a maintenance plan that assumes it.

Who’s actually in scope

Hotpatch isn’t on by default and it isn’t available everywhere, so “am I affected?” is a real question, not a rhetorical one.

On the client side, Hotpatch is a Windows 11 Enterprise capability on x64, delivered through Intune quality update (Hotpatch) policies or Windows Autopatch. It’s covered by the usual enterprise entitlements — Microsoft 365 E3/E5, Windows Enterprise E3/E5, and Windows 365 Enterprise. Home and Pro don’t get it. Arm64 has had extra prerequisites around virtualization-based security, so don’t assume parity there.

On the server side, Hotpatch for Windows Server 2025 is a subscription, billed per core, and it requires the servers to be connected through Azure Arc (Azure-edition VMs get it natively). If nobody enrolled your servers, they were never hotpatching and this pause changes nothing for them.

Where to look, and how to inventory the fleet

The client policy lives in the Intune admin center → Devices → Windows → Manage updates → Windows quality update policies, where a Hotpatch-enabled policy is a distinct policy type. Autopatch groups surface it too. For servers, it’s in the Azure portal under Windows Server Hotpatch. That’s where you confirm who’s enrolled and, if you need to, temporarily relax settings for the reboot months.

Before you touch anything, get an honest picture of which Windows Enterprise devices you’re even talking about. Here’s a read-only pull from Microsoft Graph — no changes, just inventory — with pagination and error handling so it survives a real tenant:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# Read-only: inventory Intune-managed Windows Enterprise devices
# Requires: Microsoft.Graph module, DeviceManagementManagedDevices.Read.All
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All" -NoWelcome
​
try {
    $devices = Get-MgDeviceManagementManagedDevice -All -ErrorAction Stop `
        -Filter "operatingSystem eq 'Windows'" `
        -Property "deviceName,osVersion,skuFamily,managedDeviceOwnerType,lastSyncDateTime"
​
    $devices |
        Where-Object { $_.SkuFamily -match 'Enterprise' } |
        Select-Object DeviceName, OsVersion, SkuFamily, LastSyncDateTime |
        Sort-Object OsVersion |
        Export-Csv -Path ".\win-enterprise-inventory.csv" -NoTypeInformation
​
    Write-Host ("Exported {0} Windows Enterprise devices." -f `
        (@($devices | Where-Object { $_.SkuFamily -match 'Enterprise' }).Count))
}
catch {
    Write-Error "Graph query failed: $($_.Exception.Message)"
}
finally {
    Disconnect-MgGraph | Out-Null
}

That CSV is your starting point — the set of machines where a Hotpatch policy could apply. Cross-reference it against the actual policy assignments in Intune to find the devices that were genuinely relying on reboot-free updates. Those are the ones whose owners are about to get a restart prompt they haven’t seen in a while. The kindness is telling them before the machine does.

Hotpatch is still one of the better bargains in Windows servicing. It’s just handing you the bill for two months. Book the window, set the deadline, and don’t let anyone tell you the reboot means you’re finally “properly” patched — you were patched the whole time.