Mustafa ERBAY

Posted on Sep 8 Originally published at mustafaerbay.com.tr

Hotpatching Went Free, Reboots Didn't Stop

#windowsserver #hotpatch #azurearc #sysadmin

As I write this it's 8 September 2026: the second Tuesday of the month, which means Patch Tuesday. One of the first pages I opened this morning was Microsoft's hotpatch calendar, and next to September on the Windows Server 2025 row sat a single phrase: Baseline (Restart).

What makes that interesting is that hotpatching became free four months ago. The feature that has been sold for years as "patching without a restart", and that got a per-core price tag last summer, now costs nothing. Yet the same calendar says its core promise — four reboots a year instead of twelve — did not hold in 2026.

Here's my argument: hotpatching is good engineering, and dropping its price is good news. It just doesn't eliminate restarts, it thins them out — and it renegotiates how much thinning you get every year. What you pay in return is less about money than about dependency.

What hotpatching actually does

The mechanism is described simply enough: hotpatching patches the in-memory code of running processes, so the process never has to restart. Fewer binaries get downloaded, installation is faster, and disk and CPU take less of a beating.

The rhythm is quarterly. In the first month of each quarter the machine receives a baseline cumulative update that requires a restart; over the next two months it gets hotpatches that carry only security fixes and need no reboot. The example in Microsoft's own documentation describes exactly that cadence: four baselines and eight hotpatches in a calendar year.

The documentation is honest enough to define a second concept: the unplanned baseline. When an important update — a zero-day fix, say — can't be packaged as a hotpatch, that month's hotpatch is replaced by a baseline. And a baseline means a restart. In the documentation's own words, because these events are unplanned they can't be predicted in advance.

The first time I read that sentence I filed it away as a footnote. The 2026 calendar showed me it wasn't one.

A price tag that reversed in under a year

The commercial story of this feature is every bit as instructive as the technical one, so let me lay the dates out in order.

In April 2025 the announcement landed on the Windows Server blog: hotpatching, made available in preview in 2024, was becoming generally available as a subscription service as of July 2025. The price was $1.50 USD per CPU core per month. The same post stated the promise plainly: instead of rebooting monthly, twelve times a year, you reboot quarterly — four times.

Then came 19 May 2026. The billing section of the Azure Update Manager documentation now reads: hotpatch on Azure Arc-enabled machines running Windows Server 2025 Standard or Datacenter is available at no additional cost. No per-core meter, no hourly charge, no separate hotpatch line item on the invoice. Billing was stopped for servers already enrolled; they stay enrolled and keep receiving hotpatch updates.

When a feature's price reverses within ten months, I think there's more than a product decision behind it. Selling the delivery method of an OS security update by the core was an awkward position from the start; nobody who wants to patch a server wants to first count cores. What became free is the feature; what's being asked in return is that your inventory becomes visible in Azure. I don't say that as a conspiracy — the trade is simply out in the open: the money left, the dependency stayed.

The 2026 calendar: four promised, six delivered

This is where it gets real. Microsoft publishes the Windows Server hotpatch calendar month by month, and 2026 looks like this:

Month	Type	Release	Build
January	Baseline (restart)	2026-01-13	26100.32230
February	Hotpatch	2026-02-10	26100.32313
March	Hotpatch	2026-03-10	26100.32463
April	Baseline (restart)	2026-04-14	26100.32690
May	Hotpatch	2026-05-12	26100.32772
June	Baseline (restart)	2026-06-09	26100.32995
July	Baseline (restart)	2026-07-14	26100.33158
August	Hotpatch	2026-08-11	26100.33296
September	Baseline (restart)	scheduled	—
October	Baseline (restart)	scheduled	—
November	Hotpatch	scheduled	—
December	Hotpatch	scheduled	—

A quarterly rhythm means January, April, July, October. June and September fall outside it; both are extra restart months that took the place of that month's hotpatch. A caveat is in order here: Microsoft marks unplanned baselines with an asterisk in that calendar, and not a single 2026 row carries one. So these aren't months that broke after the fact; they were announced as baselines from the start. Not even a surprise — the plan itself.

Four restart months happened in the first eight months of the year, and the calendar schedules two more for the rest of it. Six restart months against six hotpatch months: half the year either way.

But is this a typical year? At the risk of undermining my own argument: no. On the same calendar, 2025 ran exactly as promised, with baselines in January, April, July and October — four reboots, eight hotpatches. Windows Server 2022's 2024 has five baselines, and only one of them, August, is starred, meaning it genuinely replaced a planned hotpatch. Three years of record, then: five, four and six.

So hotpatching isn't failing. Twelve reboots became six, and that's a real gain. But "four a year" is an assumption about a good year, not a guarantee. And to be honest, my own "six" is provisional too: November and December haven't shipped yet, and if either turns into a baseline the number becomes seven. When you're planning maintenance windows, the difference between an assumption and a guarantee is exactly the kind that surfaces at three in the morning.

What falls outside the scope

Hotpatching covers Windows security updates only. The documentation lists the exclusions one by one: nonsecurity updates for Windows, .NET updates, and non-Windows updates such as drivers and firmware. For those you still need to restart the machine, including during hotpatch months.

So "hotpatching is on" doesn't mean "no reboot this month"; it means "no reboot for the Windows security update this month". If a .NET update is pending on your domain controller, the colour of the calendar doesn't change.

There's one more item, and I think it's the least discussed: hotpatch updates have no automatic rollback. If you hit a problem, what you have to do is uninstall the latest update and install the last functional baseline. That process requires a restart.

What that means in practice: your way back still runs through a reboot, and you'll be spending it not on a night you picked but on the night things went sideways. On your server's worst night, the only exit available is a restart you have to perform right then.

The real invoice: prerequisites

With the fee line gone, the prerequisites list became far more visible. For Arc-enabled hotpatching you need:

Windows Server 2025, build 26100.1742 or later. Preview and Insider builds aren't supported, because hotpatches aren't created for prerelease operating systems.
Standard or Datacenter edition. On Datacenter: Azure Edition hotpatching is already enabled by default and Arc isn't required — but, as the documentation underlines, the remaining technical prerequisites still apply.
Virtualization-based security, meaning VBS/VSM. The documentation states the minimum bar directly: the machine has to use UEFI with Secure Boot enabled. For a virtual machine on Hyper-V, that means a generation 2 VM.
An Azure subscription, and the machine connected to Azure Arc.

The portal already checks whether VSM is running when you enable hotpatching, and enablement fails if it isn't. Which is why asking the question up front is the cheaper move:

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' -ClassName 'win32_deviceGuard' |
  Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'

If the output is 2, VSM is up. If it isn't, you enable it and restart the machine once — the fact that the first step toward reducing restarts is a restart did, I'll admit, make me smile.

The true face of the dependency, though, shows up in what happened in October 2025. According to the known issues section, after that month's updates the hotpatch feature licence expired on some machines, while on new machines enablement got stuck in an "in progress" state. Two workarounds were offered: either install a separately packaged group policy template and enable the remediation through it, or stop the HIMDS service and run a script that writes a feature override into the registry. Both by hand, on every machine, with a restart.

And the price of skipping them? The documentation states it plainly: regular, reboot-bearing updates up to and including the January 2026 baseline. November, December, January — three months of restarting every month. The same section holds a second trap: to keep receiving hotpatches the machine had to sit on exactly one of two specific update levels, and anyone who installed an out-of-band update released in late October became incompatible with upcoming hotpatches. Dropping out of hotpatching because you applied a patch is a class of failure with no equivalent in the classic patching world.

In fairness: the page today says there are no known issues at this time and that all past issues are mitigated. But the episode stands as an unusually clear account of what this feature ties you to.

My own cluster isn't invited

Let me be concrete. In the two-node Hyper-V failover cluster I run, both hosts are on Windows Server 2022. Arc-enabled hotpatching exists only for Windows Server 2025 Standard and Datacenter; on 2022, hotpatching is limited to specific Azure Edition images on Azure and Azure Local. So my two nodes are not on the guest list.

That didn't bother me, because I had solved the same problem from another direction. The cluster runs Cluster-Aware Updating: once a month, on the third Saturday at 03:00, it drains a node, applies the patches, restarts it, resumes the roles, then moves to the other node. Its first run took 22 minutes and not one of the virtual machines on top of it saw an interruption. The cumulative update that landed on HV1 in that run was KB5094128 — which, looking at the hotpatch calendar, is precisely the June 2026 baseline on the Windows Server 2022 side. My host isn't in the hotpatch programme, so there it's just an ordinary monthly update. The fact that the same KB is called a "baseline" on one side and "this month's LCU" on the other says something useful: hotpatching isn't a new kind of patch, it's a new way of delivering one.

The distinction is easy to see from here. Clustering makes the restart invisible; hotpatching makes it rare. Those are different problems. Where you can drain roles, hotpatching mostly buys operational comfort; where you have no second node to drain, it buys availability outright.

If it were up to me, I'd order the work like this: cluster what can be clustered first, then look at hotpatching for what can't. Hotpatching earns its keep on the standalone boxes nobody dares power off during business hours — the phone system, the licence server, the ageing application server that accounting remembers only at year end, and a fourth whose name nobody quite recalls.

The same bargain exists on Linux

I couldn't write this without making a comparison, because live kernel patching has been around on Linux for years and the scope debate isn't settled there either.

The kernel's livepatch documentation lists the fixes the mechanism handles best: null pointer and boundary checks, race fixes via memory barriers, locking around critical sections. It's equally clear about the limits: only functions that can be traced may be patched, fixes that change the meaning of temporary structures get complicated because they require several functions to switch at once, and modules loaded after the patch are a separate matter.

So in both worlds, live patching is a negotiation over scope. The vendor decides which fixes can travel hot, and you find out what didn't make the list — usually on the second Tuesday of the month. I've written separately about kernel live patching and the maintenance model in enterprise Linux; the conclusion there applies here too. Live patching lowers the bill for your maintenance window. It doesn't close the window.

Should you turn it on

A short framework beats a long meeting:

Is the server on 2025? If not, the discussion is over. Arc-enabled hotpatching doesn't reach 2022.
Can it be drained? If it's in a cluster and draining already works, hotpatching isn't urgent. Queue it.
Can VBS be enabled? UEFI, Secure Boot, generation 2 on Hyper-V. Converting an older-generation VM is a bigger job than hotpatching itself.
Is connecting to Arc acceptable? An Azure subscription, an agent, outbound connectivity. Don't decide this without asking your security and procurement people; it's technically easy and organisationally not.
What about your other reboot-requiring updates? If .NET and drivers already have you restarting regularly, hotpatching will win you fewer nights than you think.
Who handles delivery and verification? You can schedule hotpatches with Azure Update Manager; configuring the Windows Update client through group policy, or using a third-party patching solution, is supported too. Whichever you pick, make sure you have somewhere to see whether what arrived this month was a hotpatch or a cumulative update — the "reboot required" column in an assessment result, or Get-HotFix on the machine, does the job.

Pay particular attention to the fifth point. It's usually what surprises teams who enable hotpatching and then keep rebooting every month anyway.

A reboot isn't a cost, it's a capability

Tonight, on the second Tuesday of the month, the September baseline lands the same way on machines with hotpatching enabled and on those without. The feature that became free four months ago spares nobody a restart this month.

I don't read that as a disappointment. Quite the opposite — it's a healthy reminder that being able to restart a server on the night you choose, under control, without anyone noticing, is the actual asset in your infrastructure. Hotpatching thins out how often you need that capability; it never claimed to replace it. And the degree of thinning is decided not by whoever plans your calendar but by that year's vulnerabilities.

As someone who has lived through what it costs to depend on a single domain controller, I'll say this comfortably: "we can't restart it" is not a patching problem, it's an architecture problem. Hotpatching helps you postpone it. Don't expect it to solve it.