Windows 11 Hotpatching Means Five Reboots in 2026, Not Four

TechRepublic’s overview of Windows 11 hotpatching gets the central premise right: security fixes can be installed on a running system without a reboot during designated hotpatch months. Microsoft’s August 11 release, KB5120994, is the current example. It provides security improvements for eligible Windows 11 24H2 and 25H2 devices and, for the first time in general availability, includes Arm64 systems that meet the additional configuration requirements.

The operational value is real. But the number IT departments should plan around is not “zero reboots,” or even Microsoft’s idealized four-baseline calendar. It is a conditional reduction in restarts that depends on enrollment, licensing, platform settings, staying current with baselines, and avoiding the out-of-cycle servicing events Microsoft explicitly reserves the right to issue.

The actual 2026 calendar has five baseline restarts​

Microsoft’s planned hotpatch cadence is straightforward on paper. January, April, July, and October are baseline months, in which an ordinary cumulative update installs and requires a restart. February–March, May–June, August–September, and November–December are intended to be hotpatch months, where eligible security fixes can install without restarting Windows.

In a clean year, that converts twelve monthly security-update reboots into four: a reduction of eight restarts, or roughly two-thirds. That is the maximum claimed benefit, assuming every device stays eligible and administrators measure only Windows monthly security servicing.

But Microsoft’s current Windows 11 release-health calendar records June 2026 as a restart-required baseline for both 24H2 and 25H2, even though June was supposed to be a hotpatch month. The July release remained the scheduled quarterly baseline. The result is five planned baseline restarts for 2026:

For a fully eligible fleet that follows this calendar, hotpatching now avoids seven of twelve routine monthly security restarts in 2026, rather than eight. That is still substantial, particularly across thousands of PCs, but it is the more accurate planning figure.

Microsoft does not present additional baseline updates as an anomaly that breaks the model; it documents them as an expected exception. Its hotpatch guidance says an extra baseline can be released for security reasons, and the quarterly schedule does not move afterward. In practical terms, an unscheduled June baseline does not replace July’s restart. It adds another one.

The planning lesson is simple: count hotpatching as a way to reduce reboot events, not a hard service-level guarantee on annual restart totals.

KB5120994 makes Arm64 coverage more useful — and more complicated​

Microsoft’s August 11 hotpatch release, KB5120994, is significant because it marks general availability of Windows 11 client hotpatching on Arm64 hardware running versions 24H2 or 25H2. The expansion matters as Snapdragon-based Windows PCs become more common in managed fleets and as organizations assess Arm hardware for mobile workers, frontline roles, and long-life endpoints.

There is a catch that deserves more attention than a footnote: Arm64 devices must disable Compiled Hybrid Portable Executable, or CHPE, before they can receive hotpatches. CHPE improves execution of certain 32-bit x86 applications on Arm64 Windows systems by using binaries that combine native Arm64 and x86 code. Microsoft says hotpatch servicing is incompatible with the CHPE OS binaries located in the system’s compatibility folder.

The change is persistent but not invisible. An administrator can deploy Microsoft’s DisableCHPE policy or set the HotPatchRestrictions registry value, then restart the PC once to make it hotpatch-ready. Microsoft warns that disabling CHPE can create application failures or performance problems for organizations dependent on 32-bit software, including legacy x86 applications, VBA integrations, and 32-bit COM add-ins without viable 64-bit replacements.

That makes the Arm64 expansion less like a blanket checkbox and more like a compatibility decision. A business with modern 64-bit software may gain the same reboot reduction as x64 fleets. A business still relying on 32-bit Office add-ins or internally developed x86 components may have to choose between those workloads’ behavior and hotpatch eligibility.

Microsoft’s support guidance also notes that security support for 32-bit Microsoft 365 Apps on Windows Arm-based devices ends in December 2026. That deadline may push some organizations toward 64-bit application validation anyway, but it does not eliminate the need to test line-of-business software before disabling CHPE.

Eligibility is the real boundary, not the Windows 11 version number​

Hotpatching is not an update option that a Windows 11 Home or unmanaged Pro PC can enable from Settings. It is an enterprise servicing feature delivered through Windows Autopatch and Microsoft Intune. Microsoft requires a Windows quality update policy with hotpatch enabled, and devices must remain on the latest applicable baseline release.

Eligible subscriptions include Windows 11 Enterprise E3 and E5, Microsoft 365 F3, Windows 11 Education A3 and A5, Microsoft 365 Business Premium, and Windows 365 Enterprise. The machine also needs Windows 11 version 24H2 or later, virtualization-based security enabled, and Microsoft Intune management. Arm64 adds the CHPE requirement.

Those prerequisites sharply limit the addressable audience. For organizations already standardized on Intune, qualifying licenses, and VBS, the feature is an incremental policy decision. For organizations using Windows Server Update Services, Configuration Manager alone, a third-party endpoint tool, or a mixed management model, hotpatching may require a management and licensing change whose cost outweighs the saved restarts.

Microsoft’s documentation is clear that Windows Autopatch is not merely an optional convenience layer here: it is how Windows 11 hotpatch deployments are created and managed. Administrators should therefore avoid treating hotpatching as a replacement for their current patch infrastructure without checking the operational implications of Autopatch enrollment, policy ownership, reporting, and exception handling.

A device that fails eligibility does not lose security coverage. Microsoft says it falls back to the standard Latest Cumulative Update. But it also falls back to the standard restart requirement. In a mixed fleet, that means a hotpatch policy does not create a uniform no-reboot experience; it creates two servicing tracks whose difference can be caused by an outdated baseline, disabled VBS, a license mismatch, or an Arm64 application dependency.

Missing a baseline turns a hotpatch month into a reboot month​

The most important operational rule is that hotpatches build on a known baseline. If a device reaches a hotpatch month without the latest baseline update installed, Microsoft sends it the baseline and the current hotpatch. The baseline requires a restart.

That behavior protects the security state of the device, but it exposes a common deployment mistake: treating the quarterly restart as optional because the next month has a hotpatch release. It does not. Missing the baseline changes the device’s patching path and erodes the reboot reduction that justified hotpatching in the first place.

Feature upgrades require similar timing discipline. Microsoft says a device upgraded to a newer supported Windows version during a baseline month can stay on the hotpatch cycle. Upgrade it during a hotpatch month, and it moves to standard updates until the next baseline release, which means a restart is required.

This is a concrete reason to coordinate Windows 11 feature-update rings with the hotpatch calendar. A 24H2-to-25H2 rollout that begins in August, for example, may deliver an avoidable operational benefit loss compared with one timed around October’s baseline. The difference is not whether the PC remains protected; Microsoft continues to service it. The difference is whether it remains on the lower-interruption path.

One-restart-a-month and hotpatching solve different problems​

Microsoft’s new “one restart a month” update experience, which began rolling out for updates released on or after July 28, handles a separate part of the reboot problem. It holds restart-requiring driver, .NET, and firmware updates so they can share the restart scheduled with the monthly security update.

This feature applies across Windows 11 24H2, 25H2, and 26H1, and Microsoft says it is rolling out gradually. It does not make those updates rebootless; it organizes their reboot demands around one event. Critical or expedited driver updates, emergency and out-of-band fixes, Defender intelligence updates, and AI component updates can still install outside that monthly grouping.

Hotpatching changes the premise for eligible security fixes. Instead of waiting for a restart to complete their installation, hotpatches are designed to apply while Windows remains running. The two systems can coexist: hotpatching reduces the number of monthly security restarts on qualifying managed PCs, while the consolidated-restart feature reduces duplicate reboot prompts caused by other updates.

For administrators, the practical outcome is a more disciplined maintenance model rather than a maintenance-free one. Baseline months still need a restart plan. Firmware and device-driver changes still need testing. Out-of-band security incidents can still override predictable schedules. And hotpatch eligibility needs monitoring as closely as update compliance, because the fleet only gets the lower-interruption benefit when it remains on the intended servicing track.

Windows 11 hotpatching is therefore worth enabling for Intune-managed organizations that already meet its licensing and VBS requirements, particularly where user downtime, long-running workloads, kiosks, or remote connectivity make restarts expensive. The measured promise for 2026 is seven avoided routine monthly security restarts, with five remaining baseline restarts, assuming the published calendar holds and devices remain eligible. That is a meaningful reduction — just not an end to the maintenance window.