Microsoft will begin enabling hotpatch updates by default for all eligible Windows endpoints managed by its Autopatch service starting in May 2026, according to a new advisory. The shift means that instead of the traditional monthly cumulative updates that force a reboot, Autopatch will deliver security patches that install without interrupting the user, dramatically cutting downtime — but it also requires IT teams to document their readiness for baseline reboots, fallback mechanisms, and ownership of the update process.
What’s changing, and when
The key change is a new Allow/Block Hotpatch policy in Windows Autopatch. Beginning May 2026, this setting will default to Allow for all devices that meet Microsoft’s eligibility criteria. Previously, hotpatch capability in Autopatch was either off by default or required an explicit opt‑in; the upcoming default represents a concerted push to expand the reach of reboot‑less patching.
Hotpatch works by delivering a small, in‑memory patch that fixes security vulnerabilities without taking the system offline. However, the technology depends on a quarterly baseline update — a larger, cumulative package that does require a reboot. Between baselines, monthly security fixes can be applied hot, so instead of rebooting 12 times a year, users may only see a reboot every three months, provided everything runs smoothly.
Eligibility for hotpatch in Windows Autopatch currently includes devices running Windows 11 Enterprise or Pro (client SKUs) that have Virtualization‑Based Security (VBS) turned on and are enrolled in the Windows Insider Program for Business or the General Availability Channel where hotpatch is supported. Microsoft has not yet confirmed whether Windows 10 will ever be included; the deadline for Windows 10 support is October 2025, so the May 2026 timeline effectively targets Windows 11 devices only.
What the default change means for you
For everyday users
If your PC is managed by your organization through Autopatch and is eligible, you’ll notice far fewer of those “please restart” prompts after monthly updates. The only regular reboots will come when the quarterly baseline is installed — roughly once every three months. In the background, you won’t see any difference: patches will be applied silently, and the device remains protected.
There is a catch. Occasionally, a hotpatch installation might fail. When that happens, the system falls back to the traditional full cumulative update, which will require a reboot. Users might be caught off guard if they haven’t been told to expect an occasional restart. Clear communication from IT will be critical.
For IT administrators and Autopatch tenants
The default “Allow” means that, unless you actively change the policy, Autopatch will begin delivering hotpatch updates to all eligible devices in your tenant. Microsoft’s advisory explicitly warns that you should leave this default in place only when you have documented:
- Update ownership — who manages update policies and how conflicts with other Windows Update for Business configurations are resolved.
- Baseline‑reboot tolerance — how your organization will handle quarterly baseline reboots, including user notification and scheduling.
- Fallback‑reboot handling — what happens when a hotpatch installation fails and a traditional update with reboot is triggered; how you’ll inform users and monitor the fallback process.
If any of these items isn’t fully addressed, the recommendation is to override the default and set the policy to Block until you’re ready. You can do this outright via Intune or Autopatch configuration profiles.
Additionally, because hotpatch alters the reboot cadence, your usual maintenance windows may need adjustment. The quarterly baselines should still fall into your regular update ring schedules, but the near‑elimination of monthly reboots might affect compliance with internal SLAs that assume monthly downtime.
Finally, not every device in your environment will be eligible. You’ll need to run discovery to identify which endpoints are on Windows 11 with VBS enabled and which are not. Devices that aren’t eligible will continue to receive standard cumulative updates as before, with no change in reboot frequency.
How we got here
Microsoft introduced hotpatching in 2021 for Windows Server 2022 Azure Edition, where the ability to apply security fixes without rebooting was a major selling point for hyperscale cloud workloads. The technology relies on code integrity and memory patching that originated in the Azure security stack.
In 2023, hotpatching began trickling down to client devices through the Windows Insider Program. It required specific hardware (VBS‑capable processors) and Windows 11. By late 2024, Microsoft had baked hotpatch support into Windows Update for Business and started making it manageable through standard MDM policies. The release of Windows Autopatch itself — a service that automates entire update ring management across Intune — set the stage for a more aggressive rollout.
The May 2026 default change is the culmination of that effort. By setting “Allow” as the new baseline, Microsoft is signaling that hotpatch is mature enough to be the default experience for supported devices, and it expects most organizations to benefit. The caution about documentation, however, suggests that the company recognizes the operational nuances — particularly around baseline reboots and fallback — are not trivial.
What to do now
If your organization uses Windows Autopatch, start preparing today. Here’s a step‑by‑step action plan:
-
Audit your device fleet
Use Intune reports or Microsoft Graph to identify which Windows 11 devices have VBS enabled and meet the other eligibility criteria. Tag those devices for hotpatch readiness, and note which are ineligible. -
Review your update ring configurations
In Autopatch, check whether your ring deadlines and deferral periods still make sense when reboots will only occur quarterly. Adjust ring soak times if needed to catch any baseline‑related issues early. -
Document your fallback process
Decide exactly what happens when a hotpatch falls back to a reboot‑ful update. Will the device install it automatically during the next maintenance window? Who gets notified? How are users warned? Write this down; Microsoft’s advisory makes it clear that undocumented fallback handling is a reason to block hotpatch. -
Test in a pilot ring
Before May 2026, create a small test group of eligible devices and opt them into hotpatch (you can flip the Allow policy early) to observe baseline reboots, user experience, and any compatibility issues. -
Set the policy explicitly
By May 2026, if you aren’t ready, override the default by setting the Allow/Block Hotpatch policy to Block. This can be done through an Intune configuration profile targeting Autopatch devices. The exact CSP setting is likely ./Device/Vendor/MSFT/Policy/Config/Update/AllowHotpatch (you’ll want to confirm the official OMA‑URI when Microsoft publishes the final documentation). -
Communicate the change
Even if you choose to allow hotpatch, users need to know that reboots will become rarer but not disappear entirely. Prepare a brief email or Teams announcement explaining the new rhythm and what to expect.
Outlook
This default change is the strongest signal yet that Microsoft sees hotpatch as the future of Windows servicing. We can expect further expansion — to Windows 10? That’s unlikely given the imminent end of support, but Windows 11 SE or even Windows 365 Cloud PCs are logical next candidates. The baseline interval may shrink over time as the patching technology improves, bringing us closer to truly reboot‑free updates year‑round.
For now, IT teams should treat May 2026 as a hard deadline to get their houses in order. Autopatch is removing a guesswork toggle and making a bet that hotpatch is ready for the mainstream. Whether your organization is ready depends on the documentation you write today.