On May 11, 2026, Windows Autopatch began enabling hotpatch security updates by default across every eligible Intune device that was not already covered by an explicit Windows quality-update policy. The first hotpatch delivered under the new default — KB5089466, released on May 12, 2026 — installed on Windows 11 Enterprise 24H2 and 25H2 fleets without a restart. The change had been announced two months earlier through Message Center post MC1248388 and a Windows IT Pro blog post titled Securing devices faster with hotpatch updates on by default, both dated March 10, 2026. The tenant opt-out toggle became available on April 1, 2026; the runway closed on May 11.
This article documents what changed, how the hotpatch mechanism operates, which devices qualify, how the tenant default interacts with existing quality-update policies, and what to verify on an estate that has just crossed the threshold.
What the Default Switch Actually Does
Before May 2026, hotpatch updates were opt-in. An administrator had to create a Windows quality-update policy in Intune, set the toggle When available, apply without restarting the device ('Hotpatch') to Allow, and target it at the device or user groups intended to receive hotpatches.
After May 2026, the same opt-in path still exists. The change is narrower than it first appears: the tenant-level default is now Allow for every device that is not already assigned to a quality-update policy. A device with an explicit policy — whether the policy is set to Allow or Block — continues to follow that policy. Devices without any policy assignment, which previously received the Latest Cumulative Update (LCU) regardless of hotpatch eligibility, now receive hotpatches automatically if they meet the prerequisites.
The mechanism is described unambiguously in the Microsoft documentation and confirmed in Anoop C. Nair's HTMD walk-through: "the default tenant setting is only applied to devices that aren't members of a quality update policy. If a device is assigned to one of those policies, the hotpatch setting from that policy is the one applied." In practice this means a brownfield Autopatch tenant with established ring structures sees minimal direct impact on devices governed by those rings, while a greenfield tenant or any tenant with un-policy-assigned devices sees the default flip on the first eligible patch cycle.
The Microsoft rationale for the change rests on a single number. The Tech Community announcement claims that hotpatch can take an organisation to 90 percent compliance in half the time of traditional restart-dependent updates. Microsoft also discloses that over ten million production devices were enrolled in hotpatch ahead of the default switch.
The Hotpatch Mechanism in One Page
Hotpatch is an extension of Windows Update that installs Monthly B-release security fixes without triggering a device restart. The mechanism is built on a quarterly cadence:
| Quarter | Baseline month (restart required) | Hotpatch months (no restart) |
|---|---|---|
| Q1 | January | February, March |
| Q2 | April | May, June |
| Q3 | July | August, September |
| Q4 | October | November, December |
A baseline release is a standard cumulative update that contains both the security fixes and the underlying servicing payload required by subsequent hotpatches in the same quarter. Without the baseline installed, a device is offered the regular LCU rather than the hotpatch. This is the reason the April 14, 2026 baseline KB5083769 is a hard prerequisite for the May hotpatch and for the broader default switch. A device that missed the April baseline simply receives the May LCU and a regular restart.
Hotpatches deliver only security content. Feature updates, non-security improvements, and preview-channel deliveries are out of scope. Microsoft Server roles and Windows 365 Cloud PCs follow parallel hotpatch schedules; the same quarterly grid applies, with the difference that Windows Server uses Azure Update Manager rather than Autopatch.
Prerequisites: Licence, OS, VBS, and CHPE
A device qualifies for hotpatch — and therefore for the new default — only if four conditions hold. The first three are documented in Microsoft Learn's Hotpatch updates article. The fourth applies only to Arm64 hardware.
Licence eligibility
Hotpatch requires one of the following licences on the device:
- Windows 11 Enterprise E3 or E5
- Windows 11 Education A3 or A5
- Microsoft 365 F3
- Microsoft 365 Business Premium
- Windows 365 Enterprise
Devices on Pro or Home SKUs are ineligible and continue to receive the LCU. Hotpatch is not currently supported in GCC High, DoD, or the 21Vianet sovereign cloud in China. Standard GCC tenants must activate the Windows Enterprise entitlement via the zero-cost Windows Enterprise (OLS) activation SKU before Autopatch — and therefore hotpatch — becomes available.
Operating system version
The device must run Windows 11 version 24H2 or later. The current release notes cover hotpatch on Windows 11 Enterprise 24H2 and hotpatch on Windows 11 Enterprise 25H2. The minimum build for the May 2026 cycle is 26100.4929 (24H2) or the corresponding 25H2 build family in the 26200 series.
Virtualisation-based Security (VBS)
VBS must be turned on for the hotpatch installer to function. This is a hard requirement, not a recommendation. The VirtualizationBasedTechnology CSP is the supported method to push it; an alert named Hotpatch – VBS not running surfaces in Autopatch when the precondition fails. The Microsoft 365 Message Center post explicitly flags VBS-on-x86 as the most common gap that disqualifies a device.
Verification on a single host:
# Reads the device's current VBS state from Win32_DeviceGuard
Get-CimInstance -ClassName Win32_DeviceGuard `
-Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus, `
SecurityServicesRunning, `
RequiredSecurityPropertiesA VirtualizationBasedSecurityStatus value of 2 indicates Running; 1 indicates Enabled but not running; 0 indicates Disabled. Only 2 qualifies the device for hotpatch.
Arm64 only: CHPE disabled
On Arm64 devices, Compiled Hybrid PE (CHPE) binaries — used to accelerate 32-bit x86 applications under emulation — are incompatible with the hotpatch installer. The installer cannot service CHPE OS binaries in %SystemRoot%\SyChpe32. Microsoft is explicit in the official documentation: "There are no plans to support hotpatch updates on Arm64 devices with CHPE enabled."
The remediation is to set the DisableCHPE policy through the DisableCHPE CSP, or to write the registry directly and restart the device once:
# Disable CHPE on Arm64 to enable hotpatch eligibility.
# Restart required after setting the value.
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management"
New-ItemProperty -Path $path `
-Name "HotPatchRestrictions" `
-Value 1 `
-PropertyType DWord -ForceA consequence to plan for: any 32-bit x86 Office add-in or VBA Declare-statement code that previously relied on CHPE-accelerated emulation will lose that acceleration. Microsoft has separately announced the end of support for 32-bit Microsoft 365 Apps on Windows Arm-based PCs (security updates end December 2026), which removes the largest remaining CHPE workload over the same horizon.
April 2026 baseline installed
The final precondition for the May default to take effect is that KB5083769 — the April 14, 2026 baseline — is already installed. A device that missed April's baseline is offered the May LCU and follows the standard restart cycle until the next baseline (July 2026) restores hotpatch eligibility for the Q3 window.
What Happens in the Tenant on May 11
The runway closed at 11 May 2026. From the next sync cycle onward, Intune evaluates each device:
- Is the device assigned to a Windows quality-update policy? If yes, the policy setting (Allow or Block) is final. The tenant default is irrelevant.
- If no policy is assigned, is the device eligible (licence, OS version, VBS on, CHPE off on Arm64, April baseline installed)? If yes, the device receives the May hotpatch automatically. If no, it receives the May LCU.
The first hotpatch under the new default is KB5089466 — May 12, 2026 Hotpatch (OS Builds 26200.8390 and 26100.8390). The release notes are sparse — Microsoft reports two non-security improvements: a reliability fix for Simple Service Discovery Protocol notifications, and a rendering fix in the Remote Desktop Connection security warning dialog on multi-monitor setups with different scaling settings. The corresponding Servicing Stack Update is KB5092762. No known issues are documented at the time of writing.
The Opt-Out Path
For tenants that want to retain the pre-May behaviour, two opt-out levels are available.
Tenant-level opt-out
The path in the Intune admin center is:
Tenant administration → Windows Autopatch → Tenant management → Tenant settingsThe relevant toggle is When available, apply updates without restarting the device ('hotpatch'). Setting it to Block restores the pre-May behaviour for every device that is not assigned to a quality-update policy. Devices that are assigned to a policy continue to follow that policy regardless of the tenant default.
This is the broadest control and the appropriate choice for an organisation that wants to study hotpatch in a pilot before adopting it across the estate.
Policy-level opt-out
The path is:
Devices → Manage updates → Windows updates → Quality updates → Create →
Windows quality update policyIn the Settings step, the toggle When available, apply without restarting the device ('Hotpatch') governs the policy. Setting it to Block and assigning the policy to the target group disables hotpatch for those devices specifically. This is the appropriate control for a brownfield estate that wants to exempt a single critical workload — for example a virtualised desktop pool that depends on a specific OS image rev — while letting the rest of the fleet inherit the default.
The documentation is explicit that policy assignment wins over the tenant default. Both controls can coexist: a tenant-level Block can be combined with policy-level Allow for specific device groups to invert the default for a subset of the estate.
Verifying Enrolment on a Device
After May 11, an administrator can confirm hotpatch enrolment on a specific device by checking the Configured update policies surface in Settings or by reading the underlying telemetry directly.
Settings → Windows Update → Advanced options
Start → Settings → Windows Update → Advanced options →
Configured update policies → Enable hotpatching when availableThis entry indicates that the device is enrolled in hotpatch updates via Autopatch.
Event Viewer
The hotpatch monitor service writes events to the Windows Application log. Filtering by the string hotpatch returns the relevant entries. A separate event named AllowRebootlessUpdates confirms the orchestrator state. The Microsoft documentation gives the diagnostic payload to expect:
"data": { "payload": "{\"Orchestrator\":{\"UpdatePolicy\":
{\"Update/AllowRebootlessUpdates\":true}}}",
"isEnrolled": 1, "isCached": 1, "vbsState": 2,A vbsState of 2 confirms VBS is running. An isEnrolled value of 1 confirms the device is enrolled in the Autopatch update policy. A monitor-detected critical error during hotpatch application causes the device to install the standard LCU instead, ensuring the device remains fully secure even when hotpatch fails.
Hotpatch quality updates report
In the Intune admin center, the report at Home → Reports → Windows Quality Updates → Summary → Hotpatch quality updates report enumerates per-policy device counts and current update statuses. It is the recommended view for verifying whether the May default is taking effect at the expected rate across the fleet.
Rollback
Hotpatch updates cannot be automatically rolled back. An administrator who experiences an unexpected issue with a hotpatch can uninstall it through the standard update history surface, install the corresponding LCU, and restart the device. The Microsoft documentation is explicit: the uninstall itself is quick, but a restart is required to complete the rollback. The same restart caveat applies to upgrades — upgrading a hotpatch-enrolled device from 24H2 to 25H2 during a baseline month keeps the device on the hotpatch cycle without disruption; upgrading during a hotpatch month switches the device temporarily to standard updates and requires a restart until the next baseline release.
What to Consider Before Letting the Default Take Effect
Three considerations deserve explicit thought.
Patch quality history. The hotpatch installer modifies running code in memory through a process Microsoft refers to as live binary servicing. The mechanism has been in production for over a year on more than ten million devices, and the public release-notes history for the 24H2 and 25H2 channels is short and uneventful. The cautious posture nonetheless argues for piloting hotpatch in a small ring before letting the tenant default flip the broader estate. The Register's coverage of the default switch raises this point and characterises a less-than-two-month runway as compressed.
Compliance reporting on third-party platforms. Several third-party compliance and vulnerability-management tools detect successful patching by observing the post-restart event sequence, not by querying the hotpatch installation state directly. An estate that depends on such a tool to attest patch compliance should verify how the tool reports a hotpatched device. The compliance database may need a vendor-side update before hotpatch installations are counted correctly.
Ring strategy alignment. The hotpatch toggle interacts with — but does not replace — the existing ring deferral configuration. A common pattern is to run hotpatch with a short deferral on test rings and a longer deferral on production rings. The default switch does not change this; what it changes is the floor for devices outside the ring structure. An audit of which devices are not assigned to any quality-update policy is the most direct way to scope the actual blast radius of the May default.
Recommendation
For tenants with mature ring structures: the May default is mostly cosmetic. Every device under an explicit quality-update policy continues to follow that policy. The right action is an audit of policy coverage to confirm there are no orphan devices receiving hotpatches unexpectedly, followed by no further change.
For tenants without comprehensive policy coverage: the May default takes effect on every eligible orphan device on the next sync cycle. If hotpatch is desirable across the fleet, no action is required. If hotpatch is to be staged, the tenant-level opt-out should be set to Block before the next monthly cycle and a quality-update policy should be created to deliberately re-enable hotpatch on a controlled pilot group.
For tenants in regulated environments with stringent attestation requirements: the third-party compliance check is the gating concern. The opt-out path remains available indefinitely; postponing hotpatch adoption to align the compliance-reporting chain is a defensible position.
Rule of thumb: The default switch on May 11, 2026 changed the floor, not the ceiling. Existing quality-update policies remain authoritative; the new behaviour applies only to the gap between policy-governed and eligible. Audit the gap, decide the default for it, and let the established ring structure continue to govern the rest.
Sources: Microsoft Tech Community — Securing devices faster with hotpatch updates on by default, Microsoft Message Center MC1248388 (mirror), Microsoft Learn — Hotpatch updates, Microsoft Support — KB5089466 May 12, 2026 Hotpatch, Microsoft Support — April 14, 2026 Baseline KB5083769, Microsoft Support — Release notes for Hotpatch on Windows 11 Enterprise 24H2, Microsoft Support — Release notes for Hotpatch on Windows 11 Enterprise 25H2, Anoop C. Nair / HTMD — Hotpatch Updates Become Default, Bleeping Computer — Microsoft to enable Windows hotpatch security updates by default, The Register — Hotpatching goes default in Windows Autopatch, Help Net Security — Microsoft flips Windows Autopatch to default hotpatch security updates. The two Microsoft Tech Community blog posts were not directly extractable through automated fetch at the time of writing; their content has been cross-validated against the Message Center post, the Microsoft Learn documentation, and the four sources above. All version, build, KB number, registry-path, CSP-name, and date references verified against the Microsoft Learn and Microsoft Support articles linked above as of 2026-05-23.