Starting with the May 2026 Windows security update, Microsoft has switched hotpatch on by default for every eligible device enrolled in Windows Autopatch. This is not a preview. It is not opt-in. If your devices meet the eligibility requirements, they are now receiving hotpatch updates — and if your organisation is not ready for that, you have a narrow window to act before the next Patch Tuesday.
This post covers exactly what hotpatch is, how the update cycle works, which devices qualify, and — critically — how to opt out at the tenant level or per policy group if you need more time to test. There is also a note on Arm64 that every endpoint engineer with a mixed fleet needs to read before assuming all devices are covered.
What hotpatch actually is
Hotpatch is a patching mechanism that installs security fixes directly into the running OS — without requiring a device restart. The update is applied to in-memory code, so the change takes effect immediately, while the device keeps running and the user keeps working.
This is materially different from a standard cumulative update. A standard update replaces files on disk, queues a restart, and only becomes effective after the device has rebooted and loaded the new binaries. Hotpatch skips that cycle entirely for supported security patches.
The practical results Microsoft report for organisations using hotpatch at scale:
- 90% patch compliance reached in half the time compared to standard cumulative updates
- Smaller update packages — hotpatch payloads are significantly smaller than full cumulative updates, reducing bandwidth consumption and install time
- Fewer required restarts — in a standard four-month hotpatch cycle, only one restart per quarter is required (for the baseline update), rather than one per month
How the hotpatch update cycle works
Hotpatch does not replace cumulative updates entirely — it operates on a four-month repeating cycle that alternates between baseline months and hotpatch months.
| Month type | What happens | Restart required? | Months per year |
|---|---|---|---|
| Baseline month | Standard cumulative update is installed; this becomes the new baseline that subsequent hotpatches build on | Yes | 4 |
| Hotpatch month | Security fixes are applied on top of the current baseline directly into the running OS — no new baseline, no restart | No | 8 (two per quarter) |
The result is one restart per quarter instead of one per month for eligible devices. Hotpatch months always patch on top of the most recent baseline, so the security coverage is equivalent — the delivery mechanism is just radically different.
Eligibility — which devices qualify
Hotpatch is not available to every device in your Autopatch estate. All of the following conditions must be met simultaneously. A device that fails any single requirement falls back to the standard cumulative update path and is not affected by the default-on change.
| Requirement | Detail | Notes |
|---|---|---|
| Windows 11, version 24H2 | Build 26100.2033 or later | Windows 10 and Windows 11 pre-24H2 are not eligible |
| x64 CPU | AMD64 or Intel 64-bit processor | Arm64 is not supported — see Arm64 note below |
| Microsoft Intune management | Device must be managed via Intune | Co-managed devices may have additional considerations |
| Virtualization-based Security (VBS) | VBS must be enabled on the device | Devices with VBS disabled will not receive hotpatch |
| Windows Autopatch quality update policy | Device must be enrolled in a Windows Autopatch quality update policy | The default-on change applies at the policy level |
Devices that do not meet all requirements receive the standard cumulative update on the normal schedule. They are unaffected by this change and require no action on your part.
How to check if your devices are receiving hotpatch
How to opt out — if you are not ready
There are two opt-out levels: tenant-wide and per-policy. Both are available through the Intune admin centre. You do not need to contact Microsoft support to opt out.
Arm64 devices — read this before assuming coverage
The precise caveat from Microsoft: Arm64 devices must disable CHPE to be eligible for hotpatch. CHPE is the mechanism that enables Arm64 devices to run x64 applications with improved performance through binary translation. Disabling it degrades application compatibility and performance on those devices, making it an impractical requirement for most organisations.
What this means in practice: If your fleet is mixed — x64 laptops and Arm64 Surface devices — only the x64 devices will receive hotpatch. Your Arm64 devices will continue to receive standard cumulative updates with monthly restarts. This is transparent to end users and requires no configuration change, but it does mean your hotpatch compliance metrics will only reflect part of your estate.
Should you leave hotpatch on?
For most organisations, the answer is yes — but with a structured pilot first rather than accepting the default blindly across the entire tenant.
The case for keeping hotpatch enabled:
- Compliance velocity is significantly better. Reaching 90% patch compliance in half the time is a meaningful security improvement, particularly for environments with distributed workforces or users who historically defer restart prompts.
- Operational disruption is reduced. Fewer forced restarts means fewer calls to the service desk, fewer interrupted sessions, and less end-user friction around Patch Tuesday.
- The update coverage is equivalent. Hotpatch security content covers the same CVEs as the standard cumulative update for supported months. You are not accepting a lower level of security coverage in exchange for fewer restarts.
- Bandwidth consumption is lower. Smaller payloads are a genuine operational benefit for distributed offices, home workers, and metered connections.
Reasons to pilot before fully committing:
- Line-of-business application compatibility. Although hotpatch applies updates without a restart, some applications that hook into the OS at a low level or rely on specific kernel state may behave differently. Run a validation pass against your critical applications on a pilot ring before broad rollout.
- VDI and shared device environments. Non-persistent VDI images may need specific consideration — hotpatch behaviour in multi-session Windows or pooled desktop scenarios should be validated against your specific stack.
- Change management requirements. Some organisations have change advisory board processes that require any deviation from the standard update mechanism to go through a change request. Confirm whether hotpatch-by-default constitutes a change that needs to be formally approved in your environment.
Official Microsoft references
- Windows Autopatch hotpatch updates — primary documentation covering hotpatch behaviour, eligibility, the update cycle, and how hotpatch interacts with the Autopatch service
- Configure hotpatch for Windows quality updates in Intune — step-by-step guidance for configuring hotpatch in the Intune admin centre, including the tenant-level and policy-level settings
- What's new in Microsoft Intune — release notes covering the hotpatch-by-default change and other recent Intune updates
- Windows Autopatch overview — overview of the Windows Autopatch service, including eligibility requirements and what the service manages