Windows Autopatch Enables Hotpatch by Default in May 2026: What IT Teams Must Do

  • Thread Author
Microsoft is flipping a default switch in Windows Autopatch that will make hotpatch security updates the standard behavior for eligible devices — a change that promises dramatically faster compliance but also requires IT teams to make explicit readiness decisions before the May 2026 security update arrives.

Background / Overview​

Microsoft announced in March 2026 that Windows Autopatch will enable hotpatch updates by default for all eligible devices managed through Microsoft Intune or the Windows updates API (Microsoft Graph) starting with the May 2026 security update. One month prior — beginning April 1, 2026 — tenant-level controls will be available to opt out if you are not ready; administrators have until May 11, 2026 before hotpatch deployments begin against the new default.
Hotpatch is a rebootless patching capability for qualifying Monthly B security updates. Instead of waiting for a device restart to complete installation and reach compliance, hotpatch updates take effect immediately after installation, removing the restart bottleneck that historically delays security coverage. Microsoft’s announcement pairs that operational benefit with concrete policy controls: tenant defaults, per-policy overrides via Intune quality update policies, and reports to help identify which devices are hotpatch-ready.
This change is a meaningful step in reducing risk exposure time for enterprise fleets — but it’s not automatic for every device, and it introduces operational tradeoffs that security and device management teams must weigh carefully.

Why hotpatch matters: the security and compliance argument​

Hotpatch changes one of the longest-standing friction points in Windows patching: the restart requirement.
  • Traditionally, critical monthly security fixes install but do not make a device fully compliant until the system is restarted. Many organizations defer restarts for 3–5 days to avoid productivity disruption.
  • Hotpatch eliminates that waiting period for eligible security updates: updates take effect as soon as they finish installing, with no restart required.
  • Microsoft shared operational telemetry showing that several organizations reached 90% patch compliance in roughly half the time after adopting hotpatch, without changing existing deployment policies. That kind of acceleration matters for mitigation of rapidly exploited vulnerabilities.
Benefits in plain terms:
  • Faster reduction of exposure windows after a patch is published.
  • Smaller, quicker downloads for hotpatch payloads because hotpatches are built incrementally on the latest baseline.
  • Reduced user disruption and fewer forced maintenance windows.
Taken together, those advantages explain why Microsoft is moving to a default-enabled posture for eligible devices: the security case is compelling for organizations that can meet prerequisites and accept the operational tradeoffs.

What is changing, exactly — and when​

Microsoft’s rollout is simple in concept but nuanced in practice.
  • Effective date for the default change: hotpatch updates will be enabled by default for eligible devices starting with the May 2026 Windows security update.
  • Tenant opt-out control availability: April 1, 2026 — administrators can change the default hotpatch behavior for their tenant in Microsoft Intune.
  • Deadline before deployments begin: Microsoft states organizations have until May 11, 2026 before any hotpatch updates are deployed under the new default.
  • Policy precedence: if a device is assigned to a quality update policy in Intune, the hotpatch setting defined in that policy overrides the tenant default. That means you can opt out at the tenant level but allow hotpatch for specific groups—or the inverse.
Operational nuance to understand:
  • Hotpatches apply only to devices that meet the hotpatch prerequisites (see next section).
  • If a device is enrolled for hotpatch but is not yet on the current baseline release, Windows Autopatch will first install the latest baseline (which does require a restart). After that baseline is installed and the device restarts, subsequent hotpatch updates will be installed without restarting going forward.
  • Hotpatch is an extension of Windows Update and is orchestrated through Windows Autopatch and Intune quality update policies.

Prerequisites and limitations: what makes a device eligible​

Hotpatch is not universal; devices must satisfy a list of configuration and licensing requirements before they’ll be offered hotpatch updates.
Key prerequisites and constraints:
  • Operating system: Windows 11 (and Windows Server with specific Azure/Automanage scenarios) on supported versions — typically Windows 11 version 24H2 or later for client hotpatching.
  • Baseline status: devices must be on the latest baseline release (quarterly cumulative baseline) to qualify. If they are not, the baseline will be installed first and a restart will be required.
  • Virtualization-based Security (VBS): VBS must be enabled on the device for hotpatch to be offered. This is a firm requirement for hotpatch installer functionality.
  • Licensing: eligible licenses are required (for example, certain Enterprise and education SKUs and specific Microsoft 365 bundles). Confirm your licenses before assuming eligibility.
  • Management: Microsoft Intune management with a Windows quality update policy and Windows Autopatch enrollment is required for orchestrated hotpatch deployments.
  • ARM64 caveat: Arm64 devices require an additional registry change to disable CHPE (Compiled Hybrid Portable Executable) usage before hotpatching; Arm64 support is treated specially and may be in preview for certain scenarios.
  • Not all update types are hotpatchable: hotpatch applies to specified security updates (Monthly B releases) and does not replace the quarterly baseline cumulative updates that still require restarts. Some patches may still require restarts for security or functional reasons even during hotpatch months.
Practical implication: you can’t simply toggle a tenant setting and expect every machine to become hotpatch-enabled overnight. The device fleet must be configured and on the correct baseline.

How to check readiness and target hotpatch safely​

Microsoft provides reporting and tooling in Intune to help identify which devices are hotpatch-ready and which will actually receive hotpatch updates.
Where to look:
  • The Hotpatch quality updates report in Intune shows which devices meet prerequisites, which have hotpatch enabled, and which were successfully hotpatched.
  • The Quality update status report gains new columns such as Hotpatch Readiness and Hotpatch enabled, helping you track per-device status.
  • Use Windows Autopatch update readiness tools to verify enrollment and eligibility before the May 2026 hotpatch release.
Suggested validation steps (recommended):
  • Inventory: list all devices by OS version, VBS status, baseline version, and management status.
  • Pilot group: choose a modest pilot (hundreds to low thousands depending on org size) that represents a cross-section of hardware, line-of-business apps, and user activity patterns.
  • Simulate worst-case: test hotpatch rollback and LCU fallback procedures in lab or pilot devices so you can quickly respond if an update behaves unexpectedly.
  • Monitor: add hotpatch readiness and hotpatch quality reports to your routine monitoring dashboards.

How to opt out: tenant and policy controls​

Microsoft gives clear ways to prevent hotpatch from being applied by default across your tenant or to specific device groups.
Opt out across the tenant (available starting April 1, 2026):
  • Open Microsoft Intune.
  • Navigate to Tenant administration > Windows Autopatch > Tenant management.
  • Select the Tenant settings tab.
  • Toggle the setting labeled When available, apply updates without restarting the device ("hotpatch") to Block.
Opt out for groups of devices (policy-level control — overrides tenant default):
  • In Microsoft Intune go to Devices > Manage updates > Windows updates.
  • Choose the Quality updates tab and select Create.
  • Pick Windows quality update policy and complete the Basics tab.
  • On the Settings tab toggle When available, apply without restarting the device ("hotpatch") to Block or Allow as desired.
  • Assign the policy to Microsoft Entra groups representing the targeted devices.
Important policy precedence rules:
  • A device assigned to a quality update policy uses that policy’s hotpatch setting; policy-level intention always takes precedence over tenant default.
  • You can mix approaches: block the tenant by default but enable hotpatch for carefully chosen groups, or enable tenant default and block specific groups that require restarts for operational reasons.

Risks, operational tradeoffs, and real-world signals​

There are several practical tradeoffs and operational risks to evaluate before enabling hotpatch broadly.
  • Visibility and reboot-based health checks
  • Many IT teams rely on regular restarts to flush transient issues, trigger firmware initialization, and reduce some classes of support tickets. Fewer restarts might hide issues until a later baseline install or manual restart surfaces them.
  • Some service desks have reported that fewer restarts correlate with increased user tickets for problems that would otherwise have been implicitly resolved by a reboot.
  • Uncommon but possible non-hotpatch updates
  • Microsoft’s model still requires baseline (quarterly) updates that necessitate restarts. On rare occasions, Microsoft may ship a non-hotpatch update during a hotpatch month that will require a reboot. Your change-control procedures must account for those exceptions.
  • Rollback and troubleshooting
  • Automatic rollback of a hotpatch update is not supported; if a hotpatch causes issues, you must uninstall the hotpatch and install the latest standard cumulative update (LCU) and perform a restart. That makes testing and rollback plans essential.
  • Compatibility with third-party tooling
  • Third-party patch management and inventory tools may need updates to detect hotpatch states correctly. Some organizations have reported false positives in scanners or reconciliation discrepancies that required vendor updates or custom detection logic.
  • Claims and adoption metrics — treat with caution
  • Microsoft’s announcement cites adoption metrics (for example, a statement of “over 10 million production devices enrolled in hotpatch updates”). While this signals strong uptake, independent reports and earlier Microsoft communications showed lower published figures in prior months. Treat vendor adoption numbers as directional rather than absolute, and validate assumptions against your own telemetry.
  • Application and driver updates
  • Hotpatch addresses specific security updates; it does not cover all update categories (e.g., driver updates or many.NET/runtime updates often still need a restart). Plan your maintenance windows accordingly.

Recommended rollout plan and checklist for IT teams​

If you decide to embrace hotpatch, follow a controlled and documented approach. If you decide to delay, use the tenant setting to block and enable hotpatch only for tightly controlled pilots.
Phase 1 — Preparation
  • Confirm licensing and OS versions for all endpoints.
  • Inventory VBS status and configure VBS at scale where required.
  • Verify baseline versions; schedule baseline installs for devices not on the latest baseline well before May 2026 to avoid unexpected reboots during baseline rollout.
  • Identify and prepare pilot device groups (diverse hardware, critical LOB apps).
Phase 2 — Pilot
  • Create a quality update policy with hotpatch Allow and scope to pilot groups.
  • Use Hotpatch quality updates report and Quality update status report to track Hotpatch readiness, Hotpatch enabled, and Hotpatched columns.
  • Test application compatibility, telemetry, user experience, and helpdesk workflows for the pilot.
  • Document rollback procedures and rehearse them in a lab environment.
Phase 3 — Staged expansion
  • Expand to additional rings after successful pilots, maintaining policy-level controls and monitoring.
  • Apply a staged cadence: pilot → small production ring → broad production.
  • Keep an eye on the release calendar and ensure devices are on the required baseline before entering broader hotpatch phases.
Phase 4 — Full adoption or mixed policy
  • Either switch tenant default to Allow (if you previously opted out) or keep tenant default Block and rely on quality update policies to permit hotpatch only where appropriate.
  • Maintain dashboards and automated alerts for hotpatch-relevant signals, including VBS status, CHPE flags on Arm64, and hotpatch deployment failures.
Checklist (actionable items)
  • [ ] Confirm Windows 11 version 24H2 or later for candidate devices.
  • [ ] Enable Virtualization-based Security (VBS) where required and confirm via inventory.
  • [ ] Ensure required licenses are in place for target devices.
  • [ ] Verify Intune enrollment and Windows Autopatch registration for groups.
  • [ ] Schedule baseline update installs for out-of-date devices before May 2026.
  • [ ] Create a pilot quality update policy in Intune and scope to pilot groups.
  • [ ] Add Hotpatch quality updates report to your monitoring suite.

Tactical examples: commands and UI paths (what to click)​

Microsoft’s UI steps are the authoritative path for tenant- and policy-level control. Summary of the Intune navigation described by Microsoft:
Tenant-level toggle (available April 1, 2026):
  • Microsoft Intune → Tenant administration → Windows Autopatch → Tenant management → Tenant settings.
  • Toggle When available, apply updates without restarting the device ("hotpatch") to Allow or Block.
Policy-level (quality update policy):
  • Microsoft Intune → Devices → Manage updates → Windows updates → Quality updates → Create → Windows quality update policy.
  • In Settings set When available, apply without restarting the device ("hotpatch") to Allow or Block.
  • Assign to Microsoft Entra groups and create.
Note: If a device is not hotpatch-eligible it will fall back to receiving the Latest Cumulative Update (LCU), which requires a restart. That behavior preserves security coverage when prerequisites are not met.

What to watch for after enabling hotpatch​

Operational monitoring topics:
  • Hotpatch deployment success/failure rates by policy and device model.
  • Rate of unexpected user incidents or helpdesk tickets that correlate with hotpatch installations.
  • Third-party scanner and inventory tool reports — reconcile them with Intune hotpatch reporting to avoid blind spots.
  • Baseline deployment schedule adherence — ensure your baseline installs are completed before hotpatch months.
  • Exceptions where Microsoft ships a non-hotpatch fix in a hotpatch month.
Communication and change management:
  • Update service desk runbooks to reflect new troubleshooting and rollback steps for hotpatches.
  • Notify stakeholders of the change in restart cadence and rationale: fewer restarts, faster compliance, but new operational implications.
  • Provide end-user guidance where necessary (for example, when a baseline restart will be required).

Final assessment — strengths and cautionary notes​

Strengths
  • Security-first: hotpatch meaningfully shortens time-to-compliance on eligible security fixes, which is a clear win in the face of fast-moving exploit campaigns.
  • User experience: Reduced forced restarts improve end-user productivity and reduce friction for always-on work modes.
  • Operational efficiency: Smaller, incremental hotpatch payloads lower bandwidth and reduce installation time for qualifying fixes.
Caveats and risks
  • Eligibility constraints: Not all devices qualify — VBS, baseline status, licensing, and management are gating factors that must be addressed beforehand.
  • Hidden issues: Fewer restarts can delay the surfacing of intermittent hardware/firmware/software issues that reboots would normally reveal.
  • Rollback friction: No automatic rollback for hotpatches means your remediation playbook needs to be practiced and reliable.
  • Tooling gaps and third-party impacts: Some third-party scanning and recon tools may require updates to correctly detect hotpatch states and compliance.
  • Vendor claims warrant scrutiny: Adoption or effectiveness figures published by vendors are directional; validate against your own telemetry and pilot results.

Bottom line — what IT leaders should do this month​

  • Treat April 1, 2026 as your decision point: if you need more time, plan to set the tenant-level hotpatch toggle to Block as soon as the control appears.
  • Immediately inventory and remediate prerequisites: VBS enablement, OS baseline status, Intune enrollment, and licensing.
  • Spin up a representative pilot and validate hotpatch behavior against your most important line-of-business apps and hardware classes.
  • Update runbooks, monitoring, and helpdesk procedures to handle hotpatch-specific troubleshooting and rollback.
  • Use policy-level overrides to adopt a mixed strategy: enable hotpatch for low-risk groups and keep critical or restart-sensitive workloads on a Block policy until you are confident.
Hotpatch defaults are a meaningful step toward faster, lower-friction security patching. For organizations that can meet the prerequisites and who have practiced recovery steps, the default change will reduce exposure time and improve compliance velocity. For teams that rely on restart-based maintenance workflows or have heavy driver/firmware/update dependencies, a cautious, policy-driven rollout is the safer path — and Microsoft has provided the tenant and policy controls to support exactly that approach.
Conclusion
The move to enable hotpatch by default signals a firm push toward restartless security patching as a mainstream option for enterprise Windows fleets. It lowers the time to secure for many environments and aligns with modern expectations for continuous, low-impact maintenance. But it also shifts responsibilities: validating prerequisites, expanding monitoring, and refining rollback procedures become central operational tasks. Use the April opt-out window wisely, validate with a pilot, and then expand deliberately — that will let you capture the security benefits of hotpatch while keeping costs and risks controlled.
Source: Microsoft - Message Center Securing devices faster with hotpatch updates on by default - Windows IT Pro Blog
 
Click to expand...
Microsoft’s decision to flip the default for hotpatch security updates in Windows Autopatch is a subtle configuration change with outsized operational consequences: starting in May 2026, eligible Windows devices managed through Microsoft Intune (and the Microsoft Graph API) will receive hotpatch security updates by default unless an administrator explicitly opts out, and tenant-level controls to block the behavior become available on April 1, 2026 with a deployment grace period through May 11, 2026.

Background / Overview​

Hotpatching is Microsoft’s rebootless update capability for qualifying Windows security updates. Instead of installing a patch and waiting for a restart to activate it, a hotpatch applies targeted binary fixes in memory so protections take effect immediately after installation. Microsoft has been rolling hotpatch support into Windows Autopatch and Intune policies since the feature moved beyond preview, and the company now says that enabling hotpatch by default will cut time-to-compliance metrics dramatically for eligible fleets.
This change is targeted and conditional: it applies only to devices that meet hotpatch prerequisites (correct baseline, supported Windows build and SKU, virtualization-based security enabled, and Intune/Autopatch management). It is not an across-the-board “force restartless updates for every Windows PC” move; unmanaged consumer PCs and many older systems will continue to follow the traditional restart-based update workflow.

What Microsoft is changing and when​

Key dates and the administrative window​

  • April 1, 2026 — Tenant-level controls to block or allow hotpatch at the organization level become available in Microsoft Intune.
  • May 2026 — Microsoft will begin enabling hotpatch updates by default for eligible devices with the May 2026 Windows security update rollout.
  • May 11, 2026 — Microsoft’s published timeline gives administrators until this date before hotpatch deployments begin under the new default, allowing a short review and opt-out period.
These exact dates matter because April is also a quarterly baseline month. Devices must install the April baseline and restart to become eligible for subsequent hotpatches; the timeline therefore gives IT teams a clear sequence to validate baseline installation and readiness before hotpatches are delivered.

Which devices are affected​

This default flip affects devices that:
  • Are managed through Microsoft Intune or the Windows updates API (Microsoft Graph) and participate in Windows Autopatch.
  • Meet hotpatch prerequisites such as being on a supported Windows client version and on the required baseline release.
  • Have Virtualization‑Based Security (VBS) enabled (VBS is a hard prerequisite for client hotpatching in most supported scenarios).
  • Have eligible licensing and enrollment (enterprise/education SKUs and appropriate Microsoft 365/Windows licenses as required by Autopatch).
If a device is ineligible it will continue receiving the standard Latest Cumulative Update (LCU) that requires a restart. That fallback preserves security coverage even when hotpatch is not supported for a particular endpoint.

How hotpatch works — a concise technical primer​

Hotpatching modifies running Windows binaries in memory so that a security fix becomes effective without an OS restart. The mechanism relies on:
  • Incremental, small security payloads designed for in‑memory patch application.
  • Baseline months where a full LCU is applied (these still require a restart) to prepare the device state for future hotpatches.
  • Device-level prerequisites such as VBS and specific OS build/version combinations to ensure memory integrity and safe patch insertion.
Hotpatch is limited in scope: it targets Monthly “B” security updates that have been structured for hotpatch delivery. Feature updates, large cumulative updates, driver updates, and certain cross-cutting fixes still require reboots. That means hotpatch reduces the number of required restarts across the year but does not eliminate restarts altogether.

Why Microsoft is making hotpatch the default​

Microsoft’s operational argument is straightforward: restart delays are one of the longest bottlenecks between patch availability and organizational compliance. Historically, many organizations used staged restart windows — sometimes waiting 3–5 days or longer before forcing reboots — to avoid disrupting users or critical workloads. Hotpatch removes that waiting window for eligible updates, enabling organizations to reach high patch coverage significantly faster.
Microsoft’s own telemetry (shared with partners and customers) suggests that some organizations reached 90% patch compliance in roughly half the time after adopting hotpatch. The company also reports multi‑million device enrollment numbers in hotpatch-capable services. Those data points underpin the pitch: faster patching reduces the exposure window for zero‑day and quickly exploited vulnerabilities, and fewer restarts reduce user disruption.
Note: those figures and estimates come from Microsoft’s own reporting and should be treated as vendor-sourced data. Organizations should validate expected gains in their own environment as real-world results vary by fleet size, app compatibility, and operational processes.

Practical prerequisites and limitations — what admins must verify​

Before you accept hotpatch as the default for your tenant, validate these technical and operational prerequisites:
  • Operating system and baseline: devices must be on a supported Windows client build and have the current quarterly baseline installed. If they are not, Intune/Autopatch will push the baseline first — this baseline still requires a restart.
  • Virtualization‑Based Security (VBS): VBS must be enabled for hotpatch eligibility. VBS can be blocked by incompatible drivers or older virtualization/antimalware stacks and will need testing before broad enablement.
  • Licensing and enrollment: ensure devices have the required enterprise SKUs and are enrolled in Intune and Windows Autopatch where appropriate.
  • Hardware and architecture caveats: Arm64 devices may have additional steps or configuration changes (for example, CHPE settings) before they’re hotpatch-ready.
  • Update types: not all patches are hotpatchable. Understand the types of updates that will still require restarts and plan maintenance windows accordingly.
Failing to confirm these prerequisites means some devices will receive traditional LCUs with required restarts while others will be hotpatched, increasing heterogeneity and complicating rollout reporting unless monitored closely.

Administrative controls: how to opt out or scope hotpatch​

Microsoft provides multiple layers of control so administrators are not forced into a one-size-fits-all rollout.
  • Tenant-level toggle (available April 1, 2026): In Microsoft Intune under Tenant administration → Windows Autopatch → Tenant management → Tenant settings, you can toggle “When available, apply updates without restarting the device (‘hotpatch’)” to Allow or Block. Changing the tenant default affects newly created Quality Update policies and the default behavior for devices that don’t have explicit policy overrides.
  • Policy-level controls (Quality update policies): Under Devices → Windows updates → Quality updates, create or edit a Windows quality update policy and set the hotpatch option to Allow or Block. Policy settings take precedence over the tenant default, so you can selectively allow hotpatch for pilot groups and block it for sensitive or incompatible devices.
  • Device group scoping: Use Microsoft Entra (Azure AD) groups to assign Quality Update policies to exact device cohorts — pilot groups, production subsets, or vendor-managed devices.
  • Reports and readiness checks: Use the Hotpatch quality updates report and the Quality update status report in Intune to enumerate per-device readiness, hotpatch enabled status, and baseline compliance.
Recommendation: start with a small, representative pilot group, confirm baseline and VBS readiness, validate line-of-business app behavior, and practice your rollback/uninstall and troubleshooting playbook before changing tenant-wide defaults.

Step-by-step checklist for IT teams (recommended runbook)​

  • Inventory and segmentation:
  • Create exports of devices by OS build, VBS status, Intune enrollment, and assigned quality update policy.
  • Baseline validation:
  • Confirm which devices have installed the April 2026 baseline (or the equivalent baseline month), and schedule restarts as necessary.
  • Enable monitoring and reporting:
  • Add Hotpatch readiness and Quality update status reports to dashboards. Monitor Hotpatch Readiness and Hotpatch Enabled columns specifically.
  • Pilot rollout:
  • Configure a Windows quality update policy for a pilot group with hotpatch Allow, and assign a rollback/emergency response runbook.
  • Application compatibility testing:
  • Run representative LOB app suites and drivers against pilot devices. Test for memory corruption, service restarts, and behavior changes when patches apply in memory.
  • Communication:
  • Notify end users and service desks of the pilot and expected behavior changes, emphasizing that restarts will still be required for baseline months.
  • Decide tenant default:
  • After pilot validation, choose tenant-level behavior: Allow by default to accelerate coverage, or Block to retain restart‑centric control and enable hotpatch only for specific groups.
  • Ongoing ops:
  • Maintain a cadence of periodic checks on VBS compatibility, device drivers, and interaction with virtualization or security tooling.

Security benefits: why hotpatch helps​

  • Faster mitigation: hotpatch removes the restart bottleneck, meaning critical mitigations are active immediately and exposure windows shrink.
  • Less user disruption: fewer forced reboots reduce downtime, lowering the risk that users delay or avoid restarts and creating a more predictable user experience.
  • Operational simplicity for large fleets: automated hotpatch via Windows Autopatch scales well for large device fleets where orchestrating mass reboots is costly and error-prone.
  • Reduced attack surface time: in fast-moving exploit scenarios, getting fixes installed and active immediately materially reduces incident probability.
These are strong and defensible security arguments for hotpatch in environments that can meet prerequisites and that prioritize rapid remediation.

Operational risks and real-world tradeoffs​

  • Reduced reboot hygiene: many organizations rely on periodic restarts to clear transient issues, load updated firmware/driver states, and surface latent faults. Fewer restarts can delay or hide underlying problems.
  • Troubleshooting complexity: because hotpatch alters binaries in memory without a restart, troubleshooting may require different diagnostic steps and an explicit plan to uninstall hotpatches and fall back to LCUs plus restarts when needed.
  • Incomplete coverage: devices that fail prerequisites will continue to require restarts for LCUs, creating mixed states across a fleet and complicating compliance reporting if not monitored closely.
  • Driver and AV compatibility: some drivers and older security products assume regular reboots for state changes; enabling VBS and applying hotpatches may expose compatibility issues that need remediation.
  • No automatic rollback: automatic hotpatch rollback is not supported; remediation can require uninstalling the hotpatch and installing the LCU and rebooting — a more manual, involved process in the face of a problematic deployment.
  • Vendor lock-in for management: hotpatch default applies to Intune/Autopatch-managed devices, which reinforces cloud-based device management models; organizations using other management architectures will not benefit and must plan accordingly.
These tradeoffs mean hotpatch is not a universal win for every environment. It’s a powerful tool with clear security upside, but it demands rigorous testing, readiness checks, and operations discipline.

Who should (and should not) enable hotpatch by default​

  • Good candidates for hotpatch by default:
  • Large enterprise fleets that already use Microsoft Intune and Windows Autopatch.
  • Organizations with established VBS enablement and mature driver/AV compatibility testing.
  • Teams seeking faster remediation for high-severity vulnerabilities and that want to minimize user disruption during emergency patching.
  • Poor candidates for immediate tenant-wide enablement:
  • Organizations with significant legacy hardware or specialized devices where VBS is unsupported or breakage risk is high.
  • Small IT teams without capacity to run a measured pilot and validation process.
  • Environments with mission-critical, tightly certified LOB applications where any in-memory patching risk is unacceptable without full vendor validation.
Ultimately, decisions should be risk‑based: pilot, evaluate, and roll out with telemetry rather than toggling global defaults without evidence.

Impact for consumer and unmanaged PCs​

Most consumer and unmanaged Home/Pro PCs will not be directly affected by this tenant-level default flip. Hotpatching by default is a change targeted at devices managed through Intune and Windows Autopatch. Home users and unmanaged Pro machines that receive updates directly from Microsoft’s Windows Update service will continue following existing policies unless other enabling mechanisms are introduced for unmanaged devices.
For personal users the practical takeaway is unchanged: expect restarts for baseline installs and updates unless later Microsoft announcements expand hotpatch coverage to consumer scenarios.

Recommendations for Windows administrators — tactical guidance​

  • Run a readiness inventory now: export device lists with OS build, VBS state, Intune enrollment, and assigned policies. This is the single best early-warning tool.
  • Start a conservative pilot before April 1, 2026: choose a cross-section of device models and LOB apps; confirm rollback and uninstall processes work.
  • Use the April baseline month: ensure your fleet installs and restarts for the baseline so devices will be eligible in May.
  • Prepare change control and communication: update your incident playbooks, support scripts, and end-user messaging to reflect rebootless update behavior and new troubleshooting steps.
  • Maintain a mixed strategy: consider enabling hotpatch for low-risk, high-scale devices while blocking it for specialized endpoints — policy-level scoping gives you this flexibility.
  • Verify backup and recovery: hotpatch does not replace the need for robust backup and rapid recovery; ensure restore points and backups are in place for rapid remediation.

The bigger picture: a shift in update posture​

Microsoft’s default change for hotpatch is a sign that rebootless security updates are becoming mainstream for managed Windows fleets. The move aligns with broader trends in cloud-native management, zero-downtime security, and automation-first operations. For organizations that can adapt, hotpatch promises faster protection and reduced user friction.
However, this is also a reminder that default settings matter. Changing defaults at scale shifts risk profiles and operational expectations. Administrators must treat this as a governance and change-management event, not just a technical toggle. The short April–May 2026 window Microsoft has provided gives teams the chance to validate readiness — treat that window as an opportunity, not an afterthought.

Conclusion​

Microsoft’s decision to enable hotpatch security updates by default for eligible Intune/Autopatch-managed devices starting May 2026 is one of those change-of-default moments that delivers material security benefits — notably faster time-to-compliance and fewer user-disrupting reboots — while also introducing operational and compatibility tradeoffs that cannot be ignored.
For IT teams, the playbook is clear: inventory your environment, validate VBS and baseline compliance, pilot hotpatch with representative devices, and use Intune’s tenant and policy controls to apply a measured rollout. Organizations that plan and test stand to gain meaningful reductions in exposure time and user disruption. Those that skip preparation risk encountering driver or app compatibility headaches, troubleshooting complexity, and the operational friction of mixed rollout states.
Hotpatch is an important tool in the modern Windows patching toolbox. Use it where it makes sense, prepare for its quirks, and remember that default changes are an invitation to audit your processes — not a replacement for them.
Source: Neowin Microsoft is enabling some Windows updates by default for several PCs
 
Microsoft quietly shifted the default for managed Windows updates on Patch Tuesday: beginning with the May 2026 security update, Hotpatch (no‑restart) updates will be enabled by default for eligible devices managed via Windows Autopatch through Microsoft Intune and the Microsoft Graph API, with tenant‑level opt‑out controls going live on April 1, 2026. This change is a major operational inflection point for enterprise Windows servicing — it promises dramatically faster time‑to‑compliance for security fixes while also introducing new prerequisites, compatibility tradeoffs, and planning obligations for IT teams ahead of the rollout date.

Background: what is Hotpatch and why it matters now​

Hotpatch (often written as “hot‑patch” or “hotpatching”) is Microsoft’s no‑restart servicing mechanism for monthly security updates. Unlike standard Latest Cumulative Updates (LCUs), which require a restart to move fixes into effect, hotpatch packages are designed to install and take effect while the OS remains running. That means security fixes can become active immediately after installation, closing the traditional “restart window” attackers have exploited.
The feature first began appearing in production in the last year on select platforms and configurations, and Microsoft reports millions of production devices already enrolled in hotpatching. The March 2026 announcement formalizes the next phase: making hotpatch the default behavior for eligible managed devices in Intune/Autopatch starting with the May 2026 security release, while giving administrators a scheduled window to opt out at the tenant level beginning April 1, 2026.
This shift is tied to broader changes in Microsoft’s servicing model: a dual cadence with quarterly baseline (restart‑required) updates and monthly hotpatch months (security‑only, restartless fixes). Understanding that calendar, the eligibility rules, and the management surface is essential for any organization that manages Windows devices at scale.

Overview: the new default and the rollout timeline​

  • Announcement made in early March 2026, effective behavior change starting with the May 2026 security update.
  • Tenant opt‑out toggle becomes available on April 1, 2026; organizations have until the first hotpatch deployment in May to act.
  • Hotpatching applies only to eligible devices — meeting both licensing and configuration prerequisites — and to devices that are managed by Windows Autopatch through Microsoft Intune or via Microsoft Graph API.
Key takeaway: the change is a default flip for eligible managed devices, not a forced global change for all Windows installations. Administrators will still control device assignments via quality update policies, and quality update policies will override the tenant default.

How Hotpatch works: mechanics and servicing calendar​

Hotpatch is a servicing mode that delivers smaller, security‑only packages during “hotpatch months,” while quarterly baseline updates remain the vehicle for larger cumulative changes and feature fixes that require restarts.
  • Baseline months: quarterly releases that include cumulative fixes and require a restart.
  • Hotpatch months: interleaving months that deliver security updates that do not require a restart for devices that meet prerequisites.
Because hotpatches are targeted and lighter weight, they consume less network bandwidth and install faster, which is one of the central operational benefits Microsoft is emphasizing. However, hotpatching is not a replacement for baseline updates; devices must still receive and install baseline releases on schedule to remain eligible.

Eligibility: licenses, OS versions, and platform configuration​

Hotpatch is intentionally gated. To be eligible, a device must meet multiple conditions across licensing, OS version, and configuration. The major prerequisites you need to be aware of are:
  • Licensing: eligible SKUs are limited to specific enterprise and education licenses and select Microsoft 365 bundles. Examples include Windows 11 Enterprise E3/E5, Windows 11 Education A3/A5, Microsoft 365 Business Premium, Microsoft 365 F3, and Windows 365 Enterprise. This is a managed‑device enterprise capability rather than a consumer feature.
  • OS version: Windows 11, version 24H2 or later is required for hotpatching on Windows client; supported Windows Server editions likewise have specific requirements where hotpatching is available.
  • Baseline status: devices must be on the latest baseline release (a restart‑required cumulative update) before they can receive hotpatch updates. If a device is behind a baseline, the baseline is installed first (requiring a restart).
  • Virtualization‑based Security (VBS): VBS must be enabled on the device for the hotpatch installer to function. VBS is a security feature that many modern deployments are already using, but it is not universal and can be intentionally disabled for compatibility reasons.
  • Arm64-specific requirement: Arm64 devices that use CHPE (Compiled Hybrid PE for x86 compatibility) must disable CHPE to be eligible for hotpatching. Disabling CHPE can break or degrade 32‑bit x86 apps on Arm devices, so device inventories and application dependencies need to be audited.
These requirements mean hotpatch is targeted at modern, enterprise‑managed fleets that can meet the prerequisites. Devices that don’t meet the conditions will simply receive the regular LCU updates and continue to follow the restart‑required model.

Benefits: faster compliance, smaller downloads, reduced disruption​

Making hotpatch the default for eligible managed devices is aimed squarely at improving security posture and user experience. The primary benefits are:
  • Faster time to compliance: with fixes active immediately on install, organizations can achieve high patch compliance much faster than the traditional model that requires waiting for restarts. Early reporting shows dramatic improvements in compliance timelines where hotpatch has been used.
  • Reduced user disruption: fewer forced restarts translate to less productivity impact and fewer helpdesk tickets resulting from lost work or interrupted sessions.
  • Lower bandwidth and install time: hotpatch packages are significantly smaller than LCUs, which helps with network efficiency and makes updates quicker to deploy across distributed fleets.
  • Consistency within Autopatch: for organizations using Windows Autopatch, enabling hotpatch by default simplifies policy creation and aims to increase baseline security across enrolled devices.
From a security standpoint, removing the restart window reduces the effective attack surface because fixes are no longer waiting to be activated on a large number of systems.

Risks and tradeoffs: compatibility, visibility, and rollback limitations​

No disruptive operational change is without tradeoffs. Here are the most important risks and operational considerations IT teams must evaluate before accepting hotpatch as the default:
  • Compatibility with legacy software: requiring VBS and disabling CHPE on Arm64 devices can break older or specialized applications. Any environment that depends on 32‑bit Microsoft 365 components or legacy COM add‑ins needs careful testing and possible exclusions.
  • Limited platform coverage: hotpatch targets modern enterprise SKUs and managed devices. Mixed fleets with unmanaged or non‑eligible devices will still rely on LCUs, creating servicing complexity.
  • Rollback limitations: automatic rollback of hotpatch updates is not supported. While a hotpatch can be uninstalled manually, doing so requires a restart and the fallback may be to reapply the LCU. That means troubleshooting and rollbacks are heavier weight than with some traditional patch orchestration.
  • Visibility and telemetry concerns: smaller, rapid installs are positive for speed, but they reduce the window in which admins can stage, observe, and measure impact before fixes are active. Organizations that rely on long validation cycles may find the speed of hotpatching challenging.
  • Dependence on cloud management: hotpatch is integrated with Windows Autopatch/Intune and Microsoft Graph API flows. Organizations that still use WSUS or strictly air‑gapped processes will need to either remain on LCUs or introduce hybrid methods; the experience and tooling differ.
  • Edge cases and failover behavior: the hotpatch monitor service on devices will detect critical issues and may revert to LCUs if needed, but those mechanisms add complexity and a new class of operational events for helpdesks to understand.
In short, hotpatch trades some admin staging control for speed and reduced disruption. For many organizations that prioritize security posture and have modernized management and application stacks, that trade is favorable. For conservative environments with critical legacy apps, the new default requires either planned remediation or an explicit opt‑out.

Operational checklist for IT teams (practical steps)​

If you manage Windows devices, treat the April 1 — May 11, 2026 window as your official planning horizon. Use this checklist to prepare and decide whether to accept the default or opt out.
  • Inventory licenses and devices
  • Confirm which devices are enrolled in Intune/Windows Autopatch and identify which meet eligible license SKUs.
  • Identify unmanaged or non‑Intune devices that will not be affected by the default change.
  • Verify baseline status
  • Ensure devices are on the latest baseline update prior to May; devices not on baseline will receive the baseline (restart required) first.
  • Audit app compatibility
  • On Arm64 devices, list apps that depend on CHPE/32‑bit binaries. Test disabling CHPE in a lab before enabling hotpatch widely.
  • Confirm VBS state
  • Check that VBS is enabled where you intend to receive hotpatches. If VBS is purposely disabled for performance or compatibility, mark those devices for exclusion.
  • Prepare policy configuration
  • If you don’t want hotpatch by default, prepare to toggle the tenant‑level setting to Block once the opt‑out control goes live on April 1.
  • Alternatively, create or edit Quality Update policies in Intune to set hotpatch Allow or Block on a per‑group basis; policy level trump tenant default.
  • Establish monitoring and rollback procedures
  • Build runbooks for investigating hotpatch errors, using event logs and the hotpatch monitor service.
  • Train helpdesk staff on the uninstallation and fallback process for hotpatches which requires a restart for rollback.
  • Communicate the change
  • Notify stakeholders and users about reduced restart frequency but also about any required reboots for baseline installs or in the event of rollback.
These steps map directly to the controls Microsoft is exposing in Intune and Autopatch; treating the rollout as a scheduled operational change — not a surprise — will reduce confusion.

How to opt out or manage the default (exact admin actions)​

Microsoft will add a tenant toggle in Microsoft Intune on April 1, 2026 that allows administrators to set the default behavior for hotpatch across the tenant. If you prefer to opt out tenant‑wide, use the Tenant administration > Windows Autopatch > Tenant management > Tenant settings pane and toggle the “When available, apply updates without restarting the device ("hotpatch")” setting to Block.
If you want a more granular approach, create or edit a Windows quality update policy and set the hotpatch option to Allow or Block for specific groups. Quality update policies assigned to devices override the tenant default, which means you can phase hotpatch adoption by pilot groups before enabling it for the entire estate.
Administrators should also use the available Intune reporting tools to view “Hotpatch readiness” and “Hotpatched” status columns to verify which devices will receive hotpatch updates.

Server and cloud considerations: Windows Server and Azure Update Manager​

Hotpatching is not limited to Windows client: Microsoft has mechanisms for no‑restart security updates on server SKUs delivered through Azure Update Manager and related Azure services for certain Windows Server editions (for example, Windows Server Azure Edition and Azure Arc–connected servers). However, the server servicing story has additional complexities:
  • On‑premises server management that relies on WSUS or Configuration Manager may not seamlessly receive hotpatch packages without integrating Azure Update Manager or Autopatch equivalents.
  • Server hotpatching timelines and baseline months may differ across server versions, and some server operating systems still require more traditional servicing practices.
  • For hybrid server environments, Azure Arc and Update Manager are the supported paths for hotpatching — that requires Azure subscriptions, appropriate licensing, and often additional configuration and testing.
Enterprises that manage a mixture of client and server hosts must treat the server side as a parallel but distinct program, with separate prerequisites and testing cycles.

Real‑world signals and community feedback​

Adoption signals and community discussions over the last year have exposed both enthusiasm and friction points: administrators praise the reduction in restart‑driven downtime and improved compliance metrics, while others highlight practical problems around Arm64 CHPE, VBS enforcement, and the need to rework legacy app support. There have also been reports of administrators seeing hotpatch labels appear in quality update reports for Windows 11 Pro devices in some telemetry — a behavior that requires careful clarification and testing in your tenant.
The practical lesson from community experience is simple: hotpatch works well in modern, standardized fleets; it requires work in heterogeneous environments. Organizations that rush to accept a default change without conducting compatibility testing risk creating support incidents that negate the user‑experience benefits.

Security analysis: does hotpatching materially reduce risk?​

From a defensive perspective, enabling hotpatch by default on eligible managed devices materially reduces the exposure window for newly disclosed vulnerabilities. Historically, the time between patch release and device restart has been an exploitable window. If updates are installed and take effect immediately, attackers have a shorter window to exploit unpatched systems en masse.
That said, some security concerns remain:
  • Hotpatches are security‑only. They do not replace baseline updates, which may contain mitigation workarounds or additional remediation steps that require a restart; keeping baseline cadence is essential.
  • The enforcement of VBS as a prerequisite is security‑minded, but it may force architectural changes in environments that have VBS disabled for compatibility or performance reasons.
  • Faster patch application increases the need for robust testing and monitoring pipelines: the security benefits can be offset if a hotpatch inadvertently breaks an authentication agent or other security controls.
Overall, the security calculus favours hotpatch for modern, managed estates — but only when combined with disciplined baseline updates, telemetry, and rapid‑response runbooks.

Recommendations for CIOs, security leaders, and system admins​

  • Treat this as a program change with scheduled milestones: prepare to make a deliberate choice before the tenant opt‑out toggle goes live on April 1, 2026 and before the first hotpatch default deployment in May 2026.
  • Audit license entitlements and device inventories to know which assets will be affected.
  • Remediate blockers early: get eligible devices onto the latest baseline and enable VBS where feasible.
  • Pilot hotpatch on a representative subset (non‑critical users, modern laptops without legacy apps) before broad enablement.
  • Maintain clear communication with user support and application owners about the new servicing model, the limited rollback options for hotpatch, and the conditions that still require restarts.
  • Retain traditional update policy controls for sensitive groups; use Quality Update policies to control hotpatch behavior per device group.

The larger picture: modernization of Windows servicing​

This default change is part of a broader evolution: Windows is moving toward faster, less disruptive security servicing for enterprise customers who have modern management and licensing in place. The model echoes trends across enterprise software — smaller, targeted patches delivered with automation and observability to reduce both risk and user friction.
But easier security does not happen by flipping a switch. The move to hotpatch as a default demonstrates how cloud management, licensing, and platform security features (like VBS) are converging to enable faster remediation. For organizations that have invested in modern endpoint management and application modernization, the change is a net positive. For those still juggling legacy dependencies and complex on‑prem tooling, it’s a mandate to accelerate modernization or to use the opt‑out and phased rollout paths Microsoft provides.

Conclusion​

Microsoft’s decision to enable Hotpatch updates by default for eligible Autopatch/Intune‑managed devices marks a significant milestone in Windows servicing. The promise is compelling: dramatically faster security compliance, smaller downloads, and fewer disruptive reboots. But the reality for enterprise IT is nuanced — prerequisites around licensing, OS baselines, VBS, and Arm64 CHPE create a nontrivial checklist that must be validated before accepting the default.
For the cautious: use April 1, 2026 to decide. For the modernized enterprise: this is a tool to reduce risk and improve user experience. Either way, this change should be treated as a scheduled operational project, not a background option. Prepare your inventories, test app compatibility, verify device readiness, and use quality update policies to stage adoption. If you do the work now, you’ll take advantage of faster security without suffering the common pitfalls of rushed change.
Source: GIGAZINE https://gigazine.net/gsc_news/en/20260311-windows-update/
 
You must log in or register to reply here.