Hotpatch on Windows 11 25H2: Restart Free Security for Enterprises

Hotpatch-enrolled tenants upgrading to Windows 11, version 25H2 will find a fundamentally different servicing model for security updates: organizations can apply targeted security patches that take effect immediately without forcing a device restart, but only when devices meet specific enrollment, configuration, and licensing prerequisites and are managed through Autopatch/Intune.

Background / Overview​

Microsoft’s Hotpatch program for Windows client devices extends the company’s existing in-place, no‑restart update capability (previously used on server SKUs) to Windows 11 Enterprise. The core idea is simple: split the year’s security servicing into quarterly baseline updates that may require restarts and intervening hotpatch months where security-only fixes are delivered and applied without a reboot. Eligible devices that install a hotpatch receive immediate protection as soon as the update is applied in memory, reducing planned restarts and minimizing user disruption.
Hotpatch for Windows 11, version 25H2 is delivered as an extension of Windows Update but requires management and enrollment through Windows Autopatch (or specifically a Windows quality update policy created in Intune). That management requirement is not incidental: Autopatch creates and deploys hotpatch updates for devices assigned to a Hotpatch-enabled quality update policy. In practice this means hotpatch is primarily an IT‑managed, enterprise feature rather than a consumer toggle.

---

What Hotpatch changes — the practical difference​

• Hotpatch updates are security-only and intentionally narrow in scope. They are not replacements for cumulative, feature, or firmware updates that still require restarts.
• When a hotpatch installs successfully, the fix takes effect immediately — there is no need to wait for the next reboot cycle to reduce exposure time to vulnerabilities.
• The servicing rhythm becomes quarterly baseline updates (restart required) followed by two months of hotpatch updates (no restart required), reducing forced restarts from a typical twelve per year to a target of four per year for eligible devices.

These changes have real operational implications: mission‑critical endpoints, kiosks, clinical workstations, and other high‑uptime devices see fewer workflow interruptions while still receiving security protections more quickly.

---

Eligibility and prerequisites — the gatekeepers​

Before planning an upgrade or enabling hotpatch, verify these mandatory requirements:

• Edition and version: Devices must run Windows 11 Enterprise, version 25H2 (or 24H2 baseline for enablement depending on timing) and be on the current baseline cumulative update when the hotpatch is offered. Devices not on the baseline fall back to the standard Latest Cumulative Update (LCU) path.
• Licensing: Eligible licenses include Windows 11 Enterprise E3/E5 (and equivalent Microsoft 365 education/enterprise SKUs), Microsoft 365 Business Premium, or Windows 365 Enterprise. Organizations should confirm their tenant licensing aligns with Microsoft’s hotpatch prerequisites.
• Management: Microsoft Intune (and Windows Autopatch for automated deployment) is required to create and assign a Windows quality update policy with Hotpatch enabled; Autopatch orchestrates hotpatch deployment for enrolled devices.
• Virtualization-based Security (VBS): VBS must be enabled on a device for it to be offered hotpatch updates. This is a hard prerequisite checked by the service.
• Architecture notes (Arm64): Arm64 support is available but requires a one-time disablement of Compiled Hybrid PE (CHPE) to be eligible for hotpatches. This is done via a registry key or the DisableCHPE CSP and requires a restart to take effect. Expect testing needs for x86 emulation workloads after CHPE is disabled.

Community discussions and early reports repeatedly stress that eligibility checks are strict: devices missing any prerequisite will be automatically offered the standard cumulative updates (LCU), which continue to require restarts. Administrators must therefore plan for mixed estates.

---

Enrollment and configuration — how to put devices on hotpatch​

The enrollment path is straightforward but operational:

• In the Intune admin center, go to Devices > Windows updates > Quality updates.
• Create a new Windows quality update policy (or edit an existing one).
• Under Settings, set “When available, apply without restarting the device (‘Hotpatch’)” to Allow.
• Assign the policy to the appropriate device groups or Autopatch groups and monitor the Hotpatch quality updates report.

If you manage updates through Windows Autopatch, create a Hotpatch policy and assign devices to it; Autopatch will generate the necessary quality update policy components for the group. Recent Microsoft messaging also changed defaults so that newly created quality update policies enable hotpatch by default, so administrators should audit new policies to confirm behavior.

---

Release cadence and what to expect in 25H2 deployments​

Microsoft separates updates into:

• Baseline months (quarterly) — cumulative updates that include feature and quality changes and generally require a restart.
• Hotpatch months — security-only updates applied without restart to eligible devices.

A typical yearly pattern: January/April/July/October = baseline; February/March, May/June, August/September, November/December = hotpatch months. Administrators should consult Microsoft’s release notes for the concrete calendar and the monthly KB articles that indicate whether a given release contains a hotpatchable package.

---

Benefits — immediate and measurable​

• Immediate protection: hotpatch updates become active the moment they are applied, narrowing the exposure window between patch release and protection. This is especially useful for high‑risk vulnerability disclosures.
• Reduced disruption: fewer restarts translate to less downtime for users and server‑like availability for critical endpoints. The productivity gains can be substantial at scale.
• Targeted scope: because hotpatches are narrow and security-focused, they’re simpler to validate and less likely to introduce feature regressions that require broad re‑testing.

These advantages are compelling for organizations that prioritize high availability and rapid mitigation.

---

Risks, compatibility and operational caveats​

Hotpatch introduces new operational considerations and potential failure modes IT teams must plan for.

1) Management and enrollment friction​

Hotpatch is tied to Autopatch/Intune and license entitlements; mixed environments (some devices not enrolled or not meeting prerequisites) will diverge in patch states and reported KB/build numbers. Asset and compliance tooling must be updated to correctly interpret hotpatched builds and KB identifiers. Failure to do so can produce false non‑compliance alarms.

2) Third‑party driver and EDR interactions​

Hotpatch modifies in‑memory code paths, which some kernel‑mode drivers or aggressive EDR hooks may interpret as anomalous behavior. Vendors may need to adapt agents to tolerate hotpatch operations. Pilot these agents early and coordinate with vendors to reduce rollout surprises. Community threads highlight reports of compatibility checks failing in early pilots; test coverage must include EDR and driver stacks.

3) Arm64 CHPE tradeoffs​

Disabling CHPE on Arm64 devices is required to receive hotpatches because CHPE binaries are not compatible with hotpatch servicing. Disabling CHPE can change x86 emulation performance and behavior. Microsoft explicitly requires a one‑time restart after applying the CHPE disable setting and recommends thorough testing before broad deployment. If an organization’s Arm64 fleet relies heavily on CHPE for performance, hotpatch may not be the right fit right now.

4) Virtualization host/guest coordination​

When virtualization management surfaces (e.g., PowerShell Direct — PSDirect) are involved, hotpatches can create transient interoperability issues if hosts and guests are patched unevenly. Microsoft has published specific corrective hotpatches to address handshake regressions, and administrators are advised to coordinate patching across hypervisor hosts and VMs to avoid management breakage. Validate PSDirect and other host‑guest scenarios in pilots.

5) Firmware and pre‑boot certificate lifecycles​

Separate from hotpatch, Microsoft and OEMs are rolling out updated Secure Boot certificates because older certificates embedded in firmware begin to expire in mid–late 2026. Ensure BIOS/UEFI and firmware update plans are in place; failure to update certificates can impact the system’s ability to validate boot components and to receive updates. This is not a hotpatch defect, but a timely firmware coordination item administrators must address during a broader servicing plan.

6) Rollback and forensics​

Automatic rollback of a hotpatch is not supported; uninstallation is manual and requires a restart. If a hotpatch causes issues, the mitigation path is to uninstall the hotpatch and apply the standard cumulative update (LCU) and restart. Because hotpatch updates change reported build numbers and KB identifiers, forensic timelines and vulnerability scanners must map hotpatch KBs to expected protection levels.

---

Testing and rollout recommendations — a practical playbook​

A disciplined pilot and staged rollout make hotpatch adoption practical and safe. The following sequence condenses best practices drawn from Microsoft guidance and field reports.

• Lab validation:
• Build a test ring that mirrors production in key dimensions: EDR/AV vendors, hypervisor hosts, drivers, and firmware levels.
• Validate baseline cumulative updates and the hotpatch install/uninstall path on representative hardware.
• Baseline readiness:
• Confirm all target devices are on the required baseline build before enabling hotpatch policies; devices not on baseline will receive LCUs.
• Enable VBS at scale using supported MDM/CSP or Group Policy paths; avoid unsupported registry hacks except for controlled labs.
• Small pilot ring (1–5% of fleet):
• Enable hotpatch via a Windows quality update policy. Monitor verbose EDR logs, performance counters, and event logs for anomalies such as Event ID 4625 (in PSDirect scenarios) or process/driver crashes.
• Early adopter ring (10–25%):
• Expand node types: include endpoints across OEMs, firmware revisions, and specialized workstations.
• Validate reporting pipelines: confirm CMDB, SCCM, or vulnerability management systems map hotpatched builds correctly.
• Production rollout:
• Stagger the rollout, maintain rollback runbooks, and schedule baseline restarts for the quarterly cumulative updates.
• Keep communication channels open with vendors for any EDR/driver issues.
• Post‑deployment instrumentation:
• Tune SIEM and EDR detection rules to remove noisy alerts caused by expected hotpatch behavior.
• Track hotpatch KB numbers and build values so compliance dashboards do not flag hotpatched devices incorrectly.

---

Monitoring, inventory and compliance​

Hotpatches report different KB numbers and often a lower “hotpatch build” than the corresponding LCU builds. Update your inventory rules and compliance scanners to recognize both hotpatch and LCU build variants to avoid false positives in vulnerability scanners and compliance reports.

• Use Intune’s Hotpatch quality updates report to see per‑policy deployment status and errors.
• Ensure CMDB and vulnerability management tools are updated to recognize hotpatch KBs and the specific build strings that indicate a device is protected by a hotpatch.

---

Cross‑checks and verifiability​

Microsoft’s official support and Learn pages document hotpatch mechanics, prerequisites (VBS, CHPE for Arm64), and enrollment. Microsoft TechCommunity blog posts provide engineering and administrative context, and independent community threads have tracked early pilot experiences, compatibility notes, and real‑world operational caveats. Administrators should treat Microsoft documentation as authoritative while using community reports to guide risk assessments and vendor coordination.
Where Microsoft KBs omit CVE details for hotpatch releases, auditors should consult the Microsoft Security Update Guide or MSRC advisories to map fixes to required compliance artifacts. Some KBs intentionally focus on functional descriptions rather than CVE enumerations; treat any missing CVE mapping as a follow‑up action for compliance teams.

---

Critical analysis — strengths and remaining gaps​

Strengths​

• Operationally transformative: Hotpatch meaningfully reduces the friction of security maintenance on high‑uptime devices and cuts the immediate exposure window for emergent vulnerabilities.
• Managed delivery: Tying hotpatch to Autopatch/Intune ensures enterprises can deploy updates through existing device‑management pipelines, keeping governance intact.
• Narrow scope reduces regression risk: Security-only patches tend to be less disruptive than broader feature releases, improving safety for mission‑critical systems.

Weaknesses and open questions​

• Enrollment and licensing complexity: The Autopatch/Intune requirement and license gating limit hotpatch to managed enterprise clients. Organizations with mixed estates must juggle dual servicing models and reconciliation overhead.
• Third‑party compatibility: Hotpatch changes in‑memory behavior and has triggered compatibility issues in early pilots—particularly with virtualization management surfaces and some security agents. This necessitates vendor coordination and robust testing.
• Arm64 tradeoffs: The CHPE disable requirement exposes a real tradeoff between performance (x86 emulation improvements) and hotpatch eligibility for Arm64 devices. Organizations must evaluate whether hotpatch benefits outweigh potential emulation performance impacts.
• Documentation and tooling maturity: While Microsoft has provided extensive guidance, some KBs lack CVE mappings and certain operational edge cases (e.g., PSDirect handshake regressions) required rapid corrective hotpatches. Monitoring the release‑health dashboard remains essential.

---

Quick checklist for IT teams (concise)​

• Confirm licensing and Intune/Autopatch enrollment.
• Verify devices are on the required baseline build before enabling hotpatch.
• Enable VBS across candidate endpoints via supported CSP/MDM.
• For Arm64 hardware, plan and test CHPE disablement and restart once to take effect.
• Pilot hotpatch on representative hardware, EDR, and virtualization stacks.
• Update inventory and compliance tooling to recognize hotpatch KBs and hotpatch build values.

---

Conclusion​

Hotpatch in Windows 11, version 25H2 is a practical, high‑value evolution of Windows servicing for enterprises: it reduces downtime, narrows exposure windows, and aligns security delivery with modern availability requirements. For organizations with the required licensing and management maturity — specifically Intune and Autopatch enrollment, VBS enabled, and baseline alignment — hotpatch offers a compelling way to protect endpoints with minimal disruption.
However, it is not a turnkey solution for all environments. The operational cost of enrollment, the need to coordinate with EDR and driver vendors, the Arm64 CHPE tradeoffs, and the requirement to update compliance tooling introduce real project work. The prudent path is conservative: validate prerequisites in a lab, pilot broadly across representative hardware, and coordinate with vendors. When implemented thoughtfully, hotpatch becomes a powerful tool in an enterprise’s patching toolkit; implemented hastily, it risks fragmentation and compatibility headaches.
Administrators should treat Microsoft’s hotpatch documentation and release notes as the primary source of truth while using community reports to shape the testing scope — and plan their rollout accordingly to reap the productivity and security benefits without losing control of their servicing pipelines.

---

Source: Microsoft - Message Center Release notes for Hotpatch on Windows 11 Enterprise version 25H2 - Microsoft Support