Windows 11 KB5132043 Hotpatch: No-Restart Security Update, Eligibility and Arm64 Requirements

This release also carries two operational reminders worth separating from the security payload: administrators must satisfy the update’s baseline and servicing-stack requirements, and Arm64 devices need additional preparation. Meanwhile, the Secure Boot certificate notice accompanying the release is a separate maintenance concern—not a claim that installing this hotpatch finishes the certificate transition.

What KB5132043 changes—and what Microsoft does not detail​

Microsoft’s release notes describe KB5132043 as a security update containing security and quality improvements. They do not provide a component-by-component repair list or identify individual vulnerabilities in the change summary. Instead, Microsoft points to its Security Update Guide for vulnerability information. Consequently, there is no basis here for attributing a particular exploit fix, application repair or performance improvement to this package.

The release covers these Windows branches:

These are the build identifiers associated with the November 10 release. Administrators should match the target build to the device’s Windows version rather than treating the shared .9911 suffix as a complete identifier.

Microsoft states that it is not currently aware of issues with this update. That is a statement about the release’s documented known-issue status, not a guarantee that every application and hardware combination has been tested. My operational recommendation remains to validate deployment on a representative group before expanding it across a fleet. “No known issues” is useful information, but it is not a substitute for your own deployment results.

Why “no restart” still depends on a baseline​

Microsoft’s Windows servicing documentation distinguishes hotpatches from ordinary monthly cumulative updates. Hotpatches carry security fixes, while quarterly baseline updates also bring the cumulative features and enhancements needed to keep the device’s servicing foundation current. Those baseline updates require a restart; the design then allows the following two monthly hotpatches to install without one.

The practical consequence is that hotpatching reduces restart disruption rather than abolishing maintenance windows. A machine cannot indefinitely skip baseline servicing and still expect every subsequent update to arrive without interruption. For KB5132043, Microsoft explicitly requires baseline KB5127648 to be installed first. That prerequisite deserves a place in the deployment checklist, not a footnote discovered after a failed rollout.

It also explains why two otherwise similar PCs can behave differently. Microsoft’s Intune guidance says devices that do not meet hotpatch prerequisites receive the standard latest cumulative update instead, which requires a restart. Existing update-ring settings remain in effect. A restart prompt therefore does not, by itself, prove that hotpatching malfunctioned; it can indicate that the device followed the standard servicing route.

Who should expect this update?​

This is primarily an enterprise update-management story, not a universal change to consumer Windows Update. Microsoft’s hotpatch guidance requires an eligible license, a supported Windows version, the current baseline, Intune-managed hotpatch deployment and virtualization-based security, or VBS, enabled.

The KB’s Arm64 prerequisites identify these eligible licenses:

• Windows 11 Enterprise E3 or E5.
• Microsoft 365 F3.
• Windows 11 Education A3 or A5.
• Microsoft 365 Business Premium.
• Windows 365 Enterprise.

The same section calls for a hotpatch-enabled Windows quality update policy in Intune. Owning an Arm-based Windows laptop, or simply running one of the Windows versions in the headline, does not establish eligibility.

There is also an important version boundary: although the overall release covers 26H2, 25H2 and 24H2, its Arm64 general-availability and preparation instructions explicitly name 25H2 and 24H2. Administrators should not silently extend that Arm64 statement to 26H2. The architecture-specific instructions are narrower than the headline.

Preflight: verify the baseline and servicing stack​

Before deploying KB5132043, establish that the device has the required baseline and installation infrastructure. Microsoft specifies:

The minimum prerequisite and the bundled servicing-stack version serve different purposes: one describes the required starting point, while the other identifies the newer servicing component delivered with the release.

Microsoft supplies this check for the installed servicing stack. Open an elevated Command Prompt and run:

DISM /Online /Get-Packages | findstr /i "ServicingStack"

Inspect the returned Package Identity information. The servicing-stack version must be 26100.9703 or later. This command checks the servicing-stack package; it is not a substitute for confirming that baseline KB5127648 is installed. Microsoft also says Windows Update installs the latest servicing-stack update together with KB5132043 when that channel is used.

For VBS, Microsoft’s troubleshooting guidance provides a separate check:

1. Search Start for System information.
2. Open it and select System summary.
3. Locate Virtualization-based security.
4. Confirm that its value is Running.

Together, these checks distinguish “the device runs a supported Windows release” from “the device is ready for this hotpatch.” That distinction is where much of the troubleshooting value lies.

Arm64 preparation: a one-time restart still matters​

For Arm64, the KB specifies Windows 11 Enterprise 25H2 or 24H2, cites build 26100.4929 or later, and requires the current baseline alongside the licensing, Intune and VBS conditions. It also requires Compiled Hybrid PE, or CHPE, to be disabled. The historical minimum build does not replace the newer baseline prerequisite for this particular update.

Before changing that setting, check the application estate. Microsoft’s broader hotpatch documentation explains that CHPE supports efficient execution of 32-bit x86 applications on Arm64. Disabling it can cause application failures or performance problems in affected legacy environments, including some 32-bit Office, VBA and COM add-in scenarios. Microsoft recommends moving affected programs to 64-bit where possible or excluding devices that must retain those applications from hotpatch policies.

That is a meaningful trade-off, not merely an enrollment checkbox. My recommendation is to test the change against the actual applications used by the target group before applying it broadly.

For the registry-based preparation method, Microsoft documents:

• Registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
• Value name: HotPatchRestrictions
• Value type: DWORD
• Value data: 1

Create or set that value, then restart the device once. Microsoft’s Intune guidance confirms the DWORD type and explains that the setting persists through updates. This requirement applies to Arm64 devices, not AMD or Intel PCs.

The setup restart is distinct from installing an eligible monthly hotpatch. In other words, “restart once to prepare” and “install subsequent hotpatches without restarting” are compatible statements. Do not mark preparation complete merely because the registry value exists; the prescribed restart is part of the procedure.

Configure the Intune policy and confirm delivery​

The KB describes this enrollment route for the prepared Arm64 device group:

1. Open the Microsoft Intune admin center.
2. Navigate to Devices > Windows updates > Quality updates.
3. Create a Windows quality update policy, or select an existing policy and edit its settings.
4. Under automatic update deployment settings, set When available, apply without restarting the device to Allow.
5. Assign the policy to the intended Arm64 device group.

Policy assignment matters as much as policy creation. Microsoft’s current Intune documentation says an assigned quality update policy takes precedence over the tenant’s default hotpatch setting. For troubleshooting, inspect the configuration that actually applies to the device rather than assuming the tenant default settles the question.

For KB5132043 itself, Microsoft identifies Windows Update as the automatic download and installation route. The release-channel table directs Microsoft Update Catalog and Windows Server Update Services users to the other options rather than providing those channels as installation routes for this hotpatch. Do not plan deployment around a standalone Catalog package that the release does not offer.

What does success look like? The target device should reach the build corresponding to its Windows branch, and deployment reporting should show its actual update state—not simply that it belongs to an assigned group. Microsoft provides a Hotpatch quality updates report under Reports > Windows Autopatch > Windows quality updates, on the Reports tab, for monitoring deployment status and errors.

If results differ from expectations, work through the prerequisites in order: required baseline, servicing stack, running VBS, applicable policy and, for Arm64, CHPE preparation plus its restart. That sequence is more useful than repeatedly changing the same policy without establishing which condition is missing.

Secure Boot: a separate check, not a hotpatch feature​

The release notes repeat Microsoft’s warning that older Secure Boot certificates began expiring in June 2026. Microsoft says it has been distributing replacements to consumer and non-managed business devices and will continue delivering them through Windows Update. Devices without the replacements can still start normally and install standard Windows updates.

However, continued operation is not equivalent to complete boot-security coverage. Microsoft’s dedicated certificate guidance says devices lacking the newer certificates cannot receive certain new early-boot protections, including relevant Windows Boot Manager updates, Secure Boot database changes, revocation updates and mitigations for newly discovered boot-level vulnerabilities. That makes the transition a security-maintenance task even when the PC appears healthy.

To inspect the user-facing status:

1. Open Windows Security.
2. Select Device security.
3. Open the Secure Boot section.
4. Read the accompanying status text—not just the badge color.

Microsoft explicitly warns that a green checkmark alone does not prove the certificate transition is complete. The fully updated state confirms that Secure Boot is enabled and all required certificate updates have been applied. Hardware or firmware limitations can require manufacturer assistance; a documented compatibility pause instead resumes automatically once resolved. Microsoft also notes that Secure Boot-specific badge changes and notifications are disabled by default on managed enterprise devices.

The useful distinction is straightforward: KB5132043 installation status and Secure Boot certificate status answer different questions. The KB does not claim that this hotpatch, by itself, completes the certificate rollout. Track both rather than allowing a successful Windows security update to close an unrelated certificate-maintenance task.

The practical takeaway​

KB5132043 is a security servicing release, not a feature showcase. Its value is the opportunity to keep eligible Windows 11 devices protected with less restart disruption, provided that baseline KB5127648, the servicing-stack requirement and the applicable hotpatch configuration are in place. Arm64 administrators have an additional compatibility decision and a one-time preparation restart to account for.

For deployment planning, I would treat this as three separate checks: readiness before installation, actual update results afterward, and Secure Boot certificate status alongside both. Hotpatching can remove an interruption from the user’s day. It does not remove the administrator’s need to verify what happened.