Microsoft has drawn a hard line in the sand for Windows patch management: no Virtualization-based Security (VBS), no hotpatching. The message, delivered through technical documentation and Intune policy updates, means that enterprises eager to slash reboot cycles and accelerate security fixes must first enable VBS across their fleets – a deceptively simple requirement that demands coordinated firmware, licensing, and compatibility efforts.
IT leaders who once viewed VBS as an optional security hardening feature now must treat it as a prerequisite for modern servicing. Hotpatching, which applies security fixes to running code without forcing an immediate restart, depends on the isolation guarantees that VBS provides. Without that secure runtime environment, devices will continue to receive traditional cumulative updates – reboots and all.
This shift turns VBS enablement from a nice-to-have into a must-do for any organization that values continuous uptime and rapid vulnerability response. But the path to universal VBS readiness is littered with hardware compatibility checks, firmware updates, and a one-time Arm64 configuration change that could disrupt x86 emulation performance.
Why VBS became the gatekeeper for restartless security
VBS uses hardware virtualization and, typically, a TPM to create a secure kernel environment separate from the main OS. Hotpatches rely on this boundary to validate and apply in-memory changes safely. Microsoft’s documentation is unambiguous: devices that can’t enable VBS – whether due to missing virtualization extensions, disabled Secure Boot, or incompatible hypervisor settings – will remain on the restart-required update cadence.
For heterogeneous fleets, that creates a dual-servicing reality. Some devices will sip restartless hotpatches while others will chug through full cumulative updates. Schisms like this erode the operational predictability that IT teams fight to maintain, turning patch Tuesday into a tale of two endpoints.
The eligibility checklist: more than just a tick box
Enabling VBS at scale isn’t a registry flip away. It’s a multi-pronged qualification exercise that touches OS baselines, licensing, management surfaces, and firmware. Here’s the full list of what each device needs to qualify for hotpatch delivery:
- Platform and build: Windows 11 Enterprise 24H2, specific server SKUs, or newer builds aligned with Microsoft’s hotpatch KB guidance. Check build numbers against official KB articles.
- Licensing: Only certain volume or cloud licenses qualify – Windows Enterprise E3/E5, Microsoft 365 variants, Education SKUs, Windows 365 Enterprise, and others. Not every Pro or Business edition will cut it.
- Management: Microsoft Intune (or Windows Autopatch) acts as the control plane. Devices must be enrolled to configure hotpatch policies and report compliance.
- Virtualization-based Security: Must be active. This demands that firmware/UEFI expose virtualization extensions, Secure Boot is on, and usually TPM 2.0.
- Arm64 caveat: Arm64 devices face an extra hurdle. The Compiled Hybrid PE (CHPE) binary compatibility layer must be disabled via policy or registry, followed by a reboot. This one-time change is required for hotpatch eligibility but can affect performance of emulated x86 applications.
These requirements transform VBS enablement into an integrated program that spans asset inventory, vendor coordination, and app testing. Treating it as a simple policy toggle is a recipe for surprise incompatibilities and support tickets.
A phased deployment playbook for VBS at scale
Field-tested guidance and community rollouts point to a structured, ringed approach that reduces risk and maximizes visibility. Here’s a practical playbook.
1. Inventory and eligibility validation
Use Intune, SCCM, or your CMDB to catalog every device by OS build, CPU architecture, virtualization extension status, Secure Boot state, and TPM presence. Record each device’s current Windows baseline. Flag any that lack hardware support for VBS – they’ll need to be replaced or excluded from hotpatching indefinitely.
2. Firmware and platform prep
Work with hardware vendors to push firmware updates that unlock virtualization features. For servers and VMs, ensure hypervisor configurations expose nested virtualization where needed. Missing firmware capabilities are the most common initial blocker.
3. Pilot deployment
Select a representative pilot group spanning different OS builds, architectures (x64 and Arm64), and critical application stacks. For Arm64 pilot devices, disable CHPE via one of two methods:
- Intune/Group Policy CSP: set …/Device/Vendor/MSFT/Policy/Config/Hotpatch/DisableCHPE = 1
- Registry: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\HotPatchRestrictions = 1
After making this change, reboot each Arm64 device once. Then apply the VBS enablement policy and hotpatch delivery configuration to the pilot group.
4. Mass VBS enablement via policy
Always prefer policy-based enablement over manual registry edits. Many organizations use device configuration profiles to enforce Device Guard/VBS settings and ensure Secure Boot and TPM compliance. If registry edits are unavoidable for automation, pair them with strong telemetry and reboot documentation. Example registry key (one-time, requires reboot):
HKLM\SYSTEM\ControlSet001\Control\DeviceGuard\EnableVirtualizationBasedSecurity = 1
5. Enroll in hotpatch delivery via Intune
The final switch: create or edit a Windows quality update policy in Intune (Devices > Windows updates > Quality updates). Under “Automatic update deployment settings,” set “When available, apply without restarting the device” to Allow and assign the policy to the pilot ring. This policy instructs Windows Update to accept hotpatches that can install without a reboot.
Verification: how to prove it’s working
After deployment, verification is two-pronged: local device checks and centralized reporting.
Locally, run msinfo32.exe and look for “Virtualization-based Security” in System Summary – it should say Enabled. Windows Update history will list hotpatch KBs with a “(Hotpatch)” label and document the OS build number change. For example, KB5064010 corresponds to OS Build 26100.4851; tracking such mappings is essential for audit trails.
In Intune, the updates reporting blade shows which devices received hotpatches and which did not. Create custom reports to correlate KB installation with OS build and highlight any machines that fell back to traditional cumulative updates.
The benefits that make the effort worthwhile
When done right, VBS-enabled hotpatching delivers measurable operational and security gains.
- Reduced downtime: Eliminating forced reboots for security patches directly boosts user productivity and cuts helpdesk calls related to unexpected restart prompts.
- Faster risk mitigation: Hotpatches can shrink the vulnerability exposure window from days to hours, particularly critical for zero-day flaws.
- Bandwidth savings: Hotpatch packages are smaller, memory-targeted fixes rather than full cumulative rollups, which eases strain on metered or remote connections.
- Centralized control: Intune and Windows Autopatch provide a single pane for policy assignment, rollout rings, and compliance – aligning with modern management goals.
Risks, trade-offs, and how to manage them
No enterprise technology change comes without friction. Here are the key risks and mitigation strategies for VBS-driven hotpatching.
Hardware and firmware incompatibility: Older devices or misconfigured VMs that can’t support VBS will stay on the traditional update path. Mitigate by conducting a thorough inventory, pushing firmware updates aggressively, and budgeting for hardware refresh where necessary.
CHPE disablement impact on Arm64: Disabling CHPE can degrade performance for x86 apps running under emulation on Arm64. Pilot heavily with your LOB applications, measure performance deltas, and coordinate with ISVs. Make sure users understand the one-time reboot requirement.
Third-party driver and security agent conflicts: Hotpatches modify in-memory code paths that antivirus, EDR, and backup tools often hook. Include these vendors early in your pilot, test their agents thoroughly, and hold back devices where vendor support isn’t confirmed until compatibility is verified.
Rollback complexity: Uninstalling a hotpatch usually requires a restart, so it’s not a fully restartless rollback. Plan maintenance windows for these scenarios and document rollback runbooks. Validate uninstall procedures during the pilot.
Firmware lifecycle events: Secure Boot certificate expirations and other firmware changes operate on their own timelines. Don’t assume hotpatching will cover these risks; treat firmware updates as a separate program with its own verification steps.
A practical rollout checklist
Use this repeatable checklist to guide your deployment:
- [ ] Complete device inventory with OS build, architecture, Secure Boot, TPM, and virtualization extension status
- [ ] Confirm licensing hotpatch eligibility for target SKUs
- [ ] Verify Intune/Autopatch enrollment for all candidate devices
- [ ] Define a pilot group that includes Arm64 devices, and disable CHPE on those (reboot once)
- [ ] Deploy VBS enablement policy to pilot via Intune; validate with msinfo32
- [ ] Create Windows quality update policy with “apply without restarting” set to Allow for the pilot
- [ ] Monitor Intune reports and Windows Update history for hotpatch KB appearance and OS build updates
- [ ] Validate uninstall/reboot behavior in a controlled pilot scenario
- [ ] Expand rings progressively, adding telemetry and vendor compatibility checks at each stage
The organizational reality: it’s a program, not a project
The technical steps are deceptively simple: enable VBS, flip a policy, maybe change a registry key. The hard part is the organizational orchestration – coordinating asset management, firmware lifecycles, licensing validation, and the multi-vendor testing that hotpatching demands.
Community reports and early enterprise aduption stories suggest that organizations that treat VBS enablement as a cross-functional program succeed. Those that treat it as a one-off IT task often stall when they encounter the first incompatible driver or unexpected CHPE performance cliff.
Microsoft’s own messaging, scattered across Message Center posts and documentation, promises millions of devices already using hotpatching. But independent verification of those numbers is scarce. IT leaders should rely on their own telemetry, not vendor-reported figures, when assessing readiness.
The bottom line
For enterprises that can meet the prerequisites, VBS-enabled hotpatching is a genuine win: fewer reboots, faster security response, and lighter update payloads. But the path to that win is paved with firmware upgrades, app compatibility tests, and careful policy staging.
Start with inventory. Engage your hardware and software vendors early. Run a meaningful pilot that covers both x64 and Arm64. Build your telemetry dashboards before you flip the switch. With that foundation, hotpatching can move from a promising idea to a reliable, restartless reality in your Windows fleet management toolkit.