Microsoft has tied the future of update servicing to a deeper security infrastructure: Virtualization-based Security (VBS) must be enabled for Windows devices to receive hotpatch updates. This change transforms VBS from an optional hardening feature into a mandatory operational prerequisite. For IT teams, that means a fleet-wide enablement project is no longer a nice-to-have; it’s the only path to reboot-light patching.

Hotpatching, which applies critical security fixes in memory without an immediate restart, relies on the hypervisor-isolated environment VBS provides. Without it, the trust boundaries and runtime protections needed to safely alter running kernel code simply don’t exist. Devices that lack VBS will continue to receive traditional cumulative updates, complete with mandatory restarts. That’s not a temporary limitation—it’s by design.

This article distills the technical facts, configuration pathways, and rollout strategies drawn from Microsoft’s official documentation and real-world deployment experience. We’ll cover exactly what VBS is, why it’s now the gatekeeper for hotpatching, the hardware and software prerequisites, step-by-step enablement via Intune, Group Policy, and registry, the unique Arm64 CHPE requirement, and a staged pilot plan to get your entire estate hotpatch-ready without blue-screening half your endpoints.

What is Virtualization-based Security and Why Does Hotpatching Need It?

Virtualization-based Security uses the Windows hypervisor to create an isolated, higher-privileged environment. Inside that environment, critical security services like Hypervisor-Enforced Code Integrity (HVCI, also known as Memory Integrity) and Credential Guard run untouchable by the rest of the operating system. Even if an attacker compromises the kernel, they can’t tamper with these services or the secrets they protect.

Hotpatching extends that model. It works by applying in-memory p-code patches to running system components. That requires a trusted execution enclave where patch integrity can be verified and enforced. VBS provides exactly that: a hypervisor-rooted root of trust that ensures hotpatches aren’t tampered with and that the patched code remains trustworthy.

Microsoft’s own security research has shown measurable reductions in kernel exploit and credential theft when VBS is active. The hotpatch requirement simply formalizes this dependency. In short: no VBS, no hotpatch eligibility. For organizations eyeing the 45% reduction in restart-caused downtime that Microsoft claims for hotpatch adopters, that makes VBS enablement an immediate priority.

Who Is Eligible? The Full Prerequisites Checklist

Before diving into enablement, verify that your fleet meets these baseline requirements. Missing any one of them will block hotpatches even if VBS is turned on.

Operating System and Licensing

  • Windows 11 Enterprise SKUs (E3/E5) or qualifying education/business editions on a supported build. Windows 10 is not eligible for hotpatch.
  • Appropriate licensing: Microsoft 365 E3/E5, Windows 365 Enterprise, or similar subscriptions that include Windows Enterprise rights.
  • Devices must be enrolled in Windows Update for Business via Intune or managed by Windows Autopatch. Hotpatch delivery is orchestrated through these channels.

Hardware and Firmware

  • CPU virtualization extensions: Intel VT-x or AMD-V and second-level address translation (EPT/NPT) are mandatory.
  • UEFI firmware with Secure Boot enabled.
  • TPM 2.0 recommended but not strictly required for VBS itself; however, many security features and future updates may demand it.
  • For AMD processors, Zen 2 or newer supports Guest Mode Execute Trap (GMET), which replaces the older Restricted User Mode emulation and reduces performance impact. Intel Kabylake and later include Mode-Based Execution Control (MBEC).
  • DMA-capable IOMMU (VT-d or AMD-Vi) is needed for full DMA protection, though memory integrity can run with just Secure Boot.

Software Compatibility

  • All kernel-mode drivers must be signed and compatible with HVCI. Unsigned drivers or those making improper memory allocations will cause boot failures. Third-party antivirus, EDR, backup, and VPN agents are frequent offenders.
  • Applications that depend on kernel hooks or virtualization-based features may need updates. Test critical line-of-business software early.

How to Check Current VBS State at Scale

Automation is your friend. Use these methods to inventory your entire fleet.

PowerShell (WMI)

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

This returns a plethora of fields, but the key one is VirtualizationBasedSecurityStatus:
- 0: Not enabled
- 1: Enabled but not running (usually due to missing hardware features or a pending restart)
- 2: Enabled and running

MSInfo32
Run msinfo32.exe and look under System Summary for “Virtualization-based security.” It will list “Running,” “Enabled but not running,” or “Not enabled.”

Intune Reporting (if managed)
Intune can report device configuration status for VBS profiles, giving you a dashboard of compliance.

Collect these values into your CMDB and tag devices as ready, needs remediation, or incompatible. This inventory will drive your rollout rings.

Three Paths to Enable VBS Across the Enterprise

Microsoft supports three primary mechanisms. Intune is the recommended path for modern cloud-managed fleets; Group Policy serves traditional AD domains; registry edits are a last resort for corner cases or manual testing.

Intune (MDM/CSP)

Use either the Settings Catalog or a Custom OMA-URI profile. The relevant CSP is ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/ and ./Device/Vendor/MSFT/Policy/Config/VirtualizationBasedTechnology/.

Settings Catalog Method
1. Create a configuration profile, platform Windows 10 and later, profile type Settings Catalog.
2. Add settings from category “Virtualization Based Technology”:
- Virtualization Based Technology Hypervisor Enforced Code Integrity: choose “Enabled without UEFI lock” or “Enabled with UEFI lock” (the latter prevents local turn-off).
- Virtualization Based Security: set to “Enabled.”
3. If you also want Credential Guard and other features, enable them in the same profile.

Custom OMA-URI (if needed)
- ./Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity = 1
- ./Vendor/MSFT/Policy/Config/DeviceGuard/HypervisorEnforcedCodeIntegrity = 1
- Optionally set RequirePlatformSecurityFeatures and Locked as per your hardware.

Assign to a pilot device group first, monitor, then expand.

Group Policy

Navigate to Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security.

Set to Enabled. Under “Virtualization Based Protection of Code Integrity,” select either “Enabled without UEFI lock” or “Enabled with UEFI lock.” Couple this with Secure Boot enforcement. Apply to OUs with compatible hardware only.

Registry (Direct Keys)

Use these only if you can’t use policy. The relevant keys are:

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
EnableVirtualizationBasedSecurity = 1 (DWORD)
HypervisorEnforcedCodeIntegrity sub-key: Enabled = 1
RequirePlatformSecurityFeatures = 1 (Secure Boot) or 3 (Secure Boot + DMA)

A full set of registry commands is available in the Microsoft documentation. But be warned: direct registry changes are harder to manage, audit, and roll back.

The Arm64 Exception: Disable CHPE for Hotpatch

Arm64 devices (like the Surface Pro X or various Snapdragon laptops) have an extra requirement. The Compiled Hybrid PE (CHPE) compatibility layer, which allows x86 emulation, must be disabled for hotpatching to work. This is a one-time change that requires a restart.

Two ways to disable CHPE:
- Intune CSP: Set ./Device/Vendor/MSFT/Policy/Config/Hotpatch/DisableCHPE to 1.
- Registry: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\HotPatchRestrictions = 1 (DWORD).

The registry change takes effect after a reboot. Once done, the setting persists; you don’t need to reapply it.

Important: Disabling CHPE may degrade performance of x86 emulated apps because the hybrid PE optimizations are turned off. Microsoft recommends a careful pilot specifically for Arm64 fleets, including benchmarking the workloads that depend on x86 emulation. Some applications might need native ARM64 versions to perform acceptably.

Staged Rollout: Pilot, Rings, Production

Treat this as a major infrastructure change. A structured deployment minimizes business disruption.

  1. Inventory and Categorization
    Use the VBS status queries to segment devices into: already running, enabled but not running, capable but off, firmware update needed, incompatible.

  2. Remediate Hardware/Firmware
    For capable devices with missing prerequisites, push firmware and UEFI updates through your vendor tools. Ensure Secure Boot is on and virtualization is enabled in BIOS.

  3. Create Device Groups
    In Intune (or AD OUs), set up:
    - Pilot: 50–100 devices representing all major hardware models and software stacks.
    - Early Adopters: a larger group (5–10% of fleet) including more edge cases.
    - Broad Deployment: the rest, released in waves.

  4. Pilot Phase
    Assign the VBS configuration profile. Monitor system stability, application compatibility, and user-reported performance. Pay special attention to driver crashes in apps like VPN clients, graphics-intensive tools, and backup agents. Validate that hotpatch is being offered (check Windows Update history for hotpatch KBs).

  5. Rollback Testing
    Ensure you can recover a device if VBS breaks something. For Intune, simply remove the device from the profile assignment; the policy should revert on next sync (if not UEFI-locked). For registry-enforced settings, you’ll need a remediation script or manual intervention.

  6. Scale in Rings
    After a stable pilot, move to early adopters, then gradually to broad deployment, monitoring telemetry at each stage.

Monitoring and Verification

Once enabled, you need to confirm VBS is running and hotpatch is functioning.

  • Use the same WMI query or msinfo32 to check state. In Intune, create a custom compliance policy that flags any device where VirtualizationBasedSecurityStatus is not 2.
  • Check for hotpatch application: In Windows Update history or via Get-Hotfix, look for update packages labeled “Hot Patch” or those that don’t request a restart.
  • Intune’s quality update reports show patch installation and restart status.

The Dark Side: Performance, Compatibility, and Operational Risks

VBS isn’t free. The hypervisor adds a thin layer of overhead, and HVCI’s code integrity checks can impact certain workloads.

  • CPU Throughput: Benchmarks show a 1–5% performance hit for most business applications, but I/O-heavy tasks like gaming, video editing, or continuous integration builds can see drops of 10% or more. Measure your own key apps.
  • Gaming: Gamers have long complained about VBS reducing frame rates. If your fleet includes high-performance workstations for 3D rendering or data analysis, test thoroughly.
  • Driver Compatibility: This is the biggest risk. A single incompatible kernel driver can trigger a blue screen at boot. Ensure all hardware and software vendors explicitly support HVCI. Some older peripherals may never get updated drivers, forcing hardware replacement.
  • Battery Life: While generally small, some laptops may see a negligible reduction in battery life due to increased CPU usage. This is rarely a showstopper but is worth noting for mobile users.
  • Rollback Complexity: Although hotpatches reduce regular restarts, undoing a problematic hotpatch often requires a full reboot. And if you need to turn off VBS, you might need to disable Secure Boot, decryption, and then roll back policy—a multi-step process.

The Long Game: Hotpatch Benefits Justify the Effort

Despite these costs, the upside is compelling. Microsoft’s telemetry suggests organizations using hotpatch experience up to 45% fewer restart-induced disruptions per month. Security response times improve dramatically: a critical CVE can be neutralized within an hour, silently, without users logging off. For industries with strict uptime requirements—healthcare, manufacturing, financial services—that’s a transformation.

Moreover, VBS itself dramatically raises the barrier for attackers. With HVCI and Credential Guard, the attack surface shrinks, and stolen credentials become far less usable. The combination of VBS and hotpatching turns Windows into a much harder target.

Immediate Steps for IT Leaders

  1. Inventory Now: Run the WMI query across your fleet this week. Know your VBS readiness percentage.
  2. Prioritize Remediation: Address the low-hanging fruit—enable virtualization in BIOS, update firmware, turn on Secure Boot. These are quick wins.
  3. Start a Pilot: Pick a diverse set of 100 devices. Enable VBS via Intune, monitor for 30 days, fix issues.
  4. Plan Arm64 Separately: If you have Arm64 devices, schedule a parallel pilot with CHPE disabled. Communicate the emulation performance changes.
  5. Coordinate with Vendors: Reach out to your EDR, backup, and line-of-business software providers. Get their HVCI support statements and updated drivers.
  6. Build a Rollback Runbook: Document exactly how to revert VBS for each operating system and management tool version.

Hotpatching isn’t a distant future—it’s already here for Windows 11 Enterprise customers who meet the prerequisites. By making VBS enablement a top priority, you’re not just ticking a security checkbox; you’re unlocking a new era of near-zero-downtime patching. The work is significant, but the payoff is an always-on, always-secure endpoint that doesn’t interrupt your users’ day.