Windows VBS and HVCI: How Memory Integrity Works

Updated on Oct 24, 2026

10 min read

Windows virtualization-based security (VBS) and hypervisor-protected code integrity (HVCI) add a hardware-backed boundary around parts of the operating system that malware may try to change. Windows administrators, security teams, and PC owners need to know what this boundary protects, what driver compatibility means, and how to verify that memory integrity is actually running. This guide explains the relationship between VBS and HVCI and how to deploy the feature without treating one setting as a complete security solution.

Why VBS and HVCI Are Being Discussed

Modern Windows devices increasingly rely on security features that use processor virtualization, firmware settings, and operating-system policy together. Memory integrity is visible in Windows Security, can be managed through Group Policy or device management, and may be enabled by default on supported devices. The Windows security documentation places VBS among the platform’s hardware security controls.

The controls matter because kernel code runs with broad privileges. A vulnerable or untrusted kernel driver can undermine protections that ordinary applications cannot. VBS creates an isolated execution environment, while HVCI uses that boundary to protect decisions about kernel-mode code. Their impact depends on the device’s processor, firmware, drivers, Windows edition, and management policy, so administrators should assess compatibility before a broad rollout.

What Are VBS and HVCI?

Virtualization-based security (VBS) uses hardware virtualization and the Windows hypervisor to create an isolated environment. Windows can run selected security functions in that environment so they are better separated from the normal operating-system kernel. Microsoft describes this architecture in its VBS documentation for device makers.

Hypervisor-protected code integrity (HVCI) is the older and still widely used name for memory integrity, a VBS feature. It moves kernel-mode code-integrity enforcement into the isolated environment. Windows checks kernel drivers and other kernel binaries against its code-integrity policy before allowing them to load, and memory-integrity protections restrict how kernel memory can become executable. This makes it harder for compromised kernel code to alter the rules that determine which code may run.

VBS is the isolation foundation; HVCI is one security service that uses it. VBS can also support other features, such as Credential Guard, when the device and configuration meet their requirements. The names Device Guard, virtualization-based protection of code integrity, HVCI, and memory integrity appear in older settings and current documentation, but they do not all refer to the same layer: Device Guard was an earlier umbrella label, VBS is the platform capability, and memory integrity is a VBS service.

Aspect	VBS	HVCI / memory integrity
Role	Creates a hypervisor-isolated security environment	Uses that environment to protect kernel code-integrity enforcement
Main boundary	Separates selected security work from the normal kernel	Helps prevent untrusted kernel code from loading and restricts executable kernel memory
Relationship	Platform capability that can host multiple security services	One service that depends on VBS
User-facing setting	Usually managed through device security or policy	Shown as Memory integrity in Windows Security

The Problem VBS and HVCI Solve

The Windows kernel and its drivers have more privilege than user applications. A driver that can run kernel code can interact with sensitive memory and system resources. Traditional code-integrity checks help, but placing every decision in the same environment as the kernel creates a problem: if that environment is compromised, an attacker may try to tamper with the checks or their results.

VBS changes the trust arrangement. The Windows hypervisor establishes a separate virtual security environment, and selected security code runs there. HVCI uses this boundary to protect kernel-mode code-integrity checks and restrict certain unsafe memory transitions. The goal is not to make Windows invulnerable; it is to make it harder for a compromise in the normal kernel to defeat these specific controls.

Firmware and hardware are part of this chain. Virtualization support, second-level address translation, suitable firmware, and Secure Boot help establish the environment. Microsoft’s memory integrity guidance warns that some drivers and applications are incompatible and may malfunction when the feature is enabled. NIST’s Platform Firmware Resiliency Guidelines provide broader guidance for protecting and recovering platform firmware; they are useful context for the boot foundation, not a VBS configuration standard.

How VBS and HVCI Work

At startup, Windows checks whether the device and firmware can support the requested virtualization-based features. If enabled and supported, the Windows hypervisor creates a protected environment alongside the regular operating system. This is not a conventional virtual machine with a separate user desktop; it is an isolation boundary managed by the host operating system.

The normal Windows kernel continues to run applications and drivers. A more privileged secure kernel operates in the isolated environment and helps enforce security decisions. With HVCI enabled, code-integrity enforcement runs within this protected context. When a kernel driver or other kernel-mode binary is loaded, Windows applies the configured code-integrity policy. Memory integrity also restricts kernel memory so that executable pages cannot simply be rewritten as ordinary writable data and then executed.

The layers matter:

Firmware and processor support provide virtualization extensions and the memory protections required by the platform.
The hypervisor creates the isolated virtual security environment.
VBS services, such as HVCI, use that environment to protect specific security decisions or assets.
Windows policy and compatible drivers determine which code can load and whether the feature can run reliably on a particular system.

VBS and HVCI can run on some virtual machines, but the VM must expose suitable virtualization support, such as nested virtualization or Guest VSM. A virtual machine that merely has a virtual TPM does not automatically have the hypervisor capabilities required for memory integrity.

Components and Key Concepts

Virtualization support and firmware

VBS depends on a 64-bit processor with virtualization extensions and second-level address translation. Firmware must provide compatible memory reporting, and Secure Boot is part of the supported platform configuration. Device makers also need to test firmware and drivers against these requirements. The precise prerequisites can vary by feature and deployment, so a device reporting that virtualization is enabled does not by itself prove that HVCI is active.

Code Integrity and drivers

Code Integrity is Windows’ mechanism for applying trust policy to kernel-mode code. HVCI protects the enforcement environment, but it does not make every driver compatible or decide whether an organization’s driver policy is appropriate. Older drivers, low-level utilities, and software that depends on unsupported kernel behavior can be blocked or behave unexpectedly. Microsoft recommends testing drivers with memory integrity enabled, not relying solely on static analysis or a successful installation.

Policy and UEFI lock

Memory integrity can be managed locally, with Group Policy, or with mobile-device management. A policy can enable HVCI without a UEFI lock, which is generally easier to adjust remotely during a pilot. A UEFI lock makes remote policy changes less able to disable the protection; it also makes recovery and policy changes more involved. Treat that lock as an operational decision, not as a default checkbox.

Performance and compatibility

VBS uses processor and memory resources, and the impact varies by workload and hardware. Modern processor support can reduce overhead, while older processors may rely on less efficient execution paths. Driver blocks, virtualization conflicts, and startup changes can be more important than a small average performance difference. Measure real workloads and review device-specific compatibility data rather than assuming a universal performance penalty or guarantee.

Real-World Use Cases

Managed Windows endpoints: Organizations can use HVCI as one layer in a baseline that also includes application control, endpoint protection, and patch management.
Systems with sensitive credentials: VBS can host credential-protection features such as Credential Guard, which are separate from HVCI but use the same general isolation foundation.
High-assurance workstations: Administrators can test memory integrity against approved drivers and line-of-business applications before enforcing the setting across a larger fleet.
Virtual desktops and cloud VMs: VBS is possible where the hypervisor exposes the necessary virtualization functions. Administrators should verify host and guest support instead of assuming that a VM setting alone enables the feature.

For controls that govern which applications and drivers are allowed, see the site’s guide to Windows Defender Application Control. For the earlier boot trust boundary, see UEFI Secure Boot and TPM-measured boot.

Getting Started: Check and Enable Memory Integrity

Start with a compatibility check and a recovery plan, especially on managed or encrypted devices. Confirm that important data is backed up, BitLocker recovery keys are available where applicable, and the help desk knows how to respond to a driver block or boot issue.

Check the current state

In an elevated PowerShell session, query the Windows Device Guard status class:

Get-CimInstance `
  -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

The output distinguishes configured security services from services that are running. VirtualizationBasedSecurityStatus reports whether VBS is off, enabled but not running, or running. If the class is unavailable or the result is unexpected, use System Information (msinfo32) and check Virtualization-based security status, then review device firmware and policy.

Enable it on a supported device

For an individual PC, open Windows Security > Device security > Core isolation details and switch on Memory integrity if the control is available. Restart Windows when prompted, then repeat the status check. If the option is missing or Windows reports an incompatible driver, identify the driver and obtain a compatible version from its device or software vendor before trying again.

For managed devices, configure Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security and set Virtualization Based Protection of Code Integrity to enabled. Begin a rollout without UEFI lock so administrators can adjust policy during testing. Intune administrators can use the Virtualization Based Technology > Hypervisor Enforced Code Integrity setting; the VirtualizationBasedTechnology Policy CSP documents the managed policy values and their UEFI-lock behavior. Apply policy, restart affected devices, and verify the running state rather than assuming policy delivery means activation.

Validate and troubleshoot

Pilot with representative hardware, drivers, and workloads. After restart, inspect the Device Guard status again and review Event Viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational for code-integrity events. If a driver is blocked, update or replace the driver; do not weaken the fleet-wide policy just to silence an isolated warning. If the device becomes unstable, follow the organization’s recovery procedure and use the documented policy or local recovery path.

Common Misconceptions

“VBS and HVCI are two names for the same setting.” VBS is the isolation platform. HVCI, shown as Memory integrity, is a service that uses it. A device can have VBS capabilities without every VBS service being enabled.

“Memory integrity protects the whole computer from every kernel attack.” It hardens code-integrity enforcement and related memory protections. It does not replace patching, application control, endpoint detection, backups, or secure configuration, and it does not prevent every kind of kernel compromise.

“If the policy says enabled, the feature must be running.” Hardware or firmware limitations, incompatible drivers, and pending restarts can prevent a configured feature from running. Verify runtime status and review events after deployment.

Changelog

Initial publication.

Last updated: 2026-10-24