Windows VBS Explained: VTL1, Secure Kernel, HVCI and VBS Enclaves

Windows virtualization-based security (VBS) uses the Windows hypervisor to split one machine into two trust levels: VTL0, where the normal kernel and apps run, and VTL1, where a small secure kernel runs with memory the normal kernel cannot read or change. Memory integrity (HVCI), Credential Guard and VBS enclaves all build on that split.

The design starts from an unusual assumption. Microsoft's own description says VBS creates an isolated environment "that assumes the kernel can be compromised." Everything else in this post follows from that line: if the Windows kernel itself might be running hostile code, then the checks that decide which code may run, and the secrets that matter most, have to live somewhere the kernel cannot reach. VBS is that somewhere.

This guide goes one level deeper than our Credential Guard post and the security notes in our Windows 11 version history. It covers how the trust levels work, what they need, why some drivers break under HVCI, how defaults changed, and how to turn everything on safely.

Key takeaways

• VBS runs a secure kernel in Virtual Trust Level 1 (VTL1). The normal Windows kernel runs in VTL0. The hypervisor enforces the boundary with second level address translation (SLAT) page tables that VTL0 cannot edit.
• Memory integrity, also called hypervisor-protected code integrity (HVCI), moves kernel mode code integrity checks into VTL1. Kernel pages become executable only after passing those checks, and executable pages are never writable.
• Drivers that write to their own code, allocate executable pool memory or ship sections that are both writable and executable fail under HVCI. That is the main source of compatibility pain.
• Credential Guard, kernel mode hardware-enforced stack protection, System Guard Secure Launch, Kernel Data Protection, Hypervisor-enforced Paging Translation and VBS enclaves all depend on VBS.
• Memory integrity is on by default for clean installs of Windows 11 on compatible hardware. Credential Guard is on by default from Windows 11 22H2 and Windows Server 2025 for qualifying devices. Upgrades behave differently from clean installs, so check rather than assume.
• The vulnerable driver blocklist is enforced whenever HVCI, Smart App Control or S mode is active (except on Windows Server 2016), and is on by default since the Windows 11 2022 update.
• Check status with msinfo32 or Get-CimInstance Win32_DeviceGuard, read the Code Integrity event log for blocked drivers, and pilot before you enforce. Never turn memory integrity off fleet wide because of one old driver.

What is virtualization-based security?

VBS is a set of Windows security features built on the Windows hypervisor. When VBS is on, Windows itself boots as a guest of the hypervisor, even on a laptop that never runs a virtual machine. The hypervisor then gives that guest two separate execution environments with different privileges.

Virtual trust levels: VTL0 and VTL1

The Hyper-V Top Level Functional Specification (TLFS) calls the underlying hypervisor facility Virtual Secure Mode (VSM) and describes it as the base on which Device Guard, Credential Guard, virtual TPMs and shielded VMs are built. VSM creates isolation through Virtual Trust Levels:

• VTLs are hierarchical. VTL0 is the least privileged; VTL1 is more privileged than VTL0.
• The architecture allows up to 16 levels, but the TLFS states that "currently, only two VTLs are implemented."
• Each VTL has its own memory access protections, managed by the hypervisor, so software inside the partition cannot change them.
• A lower VTL can protect memory by handing it to a higher one. The TLFS example: VTL0 stores a secret in VTL1, after which only VTL1 can access it, even if VTL0 is compromised.

Each VTL also keeps its own private virtual processor registers and its own interrupt subsystem, so a lower level cannot read or disturb the higher level's state.

In plain terms: the normal Windows kernel, every driver you install and every application run in VTL0, keeping ring 0 and ring 3 as before. VTL1 sits beside them with its own kernel and user mode, and the hypervisor decides which physical pages each side may read, write or execute.

The secure kernel

VTL1 runs its own small kernel, the secure kernel. The Windows security book says VBS "uses hardware virtualization features to host a secure kernel separated from the operating system," and implements VTL1 with "higher privilege than the virtual trust level 0 (VTL0) implemented in the main kernel." The secure kernel does not replace the NT kernel. It hosts HVCI's code integrity decisions, manages protected memory for features like Kernel Data Protection, and loads the few signed processes that run in VTL1 user mode.

VTL1 user mode: where LSAIso and enclaves live

Two examples from Microsoft Learn show what runs in VTL1 user mode:

• The isolated LSA process. With Credential Guard on, lsass.exe talks over remote procedure calls to LSAIso.exe, which holds the secrets. Microsoft says it hosts no device drivers, only a small set of operating system binaries signed with a certificate VBS trusts and validated before launch.
• VBS enclaves. The enclave development guide states that "enclaves are a VTL1 user-mode process."

The code in VTL1 is kept small on purpose: the more code at the higher trust level, the larger the attack surface of the thing you rely on to stay clean.

How does the hypervisor enforce the boundary?

The mechanism is second level address translation. Microsoft's July 2020 blog post introducing Kernel Data Protection explains it, and every VBS feature relies on it. With SLAT on, address translation has two stages:

1. Stage 1, controlled by the guest kernel. A guest virtual address (GVA) becomes a guest physical address (GPA) through the page tables Windows manages.
2. Stage 2, controlled by the hypervisor. The GPA becomes a system physical address (SPA) through a second set of tables: extended page tables (EPT) on Intel, nested page tables (NPT) on AMD.

The stage 2 entries carry their own read, write and execute permissions, and only the hypervisor can edit them. If VTL0 code writes to a page that stage 2 marks read only, the processor raises an EPT or NPT violation and exits to the hypervisor, whatever the guest's own page tables say. The blog notes the worst case translation can take 20 table lookups, which processors soften with tagged TLB entries.

That is the whole trick: the Windows kernel's page tables stop being the final word on memory permissions.

What hardware and firmware does VBS need?

Microsoft's OEM VBS page lists the components that must be present and configured. The table below restates it.

One nuance on Secure Boot: the Credential Guard overview says that when default enablement turns VBS on, "Secure Boot is not a hard prerequisite for VBS to enter a running state, although it is recommended." Treat it as required anyway; Microsoft notes the VBS master key might not be protected by the TPM if Secure Boot is disabled. Our explainer on Secure Boot, Trusted Boot and Measured Boot covers what each of those steps checks.

When you enable VBS by policy, RequirePlatformSecurityFeatures set to 1 means Secure Boot only and 3 means Secure Boot with DMA protection. Microsoft recommends 1, because a machine without an IOMMU will not run VBS at all if you require DMA protection.

MBEC and GMET: why CPU generation matters

The memory integrity page names one more processor feature: Mode-Based Execution Control (MBEC) on Intel, available from Kaby Lake, and Guest Mode Execute Trap (GMET) on AMD, from Zen 2. As the name of the Intel feature suggests, they let execute permission depend on whether kernel or user mode code is running. Microsoft says memory integrity "works better" with them, and that older processors rely on an emulation called Restricted User Mode, which "will have a bigger impact on performance."

Microsoft does not publish a percentage for that impact, and it varies by workload. The honest approach is to measure it on your own hardware, which the step by step section below covers.

Which machines get memory integrity turned on automatically?

Supporting VBS and qualifying for automatic enablement are different things. Microsoft's memory integrity enablement page for OEMs lists the minimum hardware for memory integrity to be on by default:

The page adds two caveats. Auto-enablement applies to clean installs only, not upgrades. And Intel 11th generation Core desktop processors are not included in the default enablement logic, though Microsoft calls them a recommended platform that OEMs can enable.

VBS inside virtual machines

VBS works in VMs with nested virtualization or Guest VSM, which Microsoft says is on by default for Generation 2 VMs on Hyper-V and Azure. Inside a VM, memory integrity and Credential Guard protect against malware in the guest, not "from the host administrator," and the host can opt a VM out with Set-VMSecurity -VirtualizationBasedSecurityOptOut. Virtual Fibre Channel adapters and pass-through disks with AllowFullSCSICommandSet are not compatible with memory integrity.

What is HVCI, or memory integrity?

Memory integrity is the VBS feature most people meet first, usually through the Core isolation page in Windows Security. Microsoft notes it "is sometimes referred to as hypervisor-protected code integrity (HVCI) or hypervisor enforced code integrity, and was originally released as part of Device Guard." The Device Guard name survives only as the place where VBS and memory integrity settings live in Group Policy and the registry.

What kernel mode code integrity does on its own

Kernel mode code integrity (KMCI) is the Windows component that checks kernel drivers and system binaries before they load, and refuses unsigned or untrusted ones. Without VBS, KMCI runs inside the same kernel it protects. If an attacker gains kernel write access, the checker and its data are just more memory to tamper with.

What changes when it moves to VTL1

With memory integrity on, code integrity decisions move into the secure kernel. The Windows security book says HVCI moves "kernel code-integrity decisions into a hypervisor-protected environment," while kernel code still executes in the normal kernel. Enforcement runs through the stage 2 tables:

1. A driver image loads, and the secure kernel in VTL1 checks its signature against the code integrity policy.
2. Only if the check passes does the hypervisor mark those physical pages executable at stage 2.
3. Executable pages are never also writable. In Microsoft's words, kernel pages "are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable."
4. Pages VTL0 allocates later as writable data stay non-executable at stage 2, so injected code in a data buffer cannot run.

Microsoft adds that memory integrity protects the kernel Control Flow Guard bitmap from modification and protects the code integrity process itself. The result is a W^X rule (writable or executable, never both) that the kernel cannot override.

Why do some drivers fail under HVCI?

Any driver that depends on writable code breaks. Microsoft's driver compatibility page lists what to avoid: not opting in to NX by default, allocating executable pool instead of NonPagedPoolNx, sections that are both writable and executable, modifying executable system memory, dynamic code in the kernel, loading data files as executable, and section alignment that is not a multiple of 0x1000. One old pattern is handled for you: older WDK defaults marked the INIT section read, write and execute, and Windows 10 strips the write bit automatically.

Compatibility has been required for all drivers since the Windows 10 Anniversary Update (version 1607), and the HLK Hypervisor Code Integrity Readiness Test must pass before Microsoft signs a driver. Microsoft still lists where it has seen problems: anti-cheat software for games, third party input methods and third party banking password protection.

When an auto-enabled system meets an incompatible boot-critical driver, Microsoft says memory integrity is "silently turned off." OEM images can also set WasEnabledBy and EnabledBootId so memory integrity disables itself after crashes in the first boots following enablement; Microsoft advises high security systems not to set them.

How driver developers test for HVCI compatibility

Microsoft gives three steps, and says the third is imperative because static analysis cannot find every runtime violation:

1. Run Driver Verifier with the code integrity flag: verifier.exe /flags 0x02000000 /driver yourdriver.sys. A clean pass prints nothing; a failure reports, for example, that a caller specified an executable page protection.
2. Run the HyperVisor Code Integrity Readiness Test in the Windows Hardware Lab Kit.
3. Test the driver on a machine with VBS and memory integrity on, exercising every code path.

If you ship kernel drivers, put step 1 and step 3 in your release pipeline, not only in certification.

Which other features run on VBS?

Memory integrity is one tenant of VTL1. The table later in this post summarises all of them; here is what each one does, from Microsoft's own docs.

Credential Guard

Credential Guard keeps NTLM password hashes, Kerberos Ticket Granting Tickets and credentials stored by applications as domain credentials in LSAIso.exe in VTL1. Microsoft says malware "running in the operating system with administrative privileges can't extract secrets that are protected by VBS," which blocks pass the hash and pass the ticket theft from LSASS memory.

Its documented limits matter just as much. It does not protect the Active Directory database, the SAM, local or Microsoft accounts, Kerberos service tickets, credentials typed into NTLM prompts, or against key loggers and physical attacks, and it "doesn't prevent an attacker with malware on the PC from using the privileges associated with any credential." With it on, NTLMv1, MS-CHAPv2, Digest and CredSSP lose single sign-on, and Kerberos unconstrained delegation and DES stop working. Microsoft advises against it on domain controllers. Our Credential Guard post covers developer machines.

Added LSA protection is a different mechanism: it runs lsass.exe as a protected process and does not need VBS. Microsoft says it is on by default for new installs of Windows 11 22H2 and later.

Kernel mode hardware-enforced stack protection

This gives every kernel stack a hardware-protected shadow stack. On each CALL and RET the return address is checked against the shadow copy, and on a mismatch Windows stops with a blue screen rather than follow a hijacked return. It targets return oriented programming in the kernel and pairs with Control Flow Guard for indirect calls.

Requirements per Microsoft: the Windows 11 2022 update or newer, Intel CET or AMD shadow stacks (11th Gen Intel Core mobile or AMD Zen 3 and newer), and VBS with HVCI on. It is off by default, and it will not turn on while a driver from its own incompatible list is installed.

System Guard Secure Launch and SMM protection

Secure Launch, first introduced in Windows 10 version 1809, uses a Dynamic Root of Trust for Measurement (DRTM). The machine boots through normal UEFI Secure Boot, then the processor is forced into a hardware-controlled trusted state before the hypervisor and secure kernel start, so a measurement of the launch is taken from a known clean point. Microsoft says this keeps a rootkit that slipped past UEFI Secure Boot from reaching secrets and critical code in the VBS environment. SMM protection builds on Secure Launch and needs it. Secure Launch requires TPM 2.0; it does not support TPM 1.2. Our DRTM explainer walks through the late launch mechanism in more depth.

Kernel Data Protection

HVCI protects code. Kernel Data Protection (KDP), announced on Microsoft's security blog on 8 July 2020, protects data. Static KDP lets a driver call MmProtectDriverSection to make part of its own image read only to all of VTL0. Dynamic KDP lets a driver allocate read only memory from a secure pool managed by the secure kernel, through ExAllocatePool3. Microsoft states this memory "is always verified by the secure kernel (VTL1) and protected using second level address translation (SLAT) tables by the hypervisor," so nothing in the NT kernel can modify it.

Hypervisor-enforced Paging Translation

The Windows security book describes Hypervisor-enforced Paging Translation (HVPT) as enforcing the integrity of guest virtual to guest physical address translations, to protect critical system data from "write-what-where" attacks. It appears as value 7 in the SecurityServicesConfigured and SecurityServicesRunning fields of Win32_DeviceGuard.

Secured-core PCs

Secured-core PCs are a device category, not a feature. Microsoft's security book says they ship with VBS and HVCI on, Kernel DMA Protection, and System Guard Secure Launch with SMM isolation. The Pluton post covers the hardware root of trust underneath.

What are VBS enclaves?

VBS enclaves bring VTL1 isolation to application developers. Microsoft defines a VBS enclave as "a software-based trusted execution environment inside the address space of a host application." The sensitive part of an application, for example code that handles keys or decrypts user data, runs in the enclave. Its memory is isolated from the host process and from the rest of the system, including VTL0 administrators and the VTL0 kernel.

Requirements

Microsoft's page carries a warning to review the OS support list "as support has recently changed," so confirm the build numbers again before you plan around them.

How an enclave is built and loaded

From the VBS enclave development guide:

1. The enclave is a DLL. Functions the host calls must be exported as LPENCLAVE_ROUTINE.
2. It must be linked with /INTEGRITYCHECK, because its signature is checked at load time.
3. veiid.exe binds the enclave's imports to known IDs for platform DLLs, so a malicious signed DLL with the same name cannot load in its place.
4. The DLL is signed. Test signing works during development; production signing uses the VBS enclave certificate profile in Trusted Signing, and the signature determines the enclave's Author ID.
5. The host loads it with CreateEnclave and InitializeEnclave. Debugging must be allowed at creation with ENCLAVE_VBS_FLAG_DEBUG; production enclaves are hidden from debuggers.

Microsoft also publishes a VBS Enclaves SDK with code generation from .edl files, samples, and a Rust crate.

Where enclaves fit and where they do not

An enclave protects data in use from a compromised VTL0. It does not make the enclave code correct. A memory safety bug inside the enclave, or an interface that hands secrets back to the host on request, defeats the purpose. Keep the enclave interface narrow, validate everything that crosses it, and treat every library you compile into the enclave as part of your trusted computing base.

How did VBS defaults change across Windows releases?

Defaults are where most confusion comes from, because clean installs, upgrades, editions and licences all differ. The timeline below uses only dates and versions stated on Microsoft pages fetched for this post.

Details that change real outcomes:

• Upgrades are not clean installs. Memory integrity auto-enablement applies to clean installs only, so an upgraded machine may be running with it off.
• Explicit settings win. If Credential Guard was explicitly disabled before the upgrade, default enablement does not overwrite that.
• Credential Guard is licensed. Microsoft lists Enterprise and Education as supported (Enterprise E3 and E5, Education A3 and A5), and Pro as not.
• Windows Server is opt in for memory integrity. The auto-enablement logic Microsoft documents is for client installs, so turn it on deliberately on servers.

How does the vulnerable driver blocklist relate to HVCI and App Control?

HVCI checks that kernel code is signed and unmodified. It does not decide whether a signed driver is safe. Microsoft's driver block rules page explains the gap: attackers "are turning to exploit vulnerabilities in legitimate and signed kernel drivers." A properly signed driver with a known flaw passes code integrity, loads, and can then be misused.

The vulnerable driver blocklist closes part of that gap. It is an App Control for Business deny policy listing drivers with known vulnerabilities that allow kernel privilege escalation, malicious drivers or certificates used to sign malware, and drivers whose behaviour circumvents the Windows security model even if not malicious.

How it ties together, per Microsoft:

• Since the Windows 11 2022 update, the blocklist is enabled by default for all devices and can be switched in the Windows Security app.
• Except on Windows Server 2016, the blocklist is also enforced whenever memory integrity, Smart App Control or S mode is active.
• The in-box blocklist is updated quarterly and also delivered through monthly Windows updates.
• The downloadable version is usually more complete than the in-box one. Deploy it as an App Control policy in audit mode first, then enforce; event ID 3099 in the CodeIntegrity Operational log confirms it applied, and running drivers are only blocked after a reboot.
• Microsoft says plainly that the blocklist "isn't guaranteed to block every driver found to have vulnerabilities," because it balances security against compatibility.

App Control for Business can also turn memory integrity on through its policy options (Set-HVCIOptions, or the Hypervisor-protected Code Integrity rule in the App Control Wizard). Microsoft notes that if an App Control policy turns memory integrity on, it is on even when that policy is in audit mode. Our post on Smart App Control and unsigned binaries covers the user mode side of the same policy engine.

Feature comparison: what each VBS feature protects

Step by step: check VBS and HVCI, find incompatible drivers, enable and verify

Run these in an elevated PowerShell session. Read the warnings: turning on memory integrity changes how the kernel loads drivers, and an incompatible boot-critical driver can stop a machine from booting.

Step 1: Check the current state

The quickest view is System Information. Run msinfo32, and at the bottom of System Summary read "Virtualization-based security", "Virtualization-based security Services Configured" and "Virtualization-based security Services Running". If memory integrity is on, "Services Running" includes "Hypervisor enforced Code Integrity".

For scripts and fleets, query the WMI class Microsoft documents:

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

The numeric arrays are easier to read decoded. This uses the value tables from Microsoft's memory integrity page:

$dg = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

$vbsState = @{0 = 'VBS not enabled'; 1 = 'VBS enabled but not running'; 2 = 'VBS enabled and running'}
$services = @{
  1 = 'Credential Guard'
  2 = 'Memory integrity (HVCI)'
  3 = 'System Guard Secure Launch'
  4 = 'SMM Firmware Measurement'
  5 = 'Kernel-mode Hardware-enforced Stack Protection'
  6 = 'Kernel-mode Hardware-enforced Stack Protection (audit)'
  7 = 'Hypervisor-Enforced Paging Translation'
}
$props = @{
  1 = 'Hypervisor support'; 2 = 'Secure Boot'; 3 = 'DMA protection'
  4 = 'Secure Memory Overwrite'; 5 = 'NX protections'; 6 = 'SMM mitigations'
  7 = 'MBEC/GMET'; 8 = 'APIC virtualization'
}

"VBS:        " + $vbsState[[int]$dg.VirtualizationBasedSecurityStatus]
"Available:  " + (($dg.AvailableSecurityProperties | Where-Object { $_ -ne 0 } | ForEach-Object { $props[[int]$_] }) -join ', ')
"Configured: " + (($dg.SecurityServicesConfigured | Where-Object { $_ -ne 0 } | ForEach-Object { $services[[int]$_] }) -join ', ')
"Running:    " + (($dg.SecurityServicesRunning | Where-Object { $_ -ne 0 } | ForEach-Object { $services[[int]$_] }) -join ', ')

If "MBEC/GMET" is missing from the available list on a machine you plan to enable, expect the Restricted User Mode emulation path and test performance more carefully.

For deeper troubleshooting, SkTool.exe in the bin folder of recent Windows SDKs shows hypervisor and VBS state and why VBS did or did not start.

Step 2: Build a driver inventory

You cannot judge compatibility without knowing what is loaded. Start with a list of drivers and third party driver packages:

# Every installed driver service with its state and path
driverquery /v /fo csv | ConvertFrom-Csv |
  Select-Object 'Module Name', 'Display Name', 'State', 'Path' |
  Export-Csv -NoTypeInformation .\drivers-$env:COMPUTERNAME.csv

# Third party driver packages in the driver store (oem*.inf)
pnputil /enum-drivers > .\driver-packages-$env:COMPUTERNAME.txt

Collect the same files from a sample of each hardware model and software build in your fleet. The vendors and versions in the driver package list are what you will check against vendor release notes and the vulnerable driver blocklist.

Step 3: Look for drivers memory integrity has already blocked or flagged

Memory integrity writes to the Code Integrity operational log, and Microsoft says compatibility events generally use event ID 3087:

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
  Id      = 3087
} -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message |
  Format-List

On a fresh image where memory integrity did not turn on by itself, search setup's setupact.log for HVCI. A line such as SYSPRP HVCI: Compatibility did not pass. VBS_COMPAT_ISSUES 0x... carries a bitmask: 0x2 means SLAT required, 0x8 IOMMU required, 0x10 MBEC or GMET required, 0x80 the ACPI WSMT table required.

Windows Security also lists incompatible drivers on the Core isolation page. For each one, look for a newer vendor version first, and remove software you no longer need.

Step 4: Pilot on a test ring

Microsoft's own instruction is to enable these features on a group of test computers before users' computers. Pick at least one machine of each hardware model and each standard software build, including the oldest CPUs you still support.

Before you enable, record a baseline for the workloads that matter: build times for developer machines, frame rates and input latency for graphics and gaming, VM density for Hyper-V hosts, and start-up time for line of business apps. Run the same measurements after. On processors without MBEC or GMET, Microsoft says the impact is bigger, so treat those as a separate group.

Step 5: Enable memory integrity

Warning: an incompatible boot-critical driver can cause a blue screen during or after enablement. Confirm the machine is in your pilot group, that you have a recovery path (Windows RE access and, if BitLocker is on, the recovery key), and that Steps 2 and 3 found nothing unresolved.

Group Policy: Computer Configuration, Administrative Templates, System, Device Guard, "Turn on Virtualization Based Security", Enabled, with "Virtualization Based Protection of Code Integrity" set to "Enabled without UEFI lock". UEFI lock stops policy or registry changes from turning it off, so save it for after the pilot.

Intune: settings catalog, Virtualization Based Technology, Hypervisor Enforced Code Integrity.

Registry, Microsoft's recommended set without UEFI lock:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f

Leave the Mandatory value unset: with it, any failure of the hypervisor or secure kernel to load means the machine refuses to boot. Then restart (on domain-joined machines using Group Policy, run gpupdate /force first).

Step 6: Verify after reboot

Run the decoding script from Step 1 again. You want "VBS enabled and running" and "Memory integrity (HVCI)" in the Running list. Then check the Code Integrity log for new 3087 events, exercise the hardware on the machine (docks, printers, audio interfaces, VPN clients, security keys), and repeat your performance baseline.

If a machine fails to boot, Microsoft's recovery path is: disable the policy that enables VBS and memory integrity (for example the GPO), boot into Windows RE, set the memory integrity value to 0, and restart:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

Microsoft's page links to the Windows RE technical reference for getting into the recovery environment; make sure the change lands in the installed system's registry, not the recovery environment's own. If you enabled memory integrity with UEFI lock, you must also turn off Secure Boot to complete recovery.

Step 7: Add the optional layers

Once memory integrity is stable:

• Turn on kernel mode hardware-enforced stack protection where the CPU supports it (Windows Security, Core isolation details, or the enforcement mode option under "Turn on Virtualization Based Security"). Check its incompatible driver list first.
• On Enterprise and Education devices, confirm Credential Guard is running and that nothing still needs NTLMv1, MS-CHAPv2 Wi-Fi or VPN, Digest, CredSSP single sign-on or unconstrained delegation. Microsoft recommends moving Wi-Fi and VPN to EAP-TLS or PEAP-TLS.
• Where hardware supports it, enable System Guard Secure Launch (DeviceGuard ConfigureSystemGuardLaunch policy, Group Policy, or the Firmware protection toggle) and verify it in msinfo32.
• For a newer vulnerable driver blocklist than the in-box one, deploy Microsoft's downloadable policy in audit mode, review the events, then enforce.

Step 8: Keep it on

Make VBS state part of compliance reporting. Re-run the WMI check after feature updates, firmware updates and new hardware models, and watch for new 3087 events when peripheral software arrives.

Common mistakes

Turning memory integrity off fleet wide because of one old driver. Update or remove the driver, or exclude that hardware model while you wait for the vendor. Disabling HVCI everywhere removes one of the paths that enforces the vulnerable driver blocklist, and takes away kernel mode stack protection and VBS enclaves, which both require HVCI.

Assuming VBS stops all kernel attacks. HVCI stops unsigned or modified code from running in the kernel. A signed driver with a known flaw still loads unless the blocklist or your App Control policy stops it. Data-only corruption outside KDP, firmware flaws, physical access and misuse of legitimate privileges are outside its scope. Microsoft's own Credential Guard page says to "incorporate other security strategies and architectures."

Treating "enabled" as "running". VirtualizationBasedSecurityStatus of 1 means enabled but not running, often because DMA protection is required on hardware without an IOMMU, or virtualization is off in firmware. Check the Running list.

Ignoring performance testing on older CPUs. Processors without MBEC or GMET use Restricted User Mode emulation, which Microsoft says costs more. Measure real workloads on your oldest supported models first.

No driver inventory. Without a driver list per hardware model and software build, every incompatibility is found by a user. Inventory first, then enable.

Assuming upgrades got the new defaults. Memory integrity auto-enablement is for clean installs, and Credential Guard default enablement skips devices where it was explicitly disabled before the upgrade. Measure each device.

Forgetting the build machines. Developer workstations and build agents run hypervisors, emulators, kernel debuggers and USB tooling. Test them as their own ring and keep exceptions documented and time limited.

FAQ

Is VBS the same as Hyper-V?

No. VBS uses the Windows hypervisor, which is also what Hyper-V uses for virtual machines, but VBS does not need the Hyper-V role or any VMs. When VBS is on, the Windows hypervisor starts at boot and runs Windows itself with two trust levels.

What is the difference between VTL0 and VTL1?

VTL0 is where the normal Windows kernel, drivers and applications run. VTL1 is a more privileged trust level running the secure kernel and a few signed user mode processes. The hypervisor enforces memory permissions so VTL0 cannot read or modify memory that VTL1 protects.

How do I check if HVCI is running?

Run msinfo32 and look for "Hypervisor enforced Code Integrity" under "Virtualization-based security Services Running", or run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard and check that SecurityServicesRunning contains 2.

Why can't I turn on memory integrity?

Usually an incompatible driver. Windows Security lists the drivers blocking it on the Core isolation page. Other causes are virtualization disabled in firmware, a CPU without SLAT, or a policy requiring DMA protection on hardware without an IOMMU. SkTool.exe from the Windows SDK reports why VBS did not start.

Does memory integrity slow down games or builds?

It can, mostly on processors without MBEC (Intel before Kaby Lake) or GMET (AMD before Zen 2), where Windows emulates the feature. Microsoft does not publish a fixed figure. Measure your own workloads before and after on each hardware model.

Does Credential Guard need Windows Enterprise?

Microsoft lists Windows Enterprise and Education as supported editions, with licence entitlements from Enterprise E3 and E5 and Education A3 and A5. Pro and Pro Education/SE are listed as not supported, though a Pro device that previously ran Credential Guard may still have it on.

Is the vulnerable driver blocklist on by default?

Yes, since the Windows 11 2022 update, for all devices, and you can toggle it in Windows Security. It is also enforced whenever memory integrity, Smart App Control or S mode is active, except on Windows Server 2016.

What do I need to build a VBS enclave?

Windows 11 build 26100.2314 or later or Windows Server 2025 with VBS and HVCI on, Visual Studio 2022 17.9 or later, Windows SDK 10.0.22621.3233 or later, and a Trusted Signing account for production signing.

Why software supply chain hygiene still matters here

Firmware, drivers and enclaves are all software someone builds from components. If your team ships a Windows driver, an enclave DLL or the app that hosts it, the libraries compiled into them carry known vulnerabilities and fixes like any other code, and keeping them current is part of keeping VTL1 trustworthy.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To be plain about the fit: Safeguard does not configure Windows, manage devices, scan drivers or firmware, or protect endpoints. VBS, HVCI and Credential Guard are Windows features you turn on with Microsoft's tools. Where Safeguard helps is the software your own teams build around them: the services, desktop apps, enclave host apps and build tooling. It scans repositories, container images and SBOM files for dependencies, matches them against vulnerability data and shows which projects contain a given component and version. Gold Open Source at gold.safeguard.sh gives free CVE intelligence with affected and fixed versions for those components.

The first demo is a real CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies when the app that hosts your enclave, or the tooling that signs and packages it, pins an outdated library.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. Driver and enclave projects often live in internal repositories on Windows build machines that never leave the corporate network, and the runner scans them where they are built.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is a way to ask which of your projects carry a given library version on the day an advisory lands, with tool permissions you set.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Microsoft Learn: Virtualization-based Security (VBS), OEM requirements
• Microsoft Learn: Enable virtualization-based protection of code integrity
• Microsoft Learn: Memory integrity and VBS enablement (OEM)
• Microsoft Learn: Driver compatibility with memory integrity and VBS
• Microsoft Learn: Memory integrity and virtualization-based security (driver bring-up)
• Microsoft Learn: Hyper-V TLFS, Virtual Secure Mode
• Microsoft Learn: Windows security book, Silicon assisted security
• Microsoft Learn: Credential Guard overview
• Microsoft Learn: How Credential Guard works
• Microsoft Learn: Configure Credential Guard
• Microsoft Learn: Credential Guard considerations and known issues
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Microsoft recommended driver block rules
• Microsoft Learn: Kernel Mode Hardware-enforced Stack Protection
• Microsoft Learn: System Guard, how a hardware-based root of trust helps protect Windows
• Microsoft Learn: System Guard Secure Launch and SMM protection
• Microsoft Learn: Kernel DMA Protection
• Microsoft Learn: Virtualization-based security (VBS) enclaves
• Microsoft Learn: VBS enclaves development guide
• Microsoft Security blog: Introducing Kernel Data Protection (8 July 2020)

Last reviewed: 25 October 2026. Microsoft notes that VBS enclave OS support recently changed; check the linked Learn pages for current build requirements.