How to Configure Credential Guard, Virtualization-Based Security (VBS), and LSA Protection in Windows 11

Architectural Foundation of Virtualization-Based Security and LSA Isolation

Lateral movement techniques—such as Pass-the-Hash, Pass-the-Ticket, and credential dumping using tools like Mimikatz—have historically compromised enterprise Active Directory domains. Under the legacy Windows architectural model, the Local Security Authority Subsystem Service (lsass.exe) executed directly inside standard userland memory. Even though lsass.exe ran under privileged SYSTEM context, any attacker who acquired local administrative privileges or kernel-level code execution could read volatile RAM, dump process memory, and extract NTLM password hashes, Kerberos Ticket-Granting Tickets (TGTs), and DPAPI master keys.

In Windows 11 Enterprise and Pro editions, Microsoft neutralizes this threat vector using Virtualization-Based Security (VBS) and Credential Guard. Operating beneath the standard operating system, the Windows Hypervisor partitions hardware memory into two cryptographically isolated execution environments known as Virtual Trust Levels (VTL):

• Virtual Trust Level 0 (VTL 0 – Normal World): Houses the standard Windows kernel, device drivers, and applications, including the proxy process lsass.exe.
• Virtual Trust Level 1 (VTL 1 – Secure World): An isolated microkernel running secure “trustlets”, completely invisible to VTL 0. Credential Guard moves sensitive credential storage into the isolated LSA process LsaIso.exe inside VTL 1.

Whenever an authentication handshake occurs, the VTL 0 proxy dispatches a Remote Procedure Call (RPC) across the hypervisor boundary. The cryptographic validation executes inside VTL 1, returning only authorization tokens back to VTL 0. Because hypervisor Second Level Address Translation (SLAT / Intel EPT / AMD NPT) enforces strict memory segmentation, even an attacker possessing full SYSTEM or kernel rootkit privileges in VTL 0 is mathematically prohibited from reading VTL 1 memory.

Security Mechanism	Kernel Execution Tier	Hostile Privilege Mitigation	Protected Credential Types
Standard Windows Auth	VTL 0 Userland (lsass.exe)	Vulnerable to SYSTEM / Admin dumps	None; plaintext and hashes readable
LSA Protection (RunAsPPL)	VTL 0 Protected Process Light	Blocks non-PPL debuggers and injection	Protects against un-signed code injection
Credential Guard (VBS)	VTL 1 Secure Trustlet (LsaIso.exe)	Hardware-isolated from VTL 0 Kernel	NTLM hashes, Kerberos TGTs, DPAPI master keys

Hardware and Firmware Prerequisites

Because Credential Guard relies upon hypervisor micro-architecture, endpoints must satisfy rigorous hardware baselines:

• 64-bit CPU: Intel Core 8th Gen+ or AMD Zen 2+ supporting hardware virtualization (Intel VT-x / AMD-V) and Extended Page Tables (SLAT).
• Trusted Platform Module (TPM): TPM 2.0 configured and provisioned in UEFI.
• UEFI Secure Boot: Enabled in firmware to prevent bootkit tampering with hypervisor loaders.
• Hypervisor-Protected Code Integrity (HVCI): Compatible memory architecture (Memory Integrity).

Configuring Credential Guard via Group Policy

While Windows 11 Enterprise (22H2 and later) enables Credential Guard by default on compliant hardware, domain administrators enforce and lock this policy using Group Policy Objects (GPO):

1. Open the Local Group Policy Editor (gpedit.msc) or GPMC on a Domain Controller.
2. Navigate to:
   Computer Configuration > Administrative Templates > System > Device Guard.
3. Double-click Turn On Virtualization Based Security and set it to Enabled.
4. Under the Options configuration panel:
   • Select Platform Security Level: Select Secure Boot and DMA Protection.
   • Virtualization Based Protection of Code Integrity: Select Enabled with UEFI lock (prevents malware or rogue administrators from modifying registry keys to disable protection).
   • Credential Guard Configuration: Select Enabled with UEFI lock.
   • Secure Launch Configuration: Select Enabled (enforces Dynamic Root of Trust for Measurement / DRTM).
5. Click Apply and restart the workstation.

Enforcing Additional LSA Protection (RunAsPPL) via Registry

To supplement Credential Guard and block un-signed DLL injection into the VTL 0 proxy, enforce Protected Process Light (PPL) on the Local Security Authority:

# 1. Enable LSA Protection with UEFI variable lock
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name "RunAsPPL" -Value 1 -PropertyType DWord

# 2. Configure Credential Guard activation flag (1 = Enabled without lock, 2 = Enabled with UEFI lock)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" `
    -Name "EnableVirtualizationBasedSecurity" -Value 1 -PropertyType DWord

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name "LsaCfgFlags" -Value 1 -PropertyType DWord

# 3. Force Group Policy refresh
gpupdate /force

Auditing Active Credential Guard Deployment

Verify that VBS and Credential Guard are running and actively defending memory space using native diagnostic tools.

Step 1: Check System Information (msinfo32)

1. Press Win + R, type msinfo32, and press Enter.
2. In the System Summary pane, scroll to the bottom:
   • Virtualization-based security: Must report Running.
   • Virtualization-based security Services Running: Must report Credential Guard, Hypervisor-Protected Code Integrity.

Step 2: Verify via PowerShell

# Query Device Guard WMI status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | `
    Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning

# Output:
# VirtualizationBasedSecurityStatus : 2 (Running)
# SecurityServicesRunning           : {1, 2} (1 = Credential Guard, 2 = HVCI)

Troubleshooting Credential Guard and VBS Incompatibilities

Observed Issue	Underlying Root Cause	Diagnostic Verification Method	Remediation Protocol
Legacy NTLMv1 Authentication Fails Organically	Credential Guard intentionally disables legacy DES encryption and NTLMv1 hashing by design	Event Viewer Event ID 4625 reports failure for legacy SMB shares or NAS appliances	Modernize legacy NAS firmware to support NTLMv2 or migrate authentication to Kerberos
Third-Party Smart Card Driver Fails to Authenticate	Smart card minidriver relies on un-virtualized cryptographic hooks unsupported in VTL 1	Workstation displays “The smart card card cannot perform requested operation”	Update smart card drivers to modern VSM-compatible minidrivers certified for Windows 11
Virtualization Software (VMware Workstation) Hangs on Start	Nested hypervisor conflict; VBS monopolizes hardware VT-x / AMD-V CPU virtualization extensions	VMware displays: “VMware Workstation and Device/Credential Guard are not compatible”	Upgrade to modern VMware Workstation (v16+) configured to use the Windows Hypervisor Platform (WHP) API
Cannot Disable Credential Guard via Registry	Configured with “Enabled with UEFI Lock”; kernel ignores registry deletion to prevent malware bypass	Registry key resets automatically upon next boot cycle	Must disable policy in GPO and execute the official Microsoft UEFI lock opt-out boot sequence tool