How to Configure Windows Defender Credential Guard in Windows 11 Using PowerShell

Pass-the-Hash and Pass-the-Ticket attacks remain among the most prevalent lateral movement tactics employed by threat actors inside compromised enterprise networks. These attack vectors target credentials cached in the Local Security Authority Subsystem Service (LSASS) process memory. Microsoft Defender Credential Guard isolates these secrets using Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI), ensuring that even malware running with full local SYSTEM privileges cannot extract NTLM hashes or Kerberos tickets. Configuring and validating Credential Guard using PowerShell establishes an essential defence against credential theft on Windows 11 workstations.

How Credential Guard Isolates Secrets

In standard Windows architectures, LSASS operates as a protected user-mode process in the primary operating system ring. While protected, malicious drivers or kernel vulnerabilities can potentially compromise LSASS memory space.

Credential Guard isolates credential storage inside an isolated virtual container running alongside the host operating system, known as Virtual Secure Mode (VSM). When Credential Guard is active, a specialized mini-process called LsaIso (LSA Isolated) runs inside the isolated environment. The host LSASS process communicates with LsaIso via secure Remote Procedure Calls (RPC), but host memory reads cannot pierce the hypervisor boundary. Consequently, credential-dumping utilities such as Mimikatz fail to extract cached hashes.

Hardware and Software Prerequisites

To support Windows Defender Credential Guard, the target system must satisfy the following hardware and software criteria:

• Windows 11 Enterprise, Education, or Pro edition (Enterprise recommended for central management).
• 64-bit CPU supporting hardware virtualisation (Intel VT-x or AMD-V) and Second Level Address Translation (SLAT / EPT / NPT).
• Unified Extensible Firmware Interface (UEFI) running in native 64-bit mode with Secure Boot enabled.
• Trusted Platform Module (TPM) 2.0 enabled in firmware (strongly recommended for hardware key binding).

Verifying Hardware and VBS Readiness via PowerShell

Before enabling Credential Guard, verify that the host platform supports Virtualization-Based Security. Open an elevated PowerShell session (Run as Administrator) and query WMI security metrics:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -Property RequiredSecurityProperties, AvailableSecurityProperties, SecurityServicesConfigured, SecurityServicesRunning

Inspect the output fields:

• AvailableSecurityProperties: Should return codes including 1 (Hypervisor support), 2 (Secure Boot), and 3 (DMA Protection).
• SecurityServicesRunning: If code 1 is listed, Credential Guard is already actively enforcing protection.

Enabling Credential Guard via PowerShell

Credential Guard is configured via the Windows Registry under Device Guard policies. To enable Credential Guard with UEFI lock protection (which prevents local attackers from disabling the policy via registry tampering):

# 1. Enable Virtualization-Based Security
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord

# 2. Require Secure Boot and DMA Protection
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -Value 3 -Type DWord

# 3. Enable Credential Guard with UEFI Lock (Value 1 = UEFI Lock, Value 2 = Without Lock)
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 1 -Type DWord

Note on UEFI Lock: Setting LsaCfgFlags to 1 locks the configuration into UEFI NVRAM. Disabling it later requires physical access to the workstation to accept a UEFI prompt during reboot. For testing environments, setting the value to 2 allows registry-only toggling.

Restarting and Validating Credential Guard Status

After applying registry changes, restart the workstation to initiate the hypervisor and launch LsaIso:

Restart-Computer -Force

Upon reboot, open PowerShell as Administrator and check the active DeviceGuard status:

$DG = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$Services = $DG.SecurityServicesRunning

if ($Services -contains 1) {
    Write-Host "Windows Defender Credential Guard is ACTIVE and RUNNING." -ForegroundColor Green
} else {
    Write-Host "Credential Guard is NOT running. Inspect BIOS/UEFI virtualisation settings." -ForegroundColor Red
}

You can also confirm operation by opening System Information (msinfo32.exe) and scrolling to the bottom of the System Summary pane. Confirm that Device Guard Security Services Running explicitly lists Credential Guard.

Operational Considerations and Compatibility

• Unsupported Authentication Protocols: Credential Guard blocks legacy protocols including NTLMv1, MS-CHAPv2, and Kerberos DES encryption. Ensure your infrastructure enforces Kerberos AES and NTLMv2.
• Third-Party Hypervisors: Type-2 hypervisors (such as older VirtualBox or VMware Workstation releases) may conflict with Windows Hypervisor Platform if not updated to their modern hypervisor-coexistence builds.
• Smart Cards and FIDO2: Credential Guard provides complementary protection alongside modern hardware-backed authentication tokens.