Introduction to Credential Guard

Credential Guard is a virtualization-based security (VBS) feature introduced in Windows 10 and Windows Server 2016 that protects derived credential material — specifically NTLM password hashes and Kerberos Ticket Granting Tickets (TGTs) — from extraction by malicious code running in the operating system. On Windows Server 2022, Credential Guard is enhanced with hardware-enforced isolation and represents one of the most effective mitigations against pass-the-hash and pass-the-ticket attacks.

Without Credential Guard, credentials cached in the Local Security Authority (LSA) process live in normal kernel-accessible memory. Tools like Mimikatz can dump these credentials from lsass.exe with minimal effort. Credential Guard moves the LSA’s sensitive operations into an isolated environment called Isolated User Mode (IUM), backed by the Virtual Secure Mode (VSM) hypervisor. Even if an attacker gains SYSTEM privileges on the host OS, they cannot access credentials stored in this isolated partition.

Understanding what Credential Guard does and does not protect is critical before deployment. It protects NTLM hashes, Kerberos TGTs, and domain-derived credentials stored in LSASS. It does not protect credentials stored in the Windows Credential Manager, SAM database hashes, digest authentication credentials when Digest authentication is enabled, or plaintext passwords entered by users at logon prompts.

Hardware Requirements for Credential Guard

Credential Guard has strict hardware prerequisites because it depends on Virtualization-Based Security. Before attempting to enable it, confirm your server meets all of the following requirements.

The system must have a 64-bit CPU with hardware virtualization extensions: Intel VT-x or AMD-V. The BIOS/UEFI must have virtualization enabled. The platform must use UEFI firmware version 2.3.1 or later with Secure Boot enabled. This prevents boot-time firmware attacks that could undermine the hypervisor.

Input/Output Memory Management Unit (IOMMU) support — Intel VT-d or AMD-Vi — is required to prevent DMA (Direct Memory Access) attacks against VSM memory. Without IOMMU, Credential Guard can still be enabled but operates in a degraded mode without DMA protection.

TPM 2.0 is strongly recommended. While Credential Guard can technically function without a TPM, the TPM is used to bind the VSM secrets to the hardware platform, making it much harder to extract credentials even if an attacker gains physical access to the drive. On production domain controllers, TPM 2.0 should be considered mandatory.

Verify hardware compatibility before deployment using the Device Guard and Credential Guard Hardware Readiness Tool, available from Microsoft, or by reviewing the output of msinfo32 which will show Virtualization-Based Security status under System Summary.

Enabling Credential Guard via Group Policy

The recommended method for domain-joined servers is to enable Credential Guard through Group Policy. Open the Group Policy Management Console (GPMC) on a domain controller or management workstation and create or edit a GPO targeted at the servers you want to protect.

Navigate to the following policy path:

Computer Configuration
  → Administrative Templates
    → System
      → Device Guard
        → Turn On Virtualization Based Security

Set the policy to Enabled. Within the policy settings, configure the following options:

Select Platform Security Level: Choose “Secure Boot and DMA Protection” for full protection if your hardware supports IOMMU. If not, select “Secure Boot” only, but note this does not protect against DMA attacks.

Credential Guard Configuration: Set this to “Enabled with UEFI lock”. The UEFI lock option writes the Credential Guard configuration to UEFI firmware variables, preventing an attacker or even an administrator from disabling it without physical access to the machine and clearing UEFI variables. If you need the ability to remotely disable Credential Guard (for example in lab environments), choose “Enabled without lock” instead, but understand this reduces security.

Secure Launch Configuration: On systems with a compatible DRTM (Dynamic Root of Trust for Measurement) — available on Intel Trusted Execution Technology (TXT) and AMD SKINIT platforms — set this to Enabled to protect against bootkit attacks.

After configuring the GPO, link it to the appropriate OU and run gpupdate /force on target servers, or wait for the next Group Policy refresh cycle. A reboot is required for Credential Guard to take effect.

Enabling Credential Guard via Registry

For servers that are not domain-joined or for scripted deployments, you can configure Credential Guard directly via registry keys. The relevant registry location is:

HKLMSYSTEMCurrentControlSetControlDeviceGuard

Use the following PowerShell commands to enable Credential Guard with UEFI lock:

# Enable Virtualization Based Security
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlDeviceGuard" `
    -Name "EnableVirtualizationBasedSecurity" -Value 1 -Type DWord

# Set Platform Security Level: 3 = Secure Boot + DMA Protection
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlDeviceGuard" `
    -Name "RequirePlatformSecurityFeatures" -Value 3 -Type DWord

# Configure Credential Guard: 2 = Enabled with UEFI lock, 1 = Enabled without lock
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLSA" `
    -Name "LsaCfgFlags" -Value 2 -Type DWord

After setting these registry values, reboot the server. The LsaCfgFlags value controls Credential Guard specifically: 0 disables it, 1 enables it without UEFI lock, and 2 enables it with UEFI lock.

Note that if you previously enabled Credential Guard with UEFI lock and want to disable it, you cannot simply delete the registry key. You must boot into UEFI firmware settings and clear the UEFI variables, or use the Device Guard and Credential Guard hardware readiness tool with the -Disable switch, then reboot twice.

Verifying Credential Guard Is Running

After rebooting, verify that Credential Guard is active using multiple methods. The simplest is to open msinfo32 (System Information) and look at the System Summary section. You should see entries for:

Virtualization-based security: Running
Virtualization-based security required security properties: Base Virtualization Support, Secure Boot, DMA Protection
Virtualization-based security available security services: Credential Guard
Virtualization-based security running security services: Credential Guard

If “Credential Guard” does not appear under “running security services,” it is not active. You can also query this programmatically with PowerShell using the Win32_DeviceGuard WMI class:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace rootMicrosoftWindowsDeviceGuard | `
    Select-Object -Property `
        VirtualizationBasedSecurityStatus, `
        SecurityServicesRunning, `
        SecurityServicesConfigured, `
        AvailableSecurityProperties

Interpret the output using these value mappings: SecurityServicesRunning value 1 = Credential Guard is running, value 2 = HVCI (Hypervisor Protected Code Integrity) is running. VirtualizationBasedSecurityStatus value 2 = VBS is running. If VirtualizationBasedSecurityStatus is 1, VBS is enabled but not running, usually indicating a hardware incompatibility.

You can also check the System event log for event ID 3 from the LSA source, which is logged when Credential Guard starts successfully during boot.

Credential Guard and Remote Desktop Protocol

Credential Guard introduces an important behavioral change for Remote Desktop connections that administrators must understand. By default, when connecting to a remote server via RDP using Network Level Authentication (NLA), Windows uses CredSSP (Credential Security Support Provider) to send the user’s credentials to the remote server for pre-authentication. When Credential Guard is enabled, this credential delegation is blocked by default.

This means that if you RDP into a server protected by Credential Guard, your NTLM hash or Kerberos TGT will not be delegated to that server. This is the intended security behavior — it prevents scenarios where a compromised server could harvest administrator credentials through CredSSP. However, it also means that features relying on credential delegation (such as double-hop Kerberos) will fail.

If your environment requires credential delegation via RDP (for example, for management scenarios), you can configure a restricted exception using Group Policy under:

Computer Configuration
  → Administrative Templates
    → System
      → Credentials Delegation
        → Allow delegating default credentials

However, carefully evaluate the security implications before enabling any form of credential delegation to servers, as it partially undermines the protections Credential Guard provides against lateral movement.

Credential Guard with Hyper-V Virtual Machines

When Credential Guard is enabled on a Hyper-V host running Windows Server 2022, a nested virtualization scenario exists: the host’s VSM hypervisor is running, and Hyper-V is also running guest VMs on top. This is supported and functional, but requires that the Hyper-V VMs are generation 2 VMs with Secure Boot enabled.

You can also enable Credential Guard inside Windows Server 2022 guest VMs running on Hyper-V. To do this, the VM must have the following virtual hardware configuration: Secure Boot enabled (Generation 2), TPM enabled (virtual TPM), and the host must have DMA protection available. Configure these settings in Hyper-V Manager or via PowerShell:

# Enable virtual TPM on a VM (VM must be off)
$VMName = "MyServer2022VM"
Set-VMKeyProtector -VMName $VMName -NewLocalKeyProtector
Enable-VMTPM -VMName $VMName

# Enable Secure Boot (should already be on for Gen2 VMs)
Set-VMFirmware -VMName $VMName -EnableSecureBoot On

After configuring the VM hardware, enable Credential Guard inside the guest using the same Group Policy or registry methods described earlier. The guest VM’s isolated LSA will be protected within its own VSM partition, which is itself isolated within the Hyper-V hypervisor running on the host.

Troubleshooting Credential Guard Compatibility Issues

Several common applications and configurations are incompatible with Credential Guard and will fail when it is enabled. Understanding these conflicts is essential before deploying in production.

Digest Authentication: Credential Guard disables Digest authentication because Digest requires access to plaintext or reversibly encrypted credentials, which Credential Guard does not support. If any services or applications on the server use Digest authentication, they will break. Audit Digest usage before deployment.

Unconstrained Kerberos Delegation: Services configured with unconstrained Kerberos delegation (where the service account is trusted for delegation to any service) are incompatible with Credential Guard. Migrate to constrained delegation (KCD) or resource-based constrained delegation (RBCD) before enabling Credential Guard.

NTLMv1: Credential Guard enforces a minimum of NTLMv2. If any clients or services on your network use NTLMv1, they will fail to authenticate. Ensure LAN Manager Authentication Level is set to 5 (NTLMv2 only) across the environment before enabling Credential Guard.

Wi-Fi with MS-CHAPv2: Wi-Fi profiles using MS-CHAPv2 authentication are incompatible because this protocol requires access to the NT hash. Migrate to certificate-based authentication (EAP-TLS) for wireless.

Use the Device Guard and Credential Guard Hardware Readiness Tool to scan for compatibility issues before deployment:

# Run the readiness tool check (download DG_Readiness_Tool.ps1 from Microsoft)
.DG_Readiness_Tool.ps1 -Ready

Review the output carefully. Any red items indicate blocking incompatibilities that must be resolved. Yellow items are warnings that may impact functionality. After resolving all conflicts, re-run the tool to confirm readiness before applying the Group Policy that enables Credential Guard across your server fleet.

Disabling Credential Guard if Required

If Credential Guard was enabled without UEFI lock, disabling it is straightforward. Set LsaCfgFlags back to 0 and reboot:

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLSA" `
    -Name "LsaCfgFlags" -Value 0 -Type DWord

Restart-Computer

If Credential Guard was enabled with UEFI lock (LsaCfgFlags value 2), you must additionally clear the UEFI variables. This typically requires booting into the UEFI firmware interface or using the DG_Readiness_Tool.ps1 script with the -Disable switch followed by two reboots as instructed by the tool. Failure to clear the UEFI variables will result in Credential Guard re-enabling itself on the next boot regardless of the registry setting, which is the entire point of the UEFI lock feature.