How to Enable and Configure Credential Guard on Windows Server 2025

Credential Guard is one of the most impactful security controls available in Windows Server 2025. It uses Virtualization-Based Security (VBS) to isolate the Local Security Authority Subsystem Service (LSASS) into a separate, hardware-protected virtual trust level (VTL1) called the Secure World. Because LSASS runs in this isolated environment, even an attacker with kernel-level code execution (SYSTEM privileges, ring-0 access) on the host cannot extract cached credentials, NTLM hashes, or Kerberos TGTs using tools like Mimikatz. This tutorial covers the complete Credential Guard deployment: hardware requirements, enabling via Group Policy and registry, verification through event logs and system information tools, and understanding the operational impact on legacy protocols and RDP scenarios.

Prerequisites

Windows Server 2025 (Credential Guard is supported on Standard and Datacenter editions)
64-bit CPU with virtualization extensions: Intel VT-x or AMD-V (check in BIOS/UEFI)
UEFI firmware (not legacy BIOS) with Secure Boot enabled
CPU support for Second Level Address Translation: Intel EPT or AMD RVI
Hypervisor-Protected Code Integrity (HVCI) compatible drivers
TPM 2.0 recommended (required for UEFI lock mode)
Domain Admin or local Administrator credentials for policy configuration
PowerShell 5.1 or later

Step 1: Verify Hardware and Firmware Requirements

Credential Guard requires specific hardware capabilities. Before deployment, audit your server hardware to confirm compatibility. Attempting to enable Credential Guard on incompatible hardware will silently fail or leave VBS in a non-functional state.

# Check Virtualization-Based Security readiness
$info = Get-ComputerInfo

# Check if VBS is enabled in firmware
Write-Host "VBS Enabled:           $($info.DeviceGuardVirtualizationBasedSecurityStatus)"
Write-Host "VBS Required:          $($info.DeviceGuardRequiredSecurityProperties)"
Write-Host "VBS Available:         $($info.DeviceGuardAvailableSecurityProperties)"
Write-Host "VBS Running Services:  $($info.DeviceGuardSecurityServicesRunning)"
Write-Host "VBS Configured:        $($info.DeviceGuardSecurityServicesConfigured)"

# Check CPU virtualization support
$cpu = Get-WmiObject -Class Win32_Processor
Write-Host "CPU: $($cpu.Name)"
Write-Host "Virtualization Firmware Enabled: $($cpu.VirtualizationFirmwareEnabled)"

# Check UEFI/SecureBoot status
Confirm-SecureBootUEFI -ErrorAction SilentlyContinue
if ($?) {
    Write-Host "Secure Boot: Enabled" -ForegroundColor Green
} else {
    Write-Warning "Secure Boot is NOT enabled — required for Credential Guard with UEFI lock"
}

# Check TPM status
Get-WmiObject -Namespace "rootCIMv2SecurityMicrosoftTpm" -Class Win32_Tpm |
    Select-Object IsEnabled_InitialValue, IsActivated_InitialValue, SpecVersion

# Check for HVCI-incompatible drivers
# Run the Device Guard and Credential Guard hardware readiness tool
# Download: https://www.microsoft.com/en-us/download/details.aspx?id=53337
# DG_Readiness_Tool_v3.6.ps1 -Ready

Step 2: Enable Credential Guard via Group Policy

Group Policy is the recommended method for deploying Credential Guard across multiple servers or an entire organizational unit. The relevant settings are in the Device Guard section of Computer Configuration.

Navigate to the following GPO path in the Group Policy Management Editor:

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

Set the policy to Enabled with these sub-settings:

Select Platform Security Level: Secure Boot and DMA Protection
Virtualization Based Protection of Code Integrity: Enabled with UEFI lock
Credential Guard Configuration: Enabled with UEFI lock
Secure Launch Configuration: Enabled

# Create and configure a GPO for Credential Guard deployment
Import-Module GroupPolicy

$gpoName = "Server2025-CredentialGuard-Policy"
$targetOU = "OU=Tier0-Servers,DC=contoso,DC=com"

# Create the GPO
New-GPO -Name $gpoName -Comment "Enables Credential Guard with VBS on Tier-0 servers"

# Link the GPO to the Tier-0 OU
New-GPLink -Name $gpoName -Target $targetOU -Enforced No

# Set the VBS registry keys via GPO Preferences (alternative to ADMX settings)
# These registry values are equivalent to the ADMX policy configuration
$gpoRegistrySettings = @(
    @{
        Key   = 'HKLMSYSTEMCurrentControlSetControlDeviceGuard'
        Name  = 'EnableVirtualizationBasedSecurity'
        Value = 1; Type = 'DWord'
    },
    @{
        Key   = 'HKLMSYSTEMCurrentControlSetControlDeviceGuard'
        Name  = 'RequirePlatformSecurityFeatures'
        Value = 3; Type = 'DWord'   # 1=Secure Boot, 2=DMA, 3=Both
    },
    @{
        Key   = 'HKLMSYSTEMCurrentControlSetControlDeviceGuard'
        Name  = 'HypervisorEnforcedCodeIntegrity'
        Value = 1; Type = 'DWord'
    },
    @{
        Key   = 'HKLMSYSTEMCurrentControlSetControlLsa'
        Name  = 'LsaCfgFlags'
        Value = 1; Type = 'DWord'   # 1=UEFI lock, 2=no lock, 0=disabled
    }
)

foreach ($setting in $gpoRegistrySettings) {
    Set-GPRegistryValue `
        -Name  $gpoName `
        -Key   $setting.Key `
        -ValueName $setting.Name `
        -Value $setting.Value `
        -Type  $setting.Type
    Write-Host "Set GPO registry: $($setting.Key)$($setting.Name) = $($setting.Value)"
}

# Force GPO update on target servers (requires WinRM)
$tier0Servers = Get-ADComputer -SearchBase $targetOU -Filter * |
    Select-Object -ExpandProperty DNSHostName

foreach ($server in $tier0Servers) {
    Invoke-Command -ComputerName $server -ScriptBlock { gpupdate /force } -AsJob
}
Write-Host "GPO pushed to $($tier0Servers.Count) server(s). Reboot required to activate VBS."

Step 3: Enable Credential Guard via Registry (Individual Servers)

For servers not managed by Group Policy, or for testing on a single machine, configure Credential Guard directly via the registry. A reboot is required for changes to take effect.

# Enable Credential Guard via direct registry modification
# Run as Administrator

$deviceGuardPath = "HKLM:SYSTEMCurrentControlSetControlDeviceGuard"
$lsaPath         = "HKLM:SYSTEMCurrentControlSetControlLsa"

# Ensure the DeviceGuard registry key exists
if (-not (Test-Path $deviceGuardPath)) {
    New-Item -Path $deviceGuardPath -Force | Out-Null
}

# Enable Virtualization-Based Security
Set-ItemProperty -Path $deviceGuardPath `
    -Name "EnableVirtualizationBasedSecurity" `
    -Value 1 -Type DWord

# Require Secure Boot + DMA protection (value 3)
# Use 1 for Secure Boot only if hardware lacks DMA protection
Set-ItemProperty -Path $deviceGuardPath `
    -Name "RequirePlatformSecurityFeatures" `
    -Value 3 -Type DWord

# Enable Hypervisor-Protected Code Integrity (HVCI)
Set-ItemProperty -Path $deviceGuardPath `
    -Name "HypervisorEnforcedCodeIntegrity" `
    -Value 1 -Type DWord

# Configure LsaCfgFlags for Credential Guard
# 1 = Enabled with UEFI lock   (secure — cannot be disabled via registry remotely)
# 2 = Enabled without UEFI lock (can be remotely disabled; use for testing)
# 0 = Disabled
Set-ItemProperty -Path $lsaPath `
    -Name "LsaCfgFlags" `
    -Value 1 -Type DWord   # Use 2 for initial testing, then switch to 1

Write-Host "Credential Guard registry settings applied." -ForegroundColor Green
Write-Host "A system reboot is required to activate Virtualization-Based Security." -ForegroundColor Yellow

# Optionally schedule a reboot
# Restart-Computer -Force

Step 4: Verify Credential Guard Is Active

After the server reboots with VBS-capable hardware, verify that Credential Guard has started successfully. Windows logs specific Event IDs to the System log when VBS and Credential Guard initialize.

# Method 1: Check Windows Event Log for VBS/Credential Guard events
# Event ID 14 in System log = Credential Guard (LsaIso.exe) started successfully

Get-WinEvent -LogName "System" -FilterXPath `
    "*[System[(EventID=14 or EventID=15)]]" -MaxEvents 10 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# Event ID 14: Credential Guard (LsaIso.exe) was started successfully
# Event ID 15: Credential Guard (LsaIso.exe) configuration: 0x01

# Method 2: Use Get-ComputerInfo
$info = Get-ComputerInfo
Write-Host "`n=== Credential Guard Status ==="
Write-Host "VBS Status:           $($info.DeviceGuardVirtualizationBasedSecurityStatus)"
Write-Host "Services Running:     $($info.DeviceGuardSecurityServicesRunning -join ', ')"
Write-Host "Services Configured:  $($info.DeviceGuardSecurityServicesConfigured -join ', ')"

# Running services should include: CredentialGuard, HypervisorEnforcedCodeIntegrity

# Method 3: Check via msinfo32 (GUI)
# Run: msinfo32
# Navigate to: System Summary → Virtualization-based security
# Look for:
#   Virtualization-based security: Running
#   Virtualization-based security Services Running: Credential Guard, HVCI

# Method 4: Check for the LsaIso.exe process (indicates VTL1 isolation is active)
Get-Process -Name "LsaIso" -ErrorAction SilentlyContinue |
    Select-Object ProcessName, Id, CPU, WorkingSet

if (-not (Get-Process -Name "LsaIso" -ErrorAction SilentlyContinue)) {
    Write-Warning "LsaIso.exe not running — Credential Guard may not be active."
    Write-Warning "Verify hardware requirements and check Event ID 14 in System log."
} else {
    Write-Host "LsaIso.exe is running — Credential Guard is ACTIVE." -ForegroundColor Green
}

Step 5: Understand the Impact on RDP and NTLMv1

Credential Guard has important implications for Remote Desktop Protocol connections and legacy authentication. Understanding these impacts is essential before deployment in production environments.

RDP with Restricted Admin and RemoteGuard

Standard RDP connections send user credentials to the remote server where they are stored in LSASS — exactly what Credential Guard protects. However, even with Credential Guard enabled on the target server, credentials are still exposed on the target if using standard RDP. To protect credentials end-to-end, use RDP Restricted Admin mode (passes hash, not full credentials) or Windows Defender Remote Credential Guard (SSO via Kerberos redirect — credentials never leave the client).

# Enable Remote Credential Guard support on the target server
# This allows RDP clients to use Kerberos delegation instead of passing credentials

$regPath = "HKLM:SystemCurrentControlSetControlLsa"
Set-ItemProperty -Path $regPath -Name "DisableRestrictedAdmin" -Value 0 -Type DWord

# Connect to a remote server using Remote Credential Guard (from client)
# Run this on the CLIENT machine, not the server
# mstsc.exe /remoteGuard /v:targetserver.contoso.com

# Or via PowerShell
cmdkey /generic:"targetserver.contoso.com" /user:"CONTOSOadminaccount" /pass

# Check if Restricted Admin mode is enabled
$value = Get-ItemProperty -Path "HKLM:SystemCurrentControlSetControlLsa" `
    -Name "DisableRestrictedAdmin" -ErrorAction SilentlyContinue
if ($value.DisableRestrictedAdmin -eq 0) {
    Write-Host "Restricted Admin mode: ENABLED (0 = enabled, counter-intuitive naming)" -ForegroundColor Green
}

NTLMv1 Impact

Credential Guard blocks NTLM hash extraction from LSASS, but it does not block NTLM authentication itself at the network level. However, Credential Guard is incompatible with NTLMv1. If your environment has applications or devices relying on NTLMv1, they will fail to authenticate. Audit and remediate NTLMv1 usage before deploying Credential Guard.

# Audit NTLMv1 usage via event log (Event 4624 with LmPackageName = NTLM V1)
# Enable NTLMv1 auditing first
$auditPath = "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0"
Set-ItemProperty -Path $auditPath -Name "NtlmMinClientSec" -Value 536870912 -Type DWord  # Require NTLMv2
Set-ItemProperty -Path $auditPath -Name "NtlmMinServerSec" -Value 536870912 -Type DWord  # Require NTLMv2

# Find NTLMv1 authentication events (before enforcing restriction)
Get-WinEvent -ComputerName $env:COMPUTERNAME -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[10].Value -eq "NTLM V1" } |
    Select-Object TimeCreated,
        @{N='User';      E={ $_.Properties[5].Value }},
        @{N='Source';    E={ $_.Properties[18].Value }},
        @{N='AuthPkg';   E={ $_.Properties[10].Value }} |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 50

Step 6: Disable Credential Guard (Without UEFI Lock)

If Credential Guard was enabled with LsaCfgFlags = 2 (no UEFI lock), it can be disabled via registry and reboot. If enabled with UEFI lock (LsaCfgFlags = 1), you must use the UEFI firmware settings or the Device Guard/Credential Guard hardware readiness tool to remove the UEFI variable.

# Disable Credential Guard (only works if NOT using UEFI lock — LsaCfgFlags = 2)
$lsaPath = "HKLM:SYSTEMCurrentControlSetControlLsa"
Set-ItemProperty -Path $lsaPath -Name "LsaCfgFlags" -Value 0 -Type DWord

$deviceGuardPath = "HKLM:SYSTEMCurrentControlSetControlDeviceGuard"
Set-ItemProperty -Path $deviceGuardPath `
    -Name "EnableVirtualizationBasedSecurity" -Value 0 -Type DWord

Write-Host "Credential Guard disabled. Reboot required." -ForegroundColor Yellow

# If UEFI lock was used, use the readiness tool to remove the UEFI variable:
# DG_Readiness_Tool_v3.6.ps1 -Disable -AutoReboot

Conclusion

Credential Guard on Windows Server 2025 fundamentally changes the attacker’s calculus for credential theft. By isolating LSASS into a hardware-enforced virtual trust level, even the most privileged code running in the standard OS cannot extract credentials from memory. The combination of Credential Guard, Remote Credential Guard for RDP sessions, the Protected Users security group, and NTLM auditing eliminates the credential theft attack surface that tools like Mimikatz have exploited for over a decade. Deploy Credential Guard with UEFI lock on all Tier-0 servers (domain controllers, PKI servers, privileged access workstations) first, validate with the LsaIso.exe process check and Event ID 14, then roll out progressively to Tier-1 and Tier-2 infrastructure. Pair this control with regular auditing of NTLMv1 usage and a clear plan to migrate legacy applications to Kerberos or NTLMv2 for a complete defense-in-depth credential protection strategy.

How to Configure Network Policy Server (NPS/RADIUS) on Windows Server 2025