Windows Credential Guard: How to Enable It, What It Protects Against, and What It Breaks
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Mimikatz-style LSASS credential dumping works by reading the memory of the lsass.exe process, which stores NTLM hashes and Kerberos tickets for authenticated users. Credential Guard moves that credential storage into a hypervisor-isolated container that nothing running in the normal OS -- not even the kernel -- can read. Enabling it requires hardware that supports virtualization-based security (almost all hardware shipped since 2016) and a brief audit for applications that use unconstrained Kerberos delegation.
Hardware and Software Requirements
Credential Guard requires hardware that supports virtualization-based security:
Required:
- 64-bit CPU with virtualization extensions (Intel VT-x or AMD-V) enabled in BIOS/UEFI
- SLAT (Second Level Address Translation: Intel EPT or AMD RVI)
- UEFI firmware (not legacy BIOS) with Secure Boot enabled
- TPM 1.2 or 2.0 (TPM 2.0 strongly recommended)
Windows edition requirements:
- Windows 10/11 Enterprise or Education
- Windows Server 2016 or later (Standard or Datacenter)
- Not available on Pro, Home, or IoT editions
Check if hardware supports VBS:
# Check virtualization support
(Get-WmiObject -Namespace root\cimv2 -Class Win32_Processor).VirtualizationFirmwareEnabled
# Should return True
# Check if VBS is enabled (after deployment)
Get-ComputerInfo -Property 'DeviceGuardVirtualizationBasedSecurityStatus'
# Returns: Running (active) or RequiresEnabledHypervisor (not yet active)
# Full VBS/Credential Guard status
msinfo32
# Navigate to System Summary > look for 'Virtualization-based security'
# Should show: Running
# Credential Guard: Running
Enable via Group Policy
Group Policy path:
Computer Configuration > Administrative Templates > System > Device Guard
Setting: Turn On Virtualization Based Security
- Enabled
- Select Platform Security Level: Secure Boot and DMA Protection (recommended, requires IOMMU)
- Use Secure Boot only if IOMMU is not available (lower security)
- Credential Guard Configuration: Enabled with UEFI lock (recommended -- cannot be disabled remotely without clearing UEFI variable)
- Use Enabled without lock if you need the ability to disable remotely (lower security)
- Secure Launch Configuration: Enabled (if hardware supports it)
Via registry (for scripted deployment):
# Enable VBS
Reg Add 'HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard' /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
# Set platform security level (3 = Secure Boot + DMA)
Reg Add 'HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard' /v RequirePlatformSecurityFeatures /t REG_DWORD /d 3 /f
# Enable Credential Guard (1 = enabled without lock, 2 = enabled with UEFI lock)
Reg Add 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v LsaCfgFlags /t REG_DWORD /d 1 /f
A reboot is required after enabling. Credential Guard status is not active until the system restarts.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Enable via Intune
Intune path: Endpoint Security > Account Protection > Create Policy > Windows 10 and later > Credential Guard (preview) or via Device Configuration > Endpoint Protection template.
Settings:
- Credential Guard: Enable with UEFI lock
- Virtualization based security: Enable with secure boot
- Virtualization based security launch: Enabled
Alternatively, use the Windows Security Baseline in Intune which includes Credential Guard in the baseline settings.
Verify deployment via Intune reporting: Devices > Monitor > Device compliance > filter by Credential Guard status (requires the Device Health Attestation feature to be enabled in your compliance policy).
Application Compatibility: What Credential Guard Breaks
Before enabling in Block mode across the fleet, audit for these known compatibility issues:
Kerberos unconstrained delegation: The most common breakage. Applications or services configured for unconstrained Kerberos delegation cannot receive forwarded TGTs from Credential Guard-protected clients. The forwarded ticket is not accessible to the delegating service.
Find services using unconstrained delegation:
# Find all computer accounts with unconstrained delegation enabled
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName
# Find all user accounts with unconstrained delegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
The fix: migrate from unconstrained to constrained delegation (resource-based constrained delegation preferred). Unconstrained delegation is a security risk independent of Credential Guard.
Other known compatibility issues:
- Some VPN clients that use NTLMv1 authentication fail -- NTLMv1 is not supported when Credential Guard is active
- Digest Authentication is disabled -- affects applications relying on HTTP Digest authentication (rare in modern environments)
- Some older remote desktop clients that negotiate weak protocols may fail
- Virtual machines running inside Hyper-V may not support nested VBS on all hardware
Audit NTLMv1 usage before enabling:
# Enable NTLMv1 audit logging on DCs
# Event ID 4624 with Authentication Package = NTLM and LM Compatibility Level
# Or enable NTLM audit: Computer Configuration > Security Settings > Local Policies > Security Options
# Network security: Restrict NTLM > Audit NTLM in this domain
The bottom line
Credential Guard is the most effective single control against LSASS-based credential dumping. The deployment path: check hardware VBS support, audit for unconstrained Kerberos delegation (and migrate those services to constrained delegation), enable via Group Policy or Intune with UEFI lock on endpoints you are confident about, verify with Get-ComputerInfo. Run in a pilot group for two weeks before fleet-wide rollout to catch application compatibility issues.
Frequently asked questions
Does Credential Guard block all Mimikatz attacks?
Credential Guard blocks the LSASS memory read class of attacks -- sekurlsa::logonpasswords and similar commands return empty results because the credential material is in the Isolated LSA container, not in accessible LSASS memory. It does not block: DCSync attacks (which read credentials from AD replication, not local LSASS), credential capture from the network (Responder, NTLM relay), credentials stored in browser caches, credentials in memory of other processes (SAP, browser, etc.), or attacks that wait for a user to enter credentials in a compromised session. Credential Guard is one layer in a credential protection stack, not a complete solution.
Can Credential Guard be disabled after enabling with UEFI lock?
Not remotely. That is the point of the UEFI lock option. Once Credential Guard is enabled with UEFI lock, it can only be disabled by a person with physical access to the machine who boots into UEFI firmware settings and manually clears the VBS configuration. This prevents attackers with remote admin access from disabling Credential Guard before dumping credentials. If you need to disable it remotely (for troubleshooting), use Enabled without lock -- but understand this allows the same remote disable path an attacker could use.
Does Credential Guard work on Windows Pro?
No. Credential Guard requires Windows Enterprise or Education editions on clients, and Standard or Datacenter on servers. Windows Pro does not include this feature. Organizations with a Pro license for some endpoints cannot deploy Credential Guard on those devices. This is one reason to standardize on Enterprise licensing for all domain-joined endpoints. As an alternative, Windows Pro endpoints can use Protected Users security group membership and ASR rules to reduce -- though not eliminate -- LSASS exposure.
If I enable Credential Guard, do I still need LAPS?
Yes. These are complementary controls that address different attack paths. Credential Guard prevents attackers from reading domain credentials from LSASS memory on a compromised endpoint. LAPS prevents attackers from reusing a local administrator password across multiple machines. An attacker on an endpoint without Credential Guard can dump the NTLM hash for the currently logged-in domain user and use that for lateral movement. An attacker on an endpoint without LAPS can reuse the local admin password to move to other machines. Both controls together close the two most common credential-based lateral movement techniques.
Does Credential Guard protect against all LSASS credential dumping techniques?
It blocks the most common techniques that read from LSASS memory directly (Mimikatz sekurlsa::logonpasswords, procdump then offline analysis). It does not protect against: credentials in memory outside of LSASS (clipboard, browser password stores, application config files), credentials accessed through legitimate Windows APIs by malicious code running in the user's session, or physical memory acquisition from the machine. Credential Guard also does not protect the LSASS memory of remote systems -- if an attacker moves laterally to a server without Credential Guard and a privileged admin has logged in there, that server's LSASS is still vulnerable. Defense in depth requires Credential Guard plus Protected Users group membership plus PAW architecture for privileged access.
What is LSASS RunAsPPL and how does it compare to Credential Guard?
LSASS RunAsPPL (Protected Process Light) makes the LSASS process a protected process, which prevents non-protected processes from reading its memory even with SeDebugPrivilege. This blocks Mimikatz and similar tools that require direct LSASS memory access. Configure it via registry: `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1` or via UEFI Credential Guard (which includes PPL as part of the configuration). The difference from Credential Guard: PPL protects LSASS from being read by untrusted processes, but credential material (NTLM hashes, Kerberos tickets) still exists in LSASS memory and can be accessed by kernel-level attackers or through Bring Your Own Vulnerable Driver (BYOVD) techniques that load a signed but vulnerable kernel driver to read protected process memory. Credential Guard moves credential material into an isolated virtual machine (VSM) where even kernel-level code cannot access it. For environments with HVCI-capable hardware, Credential Guard provides stronger protection; PPL is a worthwhile defense on hardware that does not support virtualization-based security.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.