3 High-Class Credential Guard Mistakes That Leave Your Vault Open

Who Needs Credential Guard and What Goes Wrong Without It

Credential Guard is a Windows feature that uses virtualization-based security (VBS) to isolate domain credentials from the operating system. When it works correctly, even an attacker with administrative access to the OS cannot extract NTLM or Kerberos hashes from LSASS. But when it is misconfigured, it either does not run at all—or worse, it gives administrators a false sense of protection. This guide is for IT administrators, security engineers, and anyone responsible for hardening Windows domain controllers or client machines against credential theft. We will focus on three common mistakes that leave the vault open: ignoring the prerequisites, misapplying Group Policy, and failing to monitor the actual protection state.

Before diving into the mistakes, it helps to understand what Credential Guard actually does. It creates a separate, isolated environment (a virtual machine managed by Hyper-V) where the Local Security Authority Subsystem Service (LSASS) runs. Even if the main OS is compromised, the attacker cannot reach the isolated LSASS process to dump credentials. But this protection depends on hardware and firmware support: a compatible CPU with virtualization extensions, Secure Boot, and a TPM 2.0 chip. When any of these are missing or misconfigured, Credential Guard silently falls back to running in a degraded mode—or does not start at all.

Many teams assume that simply enabling the 'Turn On Credential Guard' Group Policy setting is enough. They reboot, see no errors, and move on. But the system may be running without VBS, meaning credentials are still in the clear. Others skip the prerequisite check for Secure Boot, only to find that a custom boot configuration or legacy BIOS prevents VBS from initializing. And a third group fails to plan for the operational impact: Credential Guard breaks some legacy authentication protocols and third-party credential managers, leading to helpdesk tickets that force administrators to disable the feature entirely. Let us walk through each mistake in detail.

Prerequisites and Context You Should Settle First

Before enabling Credential Guard, you need to confirm that every target machine meets the hardware and firmware requirements. This is where the first mistake often begins: administrators assume that modern hardware automatically supports VBS. In reality, many enterprise devices ship with virtualization disabled in the firmware, Secure Boot turned off, or a TPM that is not initialized. The Windows System Information tool (msinfo32) shows a line for 'Virtualization-based security' status, but that status can be misleading if the prerequisites are only partially met.

Hardware Checklist

Start with the CPU: it must support Intel VT-x or AMD-V with Second Level Address Translation (SLAT). Most CPUs from the last decade meet this, but it is often disabled in BIOS/UEFI. Next, verify that Secure Boot is enabled (not just 'available') and that the system is booting in UEFI mode, not legacy BIOS. You can check this in System Information under 'BIOS Mode'. If it says 'Legacy', Credential Guard will not work. Finally, a TPM 2.0 is required for key storage. On many systems, the TPM is present but not activated in firmware. Use 'tpm.msc' to check the status—if it shows 'Compatible TPM cannot be found', you need to enable it in the UEFI settings.

Windows Edition and Licensing

Credential Guard is available only on Windows Enterprise and Education editions (and Windows Server 2016 and later). Pro editions do not support it, though some third-party tools can mimic parts of the functionality. If you are managing a fleet of Windows 10/11 Pro devices, you will need to upgrade or use alternative protections like Windows Defender Credential Guard (which requires Enterprise). For domain controllers, Credential Guard is available on Windows Server 2019 and later with the necessary hardware.

One more nuance: Credential Guard requires that the Hyper-V role be installed, but it does not require a Hyper-V license for client machines. On servers, you need a Windows Server license that includes Hyper-V. Many administrators skip this step and then wonder why the feature fails to enable. The installation of Hyper-V must happen before the Group Policy is applied; otherwise, the policy will exist but Credential Guard will not start.

The Core Workflow: Enabling Credential Guard Correctly

The correct sequence for enabling Credential Guard involves three phases: preparing the environment, applying the configuration, and verifying the outcome. Skipping any phase leads to the mistakes we want to avoid.

Phase 1: Enable Virtualization-Based Security

First, ensure that virtualization is enabled in the UEFI firmware. This is not something you can do from Windows; you must reboot and enter the firmware settings (usually by pressing F2, F10, or Del during boot). Look for settings like 'Intel Virtualization Technology', 'AMD SVM', or 'VT-d'. Enable them. Also enable 'Secure Boot' and set the boot mode to UEFI (not Legacy). If you are managing many machines, you can use a firmware configuration tool like Dell Command Configure or HP BIOS Config Utility to push these settings remotely.

Phase 2: Apply Group Policy or Registry Settings

The most common method is Group Policy. Navigate to Computer Configuration > Administrative Templates > System > Device Guard. Open the policy 'Turn On Virtualization Based Security' and set it to 'Enabled'. In the options, choose 'Enable with UEFI lock' or 'Enable without lock'. The UEFI lock option prevents the feature from being disabled through the registry, which is more secure but makes changes harder if you need to roll back. For initial testing, use 'without lock'. Also set 'Platform Security Level' to 'Secure Boot' or 'Secure Boot and DMA Protection' (the latter is stronger but requires hardware support).

If you are not using Active Directory, you can set the registry directly: create a DWORD value 'Enabled' under HKLM\Software\Policies\Microsoft\Windows\DeviceGuard and set it to 1. Then create a DWORD 'RequirePlatformSecurityFeatures' set to 1 (Secure Boot) or 3 (Secure Boot and DMA). Reboot the machine.

Phase 3: Verify That Credential Guard Is Running

After reboot, open System Information (msinfo32) and look for 'Virtualization-based security' status. It should say 'Running'. If it says 'Enabled but not running', something is still missing—usually Secure Boot or TPM. You can also run 'Get-CimInstance -ClassName Win32_DeviceGuard' in PowerShell to see detailed status. The output includes fields like 'VirtualizationBasedSecurityStatus' (2 means running) and 'RequiredSecurityProperties'. If the status is 0 or 1, the feature is not active.

Tools, Setup, and Environmental Realities

Deploying Credential Guard is not a one-size-fits-all process. The tools you use depend on your environment: on-premises Active Directory, Azure AD, or a mix. For on-premises, Group Policy is the standard. For Azure AD-joined devices, you can use Microsoft Intune or a mobile device management (MDM) policy. The settings are the same, but the delivery mechanism differs.

Group Policy vs. Registry vs. MDM

One reality that many teams overlook: Credential Guard is incompatible with some third-party security software. Antivirus or endpoint detection tools that hook into LSASS will be blocked by Credential Guard, causing those tools to fail or crash. Always test with your security stack before broad deployment. Another issue is system performance: VBS reserves a portion of memory (typically 1–2 GB) and can impact CPU performance on older hardware. In virtualized environments (like VDI), nested virtualization is required—and many hypervisors do not support it by default.

Composite Scenario: The Secure Boot Surprise

A mid-sized company deployed Credential Guard via Group Policy to all domain controllers. They verified the policy was applied, rebooted, and saw no errors. A week later, a penetration test revealed that LSASS still contained plaintext credentials. The root cause: Secure Boot was enabled in the UEFI, but the system had a custom boot configuration that included a non-Microsoft boot loader. Credential Guard requires that only Microsoft-signed boot components be loaded. The fix was to remove the custom boot loader and re-enable Secure Boot with the default Microsoft keys. This scenario is common in environments that use third-party disk encryption or boot managers.

Variations for Different Constraints

Not every environment can run full Credential Guard. If you are on Windows Pro or have older hardware, you have alternatives. Windows Defender Credential Guard (available in Windows 10/11 Pro) uses a different isolation mechanism that does not require Hyper-V. It protects the same credentials but with a smaller attack surface. Another variation is Remote Credential Guard, which protects credentials when connecting to a remote machine via RDP. This is useful for jump servers and administrative workstations.

When Full Credential Guard Is Not Possible

If your hardware does not support SLAT or Secure Boot, consider using 'Credential Guard with UEFI lock disabled'—but this reduces security because an attacker with admin access can disable the feature. For servers, you can use 'Credential Guard for domain controllers' which is a separate feature that protects the domain controller's own credentials (not user credentials). This requires Windows Server 2019 or later.

Another constraint is licensing: some organizations cannot upgrade to Enterprise for all devices. In that case, prioritize domain controllers and administrative workstations (the 'tier 0' assets). For standard user machines, rely on other mitigations like Restricted Admin mode for RDP and LSA protection (which is a lighter form of credential isolation).

Trade-offs with Network Access Protection

Credential Guard breaks some network authentication scenarios. For example, NTLMv2 authentication with a non-Microsoft NTLM proxy will fail because Credential Guard does not allow third-party modules to access the isolated LSASS. If your environment uses a legacy VPN that relies on NTLM, you may need to switch to certificate-based authentication or upgrade the VPN client. These trade-offs must be communicated to stakeholders before deployment.

Pitfalls, Debugging, and What to Check When It Fails

Even with careful planning, Credential Guard can fail silently. The most common failure is the '0x8007007e' error in the System event log, which usually means a missing Hyper-V component or a driver conflict. Another pitfall is the 'Virtualization-based security is enabled but not running' status. Here is a systematic approach to debugging.

Check the Event Logs

Open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > DeviceGuard > Operational. Look for event IDs 7000 (Credential Guard started) or 7001 (failed to start). The failure reason is often cryptic, but common causes include: Secure Boot not enabled, TPM not present, or Hyper-V not installed. Also check the System log for errors from the 'hvix64' or 'hvax64' driver, which indicates a virtualization issue.

Verify Each Prerequisite Individually

Do not trust the 'Virtualization-based security' status alone. Use the 'Get-CimInstance' command to check each component. Run the following PowerShell script:

$CG = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$CG

Look at the 'RequiredSecurityProperties' field. It should include '0x1' (Secure Boot) and optionally '0x2' (DMA protection). If it shows '0x0', no protection is active. Also check 'VirtualizationBasedSecurityStatus': 0 = disabled, 1 = enabled but not running, 2 = running.

Common Fixes for Specific Failures

• Secure Boot not enabled: Reboot into UEFI settings, enable Secure Boot, and ensure no custom boot loaders are present. Reset Secure Boot to factory defaults if needed.
• TPM not detected: In UEFI, ensure the TPM is activated (not just present). On some systems, the TPM is disabled by default; you must set it to 'Enabled' and reboot.
• Hyper-V missing: Install the Hyper-V feature via PowerShell: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All. Reboot.
• Virtualization disabled in BIOS: Enable Intel VT-x or AMD SVM in firmware settings. This is often hidden under 'CPU Configuration' or 'Advanced' menus.

One more pitfall: if you have previously enabled Credential Guard and then disabled it, a reboot is required to fully clear the configuration. The registry keys may persist, causing conflicts. Always reboot after changing any setting.

FAQ and Practical Checklist

Here are answers to common questions that arise during deployment, followed by a checklist you can use to audit your current setup.

Frequently Asked Questions

Q: Can I enable Credential Guard on a domain controller without rebooting? No. The feature requires a reboot to initialize VBS. Plan a maintenance window.

Q: Does Credential Guard protect against Pass-the-Hash attacks? Yes. By isolating credentials, it prevents attackers from extracting hashes even if they have admin access. However, it does not prevent Kerberos ticket reuse, so combined with other protections like Protected Users group is recommended.

Q: What happens if I remove the Group Policy setting later? If you used 'Enable with UEFI lock', Credential Guard remains enabled until the lock is removed via a secure UEFI variable reset. Without the lock, removing the policy and rebooting disables it.

Q: Does Credential Guard work with BitLocker? Yes, but both rely on TPM. Ensure the TPM is properly initialized and that BitLocker keys are not stored in the TPM in a way that conflicts with Credential Guard. In practice, they coexist without issues.

Audit Checklist

• [ ] CPU virtualization enabled (Intel VT-x / AMD SVM)
• [ ] Secure Boot enabled (UEFI mode only)
• [ ] TPM 2.0 initialized and activated
• [ ] Hyper-V feature installed
• [ ] Windows edition is Enterprise or Education (or Server 2019+)
• [ ] Group Policy or registry set correctly (Enabled = 1)
• [ ] Reboot completed after configuration
• [ ] 'Virtualization-based security' status shows 'Running'
• [ ] No third-party LSASS hooks present (check with 'fltmc' for filter drivers)
• [ ] Tested authentication with common scenarios (RDP, file shares, VPN)

After verifying all items, you can be confident that Credential Guard is protecting your credentials. But remember: no single security feature is a silver bullet. Combine Credential Guard with LSA protection, Restricted Admin mode, and regular security updates to build a layered defense. The mistakes outlined here are common, but they are also avoidable with proper planning and verification. Take the time to check each prerequisite, test in a pilot group, and monitor event logs after deployment. Your vault will stay closed—exactly where it belongs.