Credential Guard

What is Credential Guard?

Credential Guard is a Windows feature that isolates the credentials in LSASS. It uses Virtualization-Based Security (VBS) to store those secrets in a separate process that the hardware keeps isolated. Even malware with admin rights or SYSTEM rights on the regular Windows environment cannot reach it.

Those credentials used to sit in the memory of lsass.exe, the Local Security Authority process. That is exactly what tools like Mimikatz read out. Credential Guard moves them out of there into a separate process that the hypervisor shields. The feature used to be called Windows Defender Credential Guard and has shipped in Windows since Windows 10 Enterprise and Windows Server 2016.

How does it work?

VBS uses the hypervisor to create an isolated part of memory, separate from the regular Windows environment. A separate LSA process, LSAIso.exe, runs inside it and holds the secrets. The normal LSA in Windows talks to it through remote procedure calls, but cannot read its memory. The isolated process runs no drivers and contains only a small set of signed security binaries, whose signatures VBS checks before they start.

Credential Guard protects three kinds of secrets:

• NTLM password hashes.
• Kerberos Ticket-Granting Tickets (TGTs).
• Credentials that applications store as domain credentials in Credential Manager.

On hardware with a TPM 2.0, persistent VBS data is tied to a VSM master key that the TPM protects. The hashes and TGTs themselves usually do not survive a restart. They are lost on a reboot and come back once the user logs in again.

What does it protect and what doesn’t it?

Credential Guard keeps the protected secrets out of lsass.exe and inside the isolated process. An attacker who reads LSASS memory therefore no longer gets hold of those NTLM hashes and TGTs. That slows Pass-the-Hash and pass-the-ticket for the accounts it covers.

Credential Guard does not protect the local SAM, so it does not protect the local accounts. It does not protect the NTDS.dit, the password database on a domain controller. Cached domain credentials in the registry stay unprotected. A password that someone supplies directly for an NTLM login also falls outside it. Credential Guard shields the stored hash of the logged-in user, but a freshly supplied password like that still passes through LSASS in readable form. For Kerberos only the TGT is protected, not the service tickets, so Kerberoasting remains possible. Keyloggers and physical attacks are also out of scope, and it does not stop an attacker who abuses the rights of an already logged-in session.

For the local accounts that Credential Guard does not cover, you deploy LAPS. That gives each machine its own local admin password, so a local hash works nowhere else.

When is it on?

From Windows 11 22H2 and Windows Server 2025, Credential Guard is on by default on domain-joined systems that are not a domain controller and meet the hardware requirements. That default enablement happens without a UEFI lock, so you can turn it off remotely. If it was explicitly turned off before the upgrade, it stays off.

The prerequisite is VBS plus Secure Boot, and an Enterprise or Education edition. On Windows Pro it does not work. A TPM and a UEFI lock are recommended, not required. Microsoft advises against putting it on domain controllers or Exchange servers, because it offers no extra security there and can cause problems.

To check whether it is actually running, use msinfo32.exe. Under System Summary, “Virtualization-based Security Services Running” should list the value “Credential Guard”. You can also check with PowerShell:

# Is Credential Guard running? Value 1 in the array means yes (2 = HVCI)
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Credential Guard and attackers

With Credential Guard on, dumping LSASS with Mimikatz no longer yields the protected hashes and tickets. For those accounts that path is closed. But a pentester has plenty left. The local SAM is still readable, cached domain credentials are still in the registry, and on a domain controller the entire NTDS.dit can be pulled with a DCSync. NTLM relay does not need the hash at all, because there you use the authentication without ever reading it. And credentials that were just typed in still sit in LSASS.

So Credential Guard does not stand on its own. It closes one important path, reading domain credentials out of memory. Combine it with LAPS for the local accounts and with a tiering model that keeps admin accounts away from regular workstations.