Stealing credentials is still one of the easiest ways for an attacker to move through a network. Learn from this guide how Windows Credential Guard uses virtualization-based security to lock secrets away from the operating system and break the attacks that depend on harvesting them.
Credential theft remains one of the most common stepping stones in modern intrusions. Once an attacker gets access to a single machine, the goal is rarely to stay there. Instead, they harvest the credentials sitting in memory and reuse them to pivot, escalate, and eventually reach a domain controller.
Microsoft’s own security guidance frames Credential Guard as a direct answer to this problem: a way to isolate secrets so that even a fully compromised operating system cannot read them. As of Windows 11 Enterprise, version 22H2 and Windows Server 2025, it is enabled by default on supported, domain-joined systems, which makes understanding how it works more relevant than ever.
In this article, we will examine what Credential Guard is, the virtualization-based architecture behind it, the attacks it stops, and just as importantly, the attacks it does not.
What Credential Guard Actually Is
Credential Guard is a Windows security feature that uses Virtualization-Based Security (VBS) to isolate the secrets that Windows uses to prove who you are. Rather than storing derived credentials in the normal operating system process where any sufficiently privileged code can reach them, Credential Guard moves them into a hardware-isolated environment that the main OS cannot access.
To understand why this matters, it helps to know where credentials normally live.
On a traditional Windows machine, the Local Security Authority Subsystem Service (LSASS) is the process responsible for authentication. It holds secrets such as NTLM password hashes and Kerberos tickets in its memory so that the user does not have to retype a password for every resource they access. The problem is that an attacker with administrative or SYSTEM rights can read LSASS memory directly, using tools like Mimikatz, and walk away with those secrets.
Credential Guard changes this model fundamentally. With it enabled, the sensitive secrets no longer live in the normal LSASS process at all.
Virtualization-Based Security (VBS)
The foundation of Credential Guard is VBS, which uses the CPU’s hardware virtualization extensions (the same technology that powers Hyper-V) to create a small, isolated region of memory that is separate from the running operating system.
In practice, the hypervisor partitions the system into different trust levels called Virtual Trust Levels (VTLs):
- VTL 0 (Normal Mode): This is where the regular operating system runs, including the kernel, drivers, and all user applications. Everything you normally interact with lives here.
- VTL 1 (Secure Mode): This is a protected, isolated environment that runs in parallel. Even the VTL 0 kernel cannot read its memory. Credential Guard’s secrets are stored here.
Because VTL 1 is enforced by the hypervisor and the CPU rather than by the operating system, an attacker who fully compromises the normal OS, kernel included, still cannot reach into the secure region to extract credentials.
The Isolated LSA Process
When Credential Guard is active, LSASS is effectively split in two.
- The standard LSASS process continues to run in VTL 0 and handles the parts of authentication that don’t require direct access to the raw secrets.
- A second, trusted process called LSAIso (Local Security Authority Isolated) runs inside VTL 1. This is where the actual NTLM hashes and Kerberos ticket-granting tickets are stored and used.
When Windows needs to authenticate, the normal LSASS process talks to LSAIso through a controlled channel. LSAIso performs the cryptographic operation using the protected secret and returns only the result, never the secret itself. The credential never crosses back into the territory an attacker can read.
What Credential Guard Protects Against
The whole point of this isolation is to break a specific and very common class of attacks: credential theft and reuse. When the derived credentials cannot be extracted from memory, the attacks that depend on stealing them simply stop working.
Pass-the-Hash (PtH)
In a Pass-the-Hash attack, the adversary steals the NTLM hash of a user’s password from memory and replays it to authenticate as that user, without ever needing to crack the password itself. Because Credential Guard keeps NTLM hashes inside LSAIso, they can no longer be scraped from LSASS, which removes the raw material these attacks rely on.
Pass-the-Ticket (PtT)
Kerberos authentication uses ticket-granting tickets (TGTs) and service tickets. In a Pass-the-Ticket attack, an attacker steals these tickets from memory and reuses them to impersonate the user. Credential Guard protects Kerberos TGTs in the isolated environment, so they cannot be harvested and replayed.
Credential Dumping Tools
Tooling such as Mimikatz works by reading LSASS process memory and parsing out secrets. With Credential Guard enabled, the secrets these tools look for are no longer present in the memory they can access. The dump succeeds technically, but the valuable material is missing.
The table below summarizes the main threats and how Credential Guard addresses them.
| Threat | What the attacker wants | How Credential Guard helps |
|---|---|---|
| Pass-the-Hash | NTLM password hashes from memory | Hashes are isolated in LSAIso (VTL 1), not in readable LSASS |
| Pass-the-Ticket | Kerberos TGTs from memory | TGTs are stored and used inside the protected environment |
| Credential dumping | Any secret readable in LSASS | Secrets never reside in the normal LSASS process |
| Lateral movement / escalation | Reused credentials to pivot | No reusable secrets to steal cuts the chain at the source |
What Credential Guard Does Not Protect Against
It is just as important to understand the boundaries of the feature. Credential Guard is not a complete defense against credential theft and treating it as one creates a false sense of security. It protects derived domain credentials, not everything.
- Local accounts and the SAM database: Credential Guard protects domain credentials. Secrets stored in the local Security Account Manager (SAM) database and local account credentials are not protected by it.
- Plaintext credentials and key loggers: If a user types a password into a phishing page, or a key logger captures keystrokes, Credential Guard offers no protection. It guards secrets at rest in memory, not credentials entered by the user.
- Microsoft accounts and certain cloud credentials: It is focused on NTLM and Kerberos domain secrets, therefore if you have Entra ID joined devices this feature does not provide any additional security capabilities.
- Weak passwords and the user behind the keyboard: It does nothing to stop password spraying against accounts with weak passwords, social engineering, or a user being tricked into approving a sign-in.
In short, Credential Guard removes a powerful tool from the attacker’s kit, but it is one layer in a defense-in-depth strategy, not a replacement for one.
Requirements and Default Enablement
Because Credential Guard depends on VBS, it has hardware and firmware prerequisites. Systems need a 64-bit CPU with virtualization extensions and Second Level Address Translation (SLAT), UEFI firmware with Secure Boot, and ideally a TPM (1.2 or 2.0) to anchor the keys in hardware.
A significant shift happened with Windows 11, version 22H2 and Windows Server 2025: Credential Guard is now enabled by default on domain-joined systems that meet the requirements, rather than being something administrators have to opt into. There are a couple of behaviors worth knowing:
- Automatic VBS: Default enablement turns on VBS automatically on qualifying machines.
- No UEFI lock by default: The default configuration is applied without a UEFI lock, which means administrators can still disable it remotely if a compatibility issue arises.
- Respect for existing settings: If Credential Guard was explicitly disabled before the upgrade, the update does not override that choice and the device stays disabled.
This matters operationally because some older scenarios, such as unconstrained Kerberos delegation, NTLMv1, or certain third-party authentication drivers, are incompatible with Credential Guard. Knowing it may now be on by default helps explain behavior changes after an upgrade.
Verifying Credential Guard Status
Administrators can confirm whether Credential Guard is running using the built-in System Information tool (msinfo32), where the line Virtualization-based security Services Running will list Credential Guard when it is active.
It can also be checked with PowerShell:
$dg = Get-CimInstance -ClassName Win32_DeviceGuard \ -Namespace root\Microsoft\Windows\DeviceGuard # A value of 1 in SecurityServicesRunning means Credential Guard is running $dg.SecurityServicesRunning
If the output includes the value 1, Credential Guard is configured and running on that system.
Summary
This guide explained what Windows Credential Guard is and the role it plays in defending against credential theft. We examined how it uses virtualization to isolate secrets and where its protection begins and ends, highlighting:
• Isolation Model: How Virtualization-Based Security and the isolated LSAIso process keep NTLM hashes and Kerberos tickets out of reach of even a fully compromised operating system.
• Threat Coverage: Why this breaks Pass-the-Hash, Pass-the-Ticket, and credential-dumping attacks, while leaving local accounts, plaintext capture, and weak passwords as risks that need other controls.
With default enablement in modern Windows, Credential Guard moves from an optional hardening step to a baseline expectation. Used as part of a broader defense-in-depth approach, it removes one of the most reliable techniques attackers depend on to move laterally and escalate inside a network.
FAQ
What is Windows Credential Guard?
Windows Credential Guard is a security feature that uses virtualization-based security to isolate sensitive authentication data from the main operating system. It protects secrets such as NTLM password hashes and Kerberos ticket-granting tickets.
How does Credential Guard work?
Credential Guard stores protected credentials inside an isolated environment called Virtual Trust Level 1. The regular Windows operating system runs in Virtual Trust Level 0 and cannot directly access the protected memory.
What attacks does Credential Guard prevent?
Credential Guard helps block Pass-the-Hash, Pass-the-Ticket, credential dumping, and lateral movement techniques that depend on extracting reusable credentials from LSASS memory.
Does Credential Guard stop Mimikatz?
Credential Guard prevents Mimikatz and similar tools from extracting protected NTLM hashes and Kerberos tickets from the standard LSASS process. The tools may still access LSASS memory, but the protected secrets are stored separately inside LSAIso.
What does Credential Guard not protect?
Credential Guard does not protect local SAM credentials, passwords captured through phishing or keyloggers, weak passwords, or credentials entered directly by users. It does not replace multifactor authentication, endpoint protection, or identity security controls.
How can I check whether Credential Guard is enabled?
Open System Information by running msinfo32 and check the Virtualization-based security Services Running field. Administrators can check the status through PowerShell using the Win32_DeviceGuard CIM class. A value of 1 in SecurityServicesRunning indicates that Credential Guard is running.
