Credential Guard: Isolating LSASS Secrets with Virtualization-Based Security

For twenty years, the fastest way to own a Windows network has been to dump lsass.exe. Once an attacker lands on one box as a local admin, a single procdump or Mimikatz invocation hands them NTLM hashes, Kerberos TGTs, and cached credentials for every account that has touched that machine. From there it is pass-the-hash, pass-the-ticket, and lateral movement until they reach a Domain Admin. Credential Guard is Microsoft's structural answer to this problem — not another detection rule, but a hardware-backed boundary that removes the secrets from where the dumper can reach them.

What Credential Guard actually does

Normally, LSASS runs as an ordinary (if protected) process in the NT kernel's address space, and it holds derived credentials in cleartext-adjacent form so it can answer authentication challenges. Any code running with SeDebugPrivilege can open a handle to LSASS and read that memory.

Credential Guard is built on Virtualization-Based Security (VBS). The Windows hypervisor carves the machine into two isolated worlds: the normal OS (Virtual Trust Level 0) and a tiny, hardened secure kernel (VTL 1). With Credential Guard enabled, the secrets that used to live in LSASS are moved into an isolated LSA process — LSAIso.exe — running in VTL 1. The normal LSASS keeps a proxy stub, but it never sees the raw NTLM hash or Kerberos key. Even a kernel-mode attacker in VTL 0 cannot read VTL 1 memory, because the hypervisor enforces the boundary in hardware via SLAT/Second Level Address Translation.

The mental model: LSASS becomes a receptionist that can pass messages to the vault but can never open it. Dumping the receptionist's memory yields nothing useful.

What it stops — and what it does not

Credential Guard is precise, and it is important not to oversell it. It protects:

• NTLM password hashes — no more usable hashes for pass-the-hash.
• Kerberos Ticket-Granting Tickets (TGTs) — the long-lived tickets used for pass-the-ticket and to request service tickets.
• Cached domain credentials (the derived verifiers used for offline logon).

It does not protect:

• Service-ticket keys already scoped to a resource (Kerberoasting is still a concern — see hardening for service accounts with gMSA).
• Credentials typed after compromise, harvested by a keylogger or a hooked login UI.
• DPAPI-protected data, browser cookies, or tokens sitting in other processes.
• Legacy protocols that require reversible secrets — notably WDigest, which is why you still must confirm UseLogonCredential is not re-enabling cleartext caching.

Credential Guard is a layer, not a silver bullet. Pair it with LSA protection (RunAsPPL), disabling WDigest, and least-privilege local admin to close the surrounding gaps.

Enabling it

Credential Guard requires 64-bit Windows, UEFI with Secure Boot, virtualization extensions (VT-x/AMD-V) with SLAT, and ideally a TPM 2.0 to bind the keys to hardware. On modern Windows 11 Enterprise and Server builds it is increasingly enabled by default, but you should verify rather than assume.

The supported path is Group Policy: Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security, then set Credential Guard Configuration to Enabled with UEFI lock. The UEFI lock prevents an attacker (or a careless remote change) from silently disabling it — turning it off then requires physical presence. The equivalent registry keys:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" ^
  /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" ^
  /v RequirePlatformSecurityFeatures /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\LSA" ^
  /v LsaCfgFlags /t REG_DWORD /d 1 /f   :: 1 = enabled with UEFI lock, 2 = without lock

After a reboot, confirm it is genuinely running, not merely configured:

PS> (Get-CimInstance -ClassName Win32_DeviceGuard `
      -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
# 1 in the array == Credential Guard is running

You can corroborate this in msinfo32 under "Virtualization-based security services running," and by confirming LSAIso.exe is present in the process list.

Auditing it at scale

The hard part is not turning Credential Guard on for one machine — it is proving it stays on across every endpoint. A policy set in a GPO is not the same as a feature actually running; a hardware mismatch, a firmware downgrade, or a conflicting hypervisor can leave VBS configured-but-not-running, and nobody notices until the next incident.

This is exactly the drift problem WinSentinel is built to surface. On a single machine, the free WinSentinel agent audits the full VBS and Credential Guard posture — whether VBS is running, whether Credential Guard's security service is active, whether the UEFI lock is set, and whether adjacent controls like WDigest cleartext caching or LSA protection are configured — as part of its 33 modules, with no limits. Every capability described above is available on one host for free.

Where an organization runs 50 or 500 endpoints, the Pro tier's central node rolls those per-machine results up into a fleet view: which subset of machines report Credential Guard running vs merely configured, drift alerts when a host silently drops out of compliance after a firmware or driver change, and compliance rollups that map the control to CIS and other benchmarks. The agent does the same deep local audit everywhere; the fleet layer is what turns a hundred green checkmarks into a single answer you can hand an auditor.

Bottom line

Credential Guard neutralizes the single most reliable step in the Windows attack chain — LSASS credential theft — by moving the secrets behind a hypervisor-enforced boundary. Enable it with the UEFI lock, keep WDigest and RunAsPPL configured alongside it, and then verify it is running, not just deployed. The gap between "we set the GPO" and "it is actually protecting every box" is where breaches live, and closing that gap is a measurement problem you should be solving continuously.