Credential Guard

The 3:14 a.m. Mimikatz that returned an empty hash

It is 3:14 a.m. on a 2026 Windows 11 24H2 box. The operator has SYSTEM and SeDebugPrivilege. The operator has bypassed Protected Process Light the way PPLdump [449] did in 2021, has dumped lsass.exe with sekurlsa::logonpasswords from Mimikatz [261], and is staring at the screen.

For the seven years before mid-2015, the next line on that screen would have been the user's NTLM hash. Tonight, the next line is something else entirely.

[LSA Isolated Data]
    NtlmHash
      Is NT Present : True
      Context Handle: 0x0000000000c8...     # opaque per-logon trustlet reference
      Proxy Info    : <pointer into lsass-side session state>
      Encrypted blob: a000000000000000 0800000064000000 ...   # AES-GCM, key only in VTL1
      DPAPI         : <16-byte GUID prefix + wrapped blob>     # ties the record to the per-user DPAPI chain

This schematic block is structurally identical to the PassTheChallenge README [667] example, with identity details removed. Hex prefix, field names, and embedded NtlmHash ASCII tag are the artifact that tells the operator the architectural shift happened.

The literal string [LSA Isolated Data] sits where the NTLM hash used to sit. In the PassTheChallenge README example, the protected record begins with the recognizable prefix a000000000000000, and the visible ASCII tag 4e746c6d48617368 decodes to NtlmHash: serialized metadata survives, the value does not.

This is the deep look at the canonical VBS trustlet responsible for that empty hash. The VBS Trustlets chapter (Chapter 7) uses LsaIso.exe as its running example; this chapter unfolds the things that matter most about it: the extraction history that motivated the design; what LsaIso.exe actually computes and what every field of the encrypted blob means; Pass-the-Challenge, the residual class Credential Guard was never going to close; and the honest, Microsoft-documented limits [311], enumerated.

A note on intent and verification: this is defensive research. Every primary source was verified live on 2026-05-11, against the public web; every command and tool named is in the open-source security canon, used today by Microsoft's own product teams, by enterprise red teams, and by every blue team that takes the storage-versus-use distinction seriously.

The hash is not in the dump because the hash is no longer in the process. Where it went, and why Microsoft moved it, is thirty-three years of lsass.exe history.

Why LSASS became the single highest-value memory dump on Windows (1993 to 2014)

Thirty-three years before the empty hash, lsass.exe shipped in Windows NT 3.1. It was not, at first, the most-attacked process on Windows. It became that, slowly, over the course of a public tool lineage and one architectural realization. This is the tradition the trustlet was built to break.

The architectural reason lsass.exe had to hold the secret is structural to the protocols it speaks. NTLM and Kerberos are challenge-response protocols: the client proves possession of a value derived from the password every time it authenticates: the NTOWF (the MD4 of the UTF-16-LE password) for NTLM, or a long-term key for Kerberos. With respect to the network, that derived value is the credential. How the response is computed, and why holding the NTOWF is equivalent to holding the password (Pass-the-Hash), is developed in The Death of NTLM chapter (Chapter 16). What matters here is the consequence: for single-sign-on to work (the user types the password once, the OS uses it transparently for every later authentication that day) something has to remember that derived value, in clear, in a process that wakes up whenever a remote service asks the kernel to authenticate. That something is lsass.exe. Until 2015, "remembers" meant "holds the bytes in process memory."

The eleven-year road from hash to LSASS dump

The path from "the hash is the password" to "dump it from lsass.exe" took eleven years, and it is told in full elsewhere: the Pass-the-Hash framing in The Death of NTLM chapter (Chapter 16), and the tool lineage (Pass-the-Hash Toolkit, Windows Credential Editor, Mimikatz) in the Mimikatz chapter (Chapter 14). Only the beats that forced the architecture matter here. In 1997 Paul Ashton showed that a client proving possession of the hash makes the hash the credential [666]. In 2008 Hernan Ochoa's Pass-the-Hash Toolkit [669] turned "dump the hash from lsass.exe memory" into a public, repeatable post-exploitation primitive: no cracking, just OpenProcess(VM_READ) on lsass.exe and a parser. From 2011 Mimikatz [617] industrialized the trail, and its sekurlsa::logonpasswords added plaintext recovery from WDigest: a digest SSP that kept the encrypted password and its encryption key in lsass.exe memory at once so it could answer challenges on demand.

On April 6, 2014, at 22:02:03, Delpy committed Mimikatz 2.0 to GitHub as open source [261]; the compile timestamp is in the README banner, verbatim, and Microsoft's lead time on every WDigest-class disclosure dropped from "months" to "the next minute any attacker reads the README." On May 13, 2014, KB2871997 [670] shipped: on Windows 8.1 and Server 2012 R2 and later, the registry value WDigest\UseLogonCredential defaults to 0 and WDigest no longer caches plaintext credentials in lsass.exe memory. The plaintext leg closed. The hash leg could not, because the protocol required it.

By May 2014, Microsoft had patched what could be patched. Mimikatz 2.0 was on GitHub. The hash was still in the process, because it had to be. The next move had to be architectural. But before Microsoft made that move, they tried four other things.

What Microsoft tried before trustlets (1993 to 2014)

If you cannot move the secret, what can you do? Microsoft tried four answers between 1997 and 2014. Each is in production today. None of them moves the secret.

Generation 0: LSASS as an ordinary NT process (1993)

The baseline generation was no protection at all: lsass.exe ran as an ordinary user-mode system process, and the NT kernel that an administrator or driver could control owned the address space holding the credentials.

Generation 1: SYSKEY and on-disk hardening (1997)

SYSKEY moved part of the SAM protection story into boot-time key material, hardening at-rest password-verifier storage without changing the live-session fact that lsass.exe still had to hold usable secrets in memory.

Generation 2: Vista's Protected Process (2007)

In Windows Vista, Microsoft introduced the Protected Process [671] primitive: a binary signed under a designated Microsoft media-protection certificate could run in a process whose memory other Windows processes, including processes running as administrator, could not read or modify. The reason was DRM. Audio and video pipelines wanted a way to keep AACS and PlayReady decryption keys out of debuggers. The Protected Process primitive was not, in 2007, applied to lsass.exe. Six years passed before Microsoft generalized it.

Generation 3: LSA Protection / RunAsPPL (2013)

In Windows 8.1, Microsoft generalized Protected Process into Protected Process Light (PPL) [328], a signer-level lattice that allowed multiple signer "kinds" to live alongside the original DRM kind, and the RunAsPPL registry value lit up lsass.exe as a PPL (the Protected Process Light chapter, Chapter 10, develops the primitive in full).

itm4n's reference write-up of RunAsPPL [328] reproduces what Mimikatz sees on a PPL-protected lsass.exe: the call to OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, FALSE, lsass_pid), the verbatim opener of kuhl_m_sekurlsa_acquireLSA(), fails with 0x00000005, ERROR_ACCESS_DENIED. The hash extraction routine never runs, because the attacker cannot read the page.

itm4n's writeup is also the canonical source for what RunAsPPL is not. The same NT kernel that enforces PPL is the kernel the attacker is trying to subvert. Two bypass classes exist in the public record. The first is kernel-mode: an attacker who loads a signed driver, including Delpy's own mimidrv.sys [328], can suspend PPL enforcement from kernel-space because the kernel is the enforcement mechanism. This is the bring your own vulnerable driver bypass class.

The second is userland: itm4n's PPLdump (April 2021) [449] exploited a structural weakness in the PPL section-validation logic. A new Windows process loads NTDLL, then asks the image loader to load other DLLs. PPLs are allowed to load DLLs from the \KnownDlls directory, and the digital signature of a \KnownDlls entry is checked when the section is created, not when it is mapped into the address space of a PPL process. PPLdump used DefineDosDevice to swap the symbolic link of a \KnownDlls entry; a freshly spawned PPL process (launched from a Microsoft-signed image permitted to run as a PPL) then mapped the swapped-in attacker DLL into its own address space, giving the attacker code execution inside a PPL, which could in turn open and read lsass.exe with PPL enforcement nominally intact. The SCRT writeup [434] is the canonical 2021 reference. Microsoft closed the userland weakness in build 19044.1826, the July 2022 update [331], with an LdrpInitializeProcess patch in NTDLL gated by a Feature_Servicing_2206c_38427506__private_IsEnabled feature flag. On Windows 8.1 and Server 2012 R2, PPLdump's behavior is unstable per the project README [449]: itm4n notes the exploit fails on fully updated machines for an unidentified earlier patch. The userland weakness is therefore closed across the modern estate; legacy boxes that have lapsed on cumulative updates remain the practical exposure.

Generation 4: KB2871997 + the compensating-control playbook (2014)

KB2871997 [670] shipped on May 13, 2014 and rolled up three behavioral changes: WDigest cache disabled by default in Windows 8.1 / Server 2012 R2 and later (UseLogonCredential = 0); the TokenLeakDetectDelaySecs registry default; and Restricted Admin mode for Remote Desktop Connection on Windows 7 / Server 2008 R2. The same broader 2013 to 2014 credential-protection initiative also delivered the Protected Users group [672] (an Active Directory feature shipped in Windows 8.1 [673] / Server 2012 R2 [674], October 2013). Protected Users is the device-side mitigation: members cannot use credential delegation (CredSSP), Windows Digest, NTLM cached credentials or NTOWFs, DES or RC4 in Kerberos preauthentication, or offline cached verifiers; their TGT lifetime is capped at four hours. That AES-only behavior belongs to Protected Users, not to Credential Guard by itself.

Generation 4.5: Tier 0 isolation, jump-server architecture, AdminSDHolder hygiene

The Mitigating Pass-the-Hash v1 (2012) and v2 (2014) playbooks [619] layered organizational changes on top of the per-host technical changes: tier the administrative model so that Tier 0 credentials never log on to Tier 1 or Tier 2 hosts; require every Tier 0 administrative session to traverse a dedicated jump server; clean up AdminSDHolder so that orphaned high-privilege accounts cannot be re-used. The playbooks are still cited in 2026 deployment guides because the underlying recommendations remain correct.

Each of these layers shrinks the attack surface. None of them changes where the hash physically lives. The 2014 conclusion was unavoidable: the only fix is to move the hash out of the kernel that the attacker can compromise. So Microsoft did.

Credential Guard lands, then hardens, then defaults on (May 2015 to November 2024)

On May 4, 2015, Brad Anderson stood at Microsoft Ignite [276] and said "more than 75 percent of all these attacks come down to weak credentials or compromised identities." Eighty-six days later, Windows 10 Enterprise RTM shipped with LsaIso.exe running in VTL1.

The 2015–2024 chronology

On May 4, 2015, the Anderson Ignite keynote announced Virtualization-Based Security, Device Guard, and Credential Guard alongside the Hello and Microsoft Passport identity story. On July 29, 2015, Windows 10 RTM [87] shipped with LsaIso.exe as Trustlet ID 1 on Enterprise and Education SKUs. On August 5 and 6, 2015, Alex Ionescu reverse-engineered the trustlet model at Black Hat USA and published the slide deck [671] that documents the dual-EKU + Signature Level 12 constraint and names LSAISO.EXE as Trustlet ID 1 verbatim.

From 2016 to 2020, Server 2016 brought Credential Guard to server installs [676], and the VSM master key + TPM 2.0 binding [311] hardened the persistent-state path.

On September 20, 2022, Windows 11 22H2 became generally available with Credential Guard default-on for eligible, domain-joined, non-DC devices in supported editions [87], shipped without UEFI Lock. On December 26, 2022, Oliver Lyak published Pass-the-Challenge [677]: the trustlet itself was faithful, but its RPC output became the new attack surface. On November 1, 2024, Windows Server 2025 became generally available [678] and extended the default-on stance to eligible domain-joined servers with the same domain-controller carve-out: "Enabling Credential Guard on domain controllers isn't recommended. Credential Guard doesn't provide any added security to domain controllers, and can cause application compatibility issues on domain controllers." [87]

On eligible domain-joined Windows 11 22H2+ Enterprise/Education devices where the feature has not been explicitly disabled, LsaIso.exe is the default state today [87]. What that small binary actually is, what it computes, and what an attacker who has SYSTEM on the box now sees is the load-bearing technical question.

What LsaIso.exe actually is

The trustlet is a small binary that sits inside a separate kernel from the one your shell is running under. Its identity is precise, its API is small, and its memory is unreadable from the side of the boundary you are on. Microsoft's documentation gives the one-sentence shape:

That one sentence hides everything interesting.

Identity in the trustlet model

LsaIso.exe passes the five-gate trustlet definition [671] by construction: Trustlet ID 1; signed at Signature Level 12; carries both the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6) and the Isolated User Mode EKU (1.3.6.1.4.1.311.10.3.37); exports the s_IumPolicyMetadata structure from a .tpolicy PE section; and is loaded by SMSS / wininit at boot through NtCreateUserProcess with the PsAttributeSecureProcess attribute, which routes through the Secure Kernel (Chapter 6) rather than the NT kernel.

The two EKUs together are the identity gate. A binary that has only the WSCV EKU is a normal Microsoft-signed component.

A binary that has only the IUM EKU does not exist in the wild. A binary that has both, and is signed by Microsoft, is admissible as a trustlet. The IUM EKU is not issued by any commercial CA; it is a Microsoft-internal OID with a Microsoft-internal issuance policy.

That identity check is not a decorative signature policy. It is the load contract that decides whether the process is created as an ordinary user-mode process under the NT kernel or as a secure process whose execution belongs to the isolated user-mode world. PsAttributeSecureProcess is the visible process-creation switch: SMSS / wininit asks for a secure process, the Secure Kernel participates in the create path, and the .tpolicy metadata tells the secure side what the trustlet is allowed to be. The trustlet ID is therefore not discovered by scanning lsass.exe; it is established at boot by a signed image, a policy section, and a secure-process attribute that ordinary administrators cannot mint.

The practical consequence for an attacker is subtle but important. Replacing LsaIso.exe is not analogous to dropping a new SSP DLL into lsass.exe, because the replacement would need Microsoft's IUM EKU and policy metadata to be admitted as a trustlet. Debugging it is not analogous to attaching WinDbg to a normal service, because the pages and scheduler state live behind the Secure Kernel. PPL can be bypassed by attacking code-signing policy or kernel callbacks inside VTL0; the trustlet identity path moves the admission decision into the VTL1 loader. That is why the chapter keeps separating PPL from Credential Guard: PPL hardens an NT process; Credential Guard changes which kernel owns the secret-bearing process.

The agent / trustlet split

Credential Guard splits lsass.exe (the historical agent) into two cooperating processes:

• lsass.exe in VTL0 holds protocol state, network I/O, and every Security Support Provider DLL the system loads: msv1_0.dll (NTLM), kerberos.dll (Kerberos), negoexts.dll (SPNEGO extensions), cloudap.dll (the Microsoft Entra cloud authentication package), wdigest.dll (Digest, with caching disabled), tspkg.dll (Terminal Services / CredSSP), livessp.dll (Microsoft account / Live), pku2u.dll (peer-to-peer Kerberos), and schannel.dll (TLS). The core SSP/AP set (Negotiate, Kerberos, NTLM, Digest, CredSSP, Schannel) is enumerated in Microsoft's SSP Packages Provided by Microsoft [679] reference; CloudAP, NegoExts, TSPkg, LiveSSP, and PKU2U are documented under the broader LSA Authentication [668] reference. lsass.exe does not hold the long-lived NTOWF or Kerberos long-term keys.
• LsaIso.exe in VTL1 holds the long-lived NTLM hashes and Kerberos long-term key material, plus a narrow RPC API that lets the agent compute responses against those secrets without ever exposing them.

The architectural pivot is that the mimikatz-style memory dump still reaches lsass.exe, but it no longer reaches the long-term key. The key has moved across a boundary the hypervisor (Chapter 9, Above Ring Zero) enforces with hardware page-table-permission bits, and no VTL0 process, regardless of token, regardless of privilege, can map the page.

Think of the split as a storage-vs-use redesign rather than a parser rewrite. msv1_0.dll still parses NTLM messages, kerberos.dll still owns Kerberos protocol state, CloudAP still brokers cloud authentication, and the logon session still has handles, tickets, package state, and network-facing code in VTL0. What changed is the custody rule for material that remains valuable after the current protocol exchange: the NTOWF, Kerberos long-term keys, and Kerberos TGT material move into VTL1. The agent may ask, "derive the response for this challenge with this context handle"; it may not ask, "give me the NTOWF bytes." That one-way API shape is why an empty hash is success rather than breakage.

The split also explains the residuals that survive later in the chapter. Pass-the-Ticket survives because Kerberos service tickets and their use path still exist on the agent side; Microsoft explicitly says service tickets are not protected, while the TGT is [311]. Pass-the-Challenge exists because the trustlet must return NTLM responses if the enterprise still speaks NTLM. Third-party SSP breakage happens because an SSP that expected to query supplemental long-term material from LSASS is now asking the wrong process. Credential Guard is therefore best described as isolating long-lived credential storage while preserving enough credential use to keep Windows logon and SSO functional.

The encrypted-blob format and the IUM API

The visible artifact of the move is the [LSA Isolated Data] block in the opening Pypykatz-style dump. The structure of that block is documented byte-by-byte in the PassTheChallenge README [667]: an opaque encrypted payload, a Context Handle (an opaque RPC handle that identifies the per-logon session inside the trustlet), a Proxy Info field that points to the protocol-side session metadata in lsass.exe, and a DPAPI GUID that ties the encrypted blob to the per-user DPAPI master-key chain.

The public PassTheChallenge tooling exposes the four operation classes that matter for NTLM authentication [667]:

1. Wrap / unwrap protected data: opaque blobs can be round-tripped through lsass.exe memory without lsass.exe seeing the cleartext.
2. Protect a credential: the protect command converts an NT hash into an encrypted blob, modeling the post-logon ingestion path where the trustlet internalizes the NTOWF.
3. Compute an NTLMv1 response: the nthash command asks for a response from encrypted credentials and accepts an optional server challenge.
4. Compute an NTLMv2 response: the challenge command asks for an NTLMv2 response using encrypted credentials and supplied challenge metadata.

The Pypykatz fork output structure carries the exact byte layout for all of this: Is NT Present, Context Handle, Proxy Info, Encrypted blob, DPAPI. The verbatim hex prefix a000000000000000080000006400000001000000010100000100000036 is a length-prefixed serialization header. The literal string 4e746c6d48617368, which decodes from hex to the ASCII string NtlmHash, is visible serialized metadata in the protected record. The opaque payload is the wrapped NTOWF; the tag tells you what the protected value represents without exposing the value itself.

Read as bytes rather than as a secret, the identifying prefix decomposes into a small serialized header: protection level 0xa0, fixed-width little-endian length fields, version 0x01, cipher identifier 0x01, and a short tag-length field before the encrypted payload. The source documents the hex-dump shape and the embedded NtlmHash ASCII tag, but does not name every byte field; that decomposition is illustrative rather than a captured Microsoft structure. The load-bearing fact is simpler and stronger: the blob starts with the same recognizable protected-record prefix, and deeper in the serialized record the literal hex 4e746c6d48617368 decodes to NtlmHash.

The four fields around the blob tell you which side of the boundary owns which fact. Is NT Present is the agent-side statement that this logon session has an NTLM credential at all. Context Handle is not the hash; it is an opaque capability that lets lsass.exe refer back to the trustlet's per-logon record without learning the record. Proxy Info points to the VTL0 session metadata the SSP needs for protocol bookkeeping. DPAPI ties the isolated in-memory record to the per-user protection chain so that secrets that must be protected at rest can be re-associated with the user's key hierarchy. That is the whole design in one dump: identifiers and routing data remain visible, while the long-term credential is an opaque protected payload only the trustlet can unwrap.

The operation names are equally revealing. Protecting a credential is a post-logon ingestion step: the user has typed a password, the VTL0 package has briefly derived the NTOWF, and the trustlet immediately wraps and internalizes the value. The NTLMv1 and NTLMv2 operations are use calls: given a context and a challenge, return the derived response. The wrapper operations are the generic "round trip through LSASS, never reveal cleartext to LSASS" property. The public reverse-engineering surface is narrow because every extra verb would become an extra way to ask dangerous questions about the secret.

The LSA_ISO_RPC_SERVER ALPC port

The agent reaches the trustlet through a secure-call route exposed to the LSA side as LSA_ISO_RPC_SERVER (terminology per Lyak's writeup [677]). Microsoft documents the fact of RPC communication between LSA and isolated LSA [311]; Lyak and Ionescu document the route and reverse-engineered mechanics [671], [677]. Treat the exact marshalling sequence as reverse-engineered implementation detail rather than a Microsoft-stated contract: a VTL0 caller submits an IUM Base API request, secure-world code validates and dispatches it, and only marshalled inputs and outputs cross the boundary.

For credential use, this endpoint is the externally visible surface attackers have documented. There is no supported debugger or driver-load path into LsaIso.exe; claims about the absence of every possible internal channel should be read as a statement about the documented and publicly reverse-engineered attack surface, not a complete Microsoft interface inventory.

The mechanics matter because they turn the port into both the protection boundary and the attack boundary. The remote SMB server sends an eight-byte challenge; msv1_0.dll receives it in VTL0; LSASS packages the context handle and challenge into the IUM Base API call; secure-world code validates and dispatches the marshalled request; LsaIso.exe retrieves the isolated NTOWF for that handle; the trustlet computes the protocol response; and the Secure Kernel copies back the derived response, not the key. If the host is forced into NTLMv1, that returned value is the crackable 24-byte DESL response exploited by Pass-the-Challenge. If the host uses NTLMv2, the response still leaves the trustlet, but the offline attack economics are different. The interface therefore shrinks theft of a reusable hash into abuse of a protocol-specific output.

That is also why DLL injection into lsass.exe is sufficient for Pass-the-Challenge but insufficient for hash dumping. An injected SSP can stand next to the legitimate agent code and call the same LSA_ISO_RPC_SERVER route, because the route exists to keep SSO working. It cannot read VTL1 pages or ask the endpoint to export the NTOWF, because neither operation is in the API. This is the core operational pattern defenders should remember: Credential Guard removes the memory-read primitive; it does not remove every possible authenticated computation over the protected key.

The MSV1_0\IsolatedCredentialsRootSecret registry sentinel

One registry artifact correlates with default-on Credential Guard activation: the value Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret. Microsoft documents this value on the Credential Guard overview page [87] as the way to detect the Pro / Pro Education Enterprise-carry-over state; it is a detection check, not a general configuration API like LsaCfgFlags or Get-CimInstance Win32_DeviceGuard. Its presence on a Windows 11 22H2+ Pro / Pro Education box is consistent with default-on having activated the feature. Absence does not by itself prove a problem: the device may simply never have been in the Enterprise carry-over state, or Credential Guard may be disabled by policy, or the hardware may not meet the VBS and Secure Boot requirements.

TPM binding and the VSM master key

Persistent state in Credential Guard is rare. The trustlet does not normally persist the NTOWF or TGT material across reboots; the next user logon re-derives both. When persistence is needed, the data is sealed under what Microsoft calls the VSM master key:

"On recent supported hardware with TPM 2.0, VSM data that is persisted will be protected by a key called the VSM master key, which is protected by device firmware protections.... The VSM master key is protected by the TPM, ensuring that the key and secrets protected by Credential Guard can only be accessed in a trusted environment." [311]

The key hierarchy is intentionally boring from the attacker's point of view. Pulling the disk gives ciphertext. Booting another OS changes the measured-boot state and loses the TPM unseal policy. Owning the VTL0 NT kernel gives scheduling, drivers, and ordinary kernel memory, but not the VTL1-only key bytes. The remaining path is to make the legitimate booted system perform legitimate operations for you, which is why the later sections emphasize protocol outputs, token abuse, and supplied plaintext rather than mythical "dump the VSM master key from LSASS" steps. The master key is a persistence wrapper for rare VSM state, not a convenient universal password vault.

Where the hash physically lives, in 2026, is in pages of LsaIso.exe that the VTL0 NT kernel cannot map. What an attacker on a default-on Credential Guard box actually sees, what the verification surface for defenders is, and what the operational reality looks like in production are now operational questions, not architectural ones.

The operational reality of default-on Credential Guard

Default-on means specifics. Specifically: an eligible domain-joined Windows 11 22H2+ Enterprise / Education device that meets the hardware and software requirements and has not been explicitly configured to disable Credential Guard should have Virtualization-Based Security up, LsaIso.exe running, and Credential Guard present in the SecurityServicesRunning array of Win32_DeviceGuard. Pro and Pro Education boxes are not ordinary default-on targets; the special case where a Pro/Pro Edu device previously ran Credential Guard on Enterprise is the carry-over path, and Microsoft documents the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret sentinel as the way to detect that state [87].

Default-on scope and the no-UEFI-lock choice

Microsoft's Credential Guard overview page [87] is precise about scope: Windows 11 22H2 and later (Enterprise, Education), Windows Server 2025, domain-joined non-DC, hardware-eligible (Hyper-V Generation 2 VM with IOMMU on virtual hardware; UEFI Secure Boot and virtualization extensions required on physical hardware, with a TPM (1.2 or 2.0) and IOMMU recommended for additional protection). Pro and Pro Education hold the license entitlement only via the Enterprise-to-Pro carry-over case. The default-on policy ships "without UEFI Lock" [87], which is a deliberate trade-off.

The three supported verification surfaces

Microsoft's configuration guide [664] names three supported ways to verify Credential Guard is running, and explicitly disrecommends a fourth:

1. msinfo32: opens the System Information UI; the line "Virtualization-based Security Services Running" includes "Credential Guard" when the trustlet is up.
2. PowerShell Get-CimInstance Win32_DeviceGuard: returns a SecurityServicesRunning array of service identifiers, not a bitmask.
3. WinInit Event ID 13 in the System log: "Credential Guard (LsaIso.exe) was started and will protect LSA credentials." [664]

The disrecommended approach is "look for LsaIso.exe in Task Manager." Microsoft's words: "Checking Task Manager if LsaIso.exe is running isn't a recommended method for determining whether Credential Guard is running." [664] Task Manager is a weak administrative signal because it runs in VTL0 and queries ordinary process enumeration. The three supported surfaces are better configuration and health checks, but they are not remote attestation and should not be treated as tamper-proof forensic proof after a SYSTEM or kernel compromise.

Read the PowerShell value as an array of service IDs. 1 means Credential Guard; 2 means Hypervisor-enforced Code Integrity; 3 means System Guard Secure Launch; 4 means SMM Firmware Measurement; 5 and 6 are kernel-mode hardware-enforced stack protection in enforce and audit modes; 7 is Hypervisor-Enforced Paging Translation. MBEC is not part of this array at all: it is a CPU capability advertised in the separate AvailableSecurityProperties array. A healthy default-on endpoint commonly reports [1, 2], which should be read as "Credential Guard and HVCI are running," not as a bitwise sum.

Proof on a live machine

The claims above are architecture; a Reasoner should not take them on faith. The following are verbatim captures from our lab VM, each tagged and hash-stamped. The build gate re-hashes every block against the capture manifest, so these bytes cannot have been edited to fit the prose.

First, that Virtualization-Based Security is actually running and Credential Guard is one of the services it hosts:

VirtualizationBasedSecurityStatus = 2  # Running
SecurityServicesConfigured        = CredentialGuard, HypervisorEnforcedCodeIntegrity
SecurityServicesRunning           = CredentialGuard, HypervisorEnforcedCodeIntegrity
LsaIso_process_present = True
LsaIso_pid             = 1008
Scenarios\CredentialGuard\Enabled = 1

VirtualizationBasedSecurityStatus = 2 is the hypervisor reporting VBS running, not just configured. SecurityServicesRunning is a uint32[] array (not a bitmask) whose presence of CredentialGuard is what the supported verification surfaces ultimately read. (A raw Get-CimInstance returns these enum codes as integers, e.g. {1, 2} for Credential Guard and HVCI; the capture maps them to names for readability.) And LsaIso_process_present = True with a live PID is the trustlet itself, the process whose pages VTL0 cannot map.

Second, the agent/trustlet split as two distinct, co-resident processes:

pid             = 1016
CredentialGuard_running = True
LsaIso_trustlet_present = True
LsaIso_pid              = 1008   # secrets live here, isolated from lsass in VTL1
SecureSystem_present    = True   # the secure kernel host process

Read this as a Reasoner: lsass.exe (pid 1016) is the agent you can reach; LsaIso.exe (pid 1008) is the vault you cannot; SecureSystem is the VTL1 host that mediates between them.

Third, the on-box configuration sentinels that say this state is policy, not accident:

LsaCfgFlags (Cred Guard) = 2
RunAsPPL (LSASS protected process) = 2
CachedLogonsCount   = 10  # # of cached domain logons

LsaCfgFlags = 2 is the policy register's own read-back: Credential Guard enabled, without UEFI lock. RunAsPPL = 2 carries the same scheme (1 = enabled with UEFI lock, 2 = without), but it is a different feature, and conflating them is the most common architectural error in defensive reviews:

What changes for the protocols

When Credential Guard is enabled, four SSPs lose the ability to use signed-in credentials: "NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials" [311]. For NTLMv1 and Digest the practical effect is small (NTLMv1 is end-of-life: see The Death of NTLM chapter (Chapter 16); Digest is essentially unused outside legacy HTTP digest authentication). For MS-CHAPv2 and CredSSP the effect is real: any single-sign-on path that depended on those protocols breaks with Credential Guard on. The considerations page [681] calls out PEAP-MSCHAPv2 / EAP-MSCHAPv2 WiFi and VPN configurations explicitly: "If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1." [681] The recommended remediation is to migrate the endpoints to PEAP-TLS / EAP-TLS (certificate-based authentication).

For Kerberos, Credential Guard "doesn't allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials" [311]. Constrained Delegation and Resource-Based Constrained Delegation continue to work. Credential Guard itself does not make the estate AES-only; RC4 is handled by Kerberos policy and account configuration, while Protected Users is the feature in this chapter that forbids RC4 for its members [672].

What doesn't change

The agent surface still exposes every SSP that loads inside lsass.exe. The trustlet isolates the secret the SSP uses; it does not isolate the parser that the SSP runs against an attacker-controlled wire format. A bug in msv1_0.dll's NTLM parser is exactly as exploitable on a 2026 Credential-Guard-on box as it was on a 2015 Credential-Guard-off box. The trustlet does not guard the agent; the trustlet guards the key.

Credential Guard is on; the surface is documented; the verification is one PowerShell line. So what other things claim to "protect LSASS," and how do they fit together with Credential Guard?

The other things that "protect LSASS"

Six other things in the Microsoft security stack get called "LSASS protection" in someone's marketing. None of them is a substitute for Credential Guard. Most of them are complements. The difference matters because the choice between them is not a choice; the answer is all of them, layered.

LSA Protection's kernel-driver-loader bypass class is closed by HVCI for unsigned drivers but not for signed-and-vulnerable ones. Defender for Identity is a detection layer, not a TCB boundary. The Windows Hello chapter (Chapter 20) develops Hello for Business, which replaces the password with a TPM-bound asymmetric key [253]: the Hello for Business overview [253] row in the Security comparison table reads "It uses key-based or certificate-based authentication. There's no symmetric secret (password) which can be stolen from a server or phished from a user and used remotely." The Microsoft Entra ID Primary Refresh Token (PRT) inside cloudap.dll is the cloud-joined analog of the on-prem identity problem: Microsoft documents device/TPM binding for PRT protection [683], while this chapter should not imply that the PRT itself is necessarily in LsaIso.exe custody. Restricted Admin and Protected Users [672] suppress credential delegation at the protocol layer; on a Credential-Guard-on box they are additionally effective because they remove the prompt path, but they are not a substitute for the storage-isolation primitive.