Protecting LSASS: LSA protection and Credential Guard, what they block and what they don't
The LSASS process keeps authentication material for signed-in users in memory: NT hashes, Kerberos tickets, sometimes more. An attacker with local admin rights on a machine almost always tries to extract them to move elsewhere. LSA protection and Credential Guard address this threat in two different and complementary ways.
Why LSASS is a target
To enable single sign-on to network resources, Windows keeps derivatives of each session's credentials in LSASS. A domain administrator who signs in to a compromised server therefore leaves reusable material behind. Extracting that material and replaying it (pass-the-hash, pass-the-ticket) is the main engine of lateral movement in directory compromises.
LSA protection (RunAsPPL)
LSA protection runs LSASS as a protected process light (PPL). Only processes with an equivalent protection level can then read its memory or inject code into it, and only modules signed to Microsoft's requirements can load into it. A tool running with administrator rights can no longer simply open LSASS and read its contents.
It is enabled through the RunAsPPL registry value under the LSA key, or through Group Policy on recent versions. With value 1 on a UEFI machine with Secure Boot, the setting is locked in a UEFI variable and cannot be disabled by just editing the registry. Recent Windows 11 versions enable it by default under certain conditions; check the current Microsoft documentation for your version.
Limitations. An attacker able to load a kernel driver can bypass the protection. It also does not protect the local SAM database or LSA secrets stored in the registry.
Credential Guard
Credential Guard goes further by relying on virtualisation-based security (VBS). The most sensitive secrets, notably NT hashes and Kerberos TGTs, are kept in an isolated process, LSAIso, running in an environment the operating system itself cannot read. LSASS only handles references. Even with kernel access, an attacker cannot extract those secrets.
Credential Guard is enabled by default on recent Windows 11 Enterprise and Education editions that meet the hardware requirements, and Microsoft has extended this behaviour to Windows Server 2025 under certain conditions. The prerequisites (64-bit CPU, virtualisation extensions, Secure Boot, TPM recommended) and default enablement rules change over time: check them in the current Microsoft documentation.
| Credential Guard protects | Credential Guard does not protect |
|---|---|
| NT hashes of domain sessions | Passwords captured as they are typed (keyloggers) |
| Kerberos TGTs | Local accounts and the SAM database |
| Domain credentials saved in Credential Manager | Service tickets already issued, usable while valid |
| Actions carried out directly on the compromised machine during the session |
Compatibility impact
Credential Guard blocks legacy mechanisms: NTLMv1, MS-CHAPv2 with signed-in credentials (some VPNs and PEAP Wi-Fi networks), Kerberos unconstrained delegation and DES encryption. LSA protection can prevent non-compliant third-party modules from loading (authentication providers, some older smart card drivers or security agents).
Audit before enforcing. LSA protection has an audit mode that logs, in the CodeIntegrity log, the modules that would have been blocked. Let it run on a representative sample before enabling. For Credential Guard, test VPN and Wi-Fi access first.
Deployment on servers and workstations
- Workstations. Enable both protections across the eligible fleet, via Group Policy or Intune, after the audit phase.
- Member servers. Enable LSA protection broadly; enable Credential Guard on servers where administrators sign in interactively, after checking application compatibility.
- Domain controllers. Credential Guard brings no benefit there, since the directory database holds every secret anyway. LSA protection is still recommended.
- Virtual machines. Credential Guard requires nested virtualisation and a compatible hypervisor; check your platform configuration.
None of these protections replaces tiering: the best way to avoid having a domain admin credential stolen is never to use it on a lower-tier machine.
What an audit checks
- the actual running state of LSA protection and Credential Guard, not just the presence of a GPO;
- UEFI locking of LSA protection on compatible machines;
- dependencies on NTLMv1, MS-CHAPv2 or unconstrained delegation;
- coverage of servers where privileged accounts sign in;
- WDigest being disabled and no unnecessary credential caching.