Enable LSA Protection and Credential Guard to Prevent Credential Theft

The Local Security Authority Subsystem Service (LSASS) stores credential material in memory — NTLM hashes, Kerberos tickets, and in some configurations plaintext-equivalent secrets. Tools like Mimikatz and its many derivatives work by reading or dumping LSASS memory, which is often the first step attackers take after gaining local admin on a machine. Two built-in Windows features close most of this attack surface: LSA Protection and Credential Guard.

What each feature does

• LSA Protection (RunAsPPL) runs LSASS as a Protected Process Light. Non-protected processes — including tools running as admin — can no longer open LSASS with read or dump access. Only signed, protected code can interact with it.
• Credential Guard goes further and moves secrets out of LSASS entirely. Using virtualization-based security (VBS), NTLM hashes and Kerberos ticket-granting tickets are stored in an isolated process (LSAIso) that even the kernel cannot read. A full memory dump of LSASS yields nothing usable.

How to deploy

• Enable LSA Protection via Group Policy: Computer Configuration > Administrative Templates > System > Local Security Authority > Configure LSASS to run as a protected process, or via the registry value RunAsPPL = 1 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
• Before enforcing, run in audit mode by setting the Audit Level registry value and monitor Event IDs 3065 and 3066 to identify plugins or drivers that would fail to load.
• Enable Credential Guard via GPO: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, selecting Credential Guard with UEFI lock. On Windows 11 22H2 and later it is enabled by default on eligible devices.
• Verify with msinfo32 — look for "Virtualization-based security Services Running: Credential Guard" — or check for the LsaIso.exe process.

Compatibility notes

• Some third-party authentication modules, smart card drivers, and older security agents are incompatible with RunAsPPL. The audit phase exists precisely to catch these before enforcement.
• Credential Guard requires UEFI, Secure Boot, and virtualization extensions. It also breaks NTLMv1, MS-CHAPv2, and unconstrained Kerberos delegation — audit for these dependencies first.
• Credential Guard does not protect local account credentials (SAM database) or credentials typed into a phishing page. It is one layer, not a complete solution.

Deploy LSA Protection first — it is low-risk and applies to a wider range of hardware — then roll out Credential Guard in rings, starting with IT and pilot machines before domain-wide enforcement.