Credential Guard and LSA protection: protect LSASS

LSASS (the Local Security Authority Subsystem Service) holds the secrets that make single sign-on work: NTLM hashes, Kerberos tickets and keys, and sometimes more. Any process that can read LSASS memory can harvest those secrets and reuse them elsewhere. Credential dumping from LSASS appears in a very large share of hands-on intrusions, which is why Windows now ships two dedicated defences:

• LSA protection (RunAsPPL) runs LSASS as a protected process light. Only code signed with the right protection level can open it for memory reads or code injection, even when the attacker is a local administrator.
• Credential Guard uses virtualization-based security (VBS) to move NTLM hashes, Kerberos TGT session keys and stored domain credentials into an isolated process, LsaIso.exe, running in a separate virtual trust level. LSASS talks to it over RPC and never holds the raw secrets itself.

They complement each other and should be enabled together.

Requirements

What breaks

Both features remove capabilities, by design. Plan for:

• Third-party LSA plug-ins and drivers that are not signed for protected processes. Smart card middleware, some password filters, older security products. LSA protection has an audit mode for this; use it.
• With Credential Guard: NTLMv1, MS-CHAPv2 and Digest single sign-on no longer work with saved credentials, Kerberos unconstrained delegation and DES encryption are blocked, and CredSSP cannot delegate saved or default credentials. Wi-Fi and VPN profiles that use MS-CHAPv2 (PEAP-MSCHAPv2) will prompt or fail when relying on saved Windows credentials. Move them to certificate-based authentication (EAP-TLS) first.

Step 1: audit LSA protection before enforcing

Set LSASS to audit mode on a pilot group (Windows 11 22H2 and later already audit by default). This logs every module that would fail to load under protection without blocking anything:

Key:   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe
Value: AuditLevel  (REG_DWORD) = 8

Reboot and review Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational:

• Event 3065: LSASS tried to load a driver or module that does not meet the security requirements for shared sections.
• Event 3066: LSASS tried to load a module that does not meet the Microsoft signing level requirements, so it would be blocked once protection is on.

Contact the vendor of every module listed. Most current security and authentication products ship properly signed LSA components.

Step 2: enable LSA protection

Group Policy (Windows 11 22H2 and later, and Server 2025 ADMX): Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process, set to Enabled with UEFI Lock or Enabled without UEFI Lock.

The equivalent registry value, which also works on older builds:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: RunAsPPL  (REG_DWORD)
       1 = enabled with a UEFI variable (cannot be turned off by registry alone)
       2 = enabled without UEFI lock (Windows 11 22H2 and later)

The UEFI lock is stronger, because an attacker with admin rights cannot simply flip the registry and reboot. It also means disabling later requires a documented opt-out tool and physical presence, so use it once you are confident in compatibility.

Verify after reboot in the System log: Event 12 from source Wininit states that LSASS.exe was started as a protected process with level: 4.

Step 3: enable Credential Guard

Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security:

Registry equivalents, for scripted or non-domain deployment:

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
  EnableVirtualizationBasedSecurity   REG_DWORD 1
  RequirePlatformSecurityFeatures     REG_DWORD 1  (Secure Boot)  or 3 (Secure Boot + DMA)

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  LsaCfgFlags                         REG_DWORD 1  (with UEFI lock) or 2 (without lock)

In Intune, use Endpoint security > Account protection or a settings catalog profile for Credential Guard.

Step 4: verify

On the device, msinfo32 shows Virtualization-based security: Running and lists Credential Guard under Virtualization-based security Services Running. From PowerShell:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus   # 2 = running
$dg.SecurityServicesRunning             # contains 1 = Credential Guard, 2 = HVCI (memory integrity)

Microsoft does not recommend checking Task Manager for LsaIso.exe; instead look in the System log for Event 13 from WinInit (Credential Guard (LsaIso.exe) was started and will protect LSA credentials). Collect these values fleet-wide through your management tool or a compliance script, because firmware updates, BIOS resets and hardware swaps can quietly turn VBS off.

Step 5: turn off the legacy leftovers

Credential Guard and PPL protect what LSASS holds. Reduce what it holds in the first place:

Also enable the ASR rule Block credential stealing from the Windows local security authority subsystem (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2), which adds another barrier for devices where Credential Guard cannot run. See the ASR rules guide.

Detection still matters

Neither feature protects credentials typed into a compromised machine (a keylogger still sees them), local account hashes in the SAM, or the NTDS.dit database on domain controllers. Keep detecting:

• Process access to lsass.exe with memory-read rights (Sysmon Event 10, or your EDR).
• Changes to RunAsPPL, LsaCfgFlags and UseLogonCredential (registry auditing or Sysmon Event 13).
• Creation of LSASS dump files (Sysmon Event 11 for *.dmp written by unusual processes).

Checklist

• LSA protection audited (events 3065/3066), then enforced with UEFI lock
• Event 12 confirms protected process level on every host
• VBS and Credential Guard running on all eligible clients and member servers
• Wi-Fi/VPN moved off MS-CHAPv2 before Credential Guard rollout
• WDigest off and monitored; cached logons reduced
• ASR LSASS rule in block mode
• Fleet report on SecurityServicesRunning, re-checked after firmware updates

These two settings turn the single most reliable post-exploitation technique on Windows into an unreliable one. Combined with admin tiering, there is simply less worth stealing and fewer places to steal it from.