Configures LSASS to run as a protected process
The `RunAsPPL` registry value controls whether the Local Security Authority process (`LSASS.exe`) runs with added LSA protection as a Protected Process Light (PPL).
since 0.9.8.11
Purpose
Show registry keys (1)
HKLM\System\CurrentControlSet\Control\Lsa\RunAsPPL
The RunAsPPL registry value controls whether the Local Security Authority process (LSASS.exe) runs with added LSA protection as a Protected Process Light (PPL). LSASS performs functions that include validating local and remote sign-ins, enforcing local security policy, and managing credentials used for authentication.
The value uses the REG_DWORD data type. Microsoft documents these value data:
1: Enables LSA protection and, on capable systems, stores the configuration in a UEFI firmware variable.2: Enables LSA protection without a UEFI lock. This value is enforced only on Windows 11, version 22H2 and later.0: Disables LSA protection controlled through this registry value, provided that an existing UEFI lock does not remain in effect.
A change takes effect at the next system startup.
Notes
Additional effects
When protection is enabled with a UEFI lock on a device with suitable UEFI and Secure Boot support, the configuration is persisted in firmware. Later registry or policy changes cannot remove that firmware setting. On devices without usable UEFI or Secure Boot support, protection instead depends on the registry configuration alone.
LSA protection and Windows Defender Credential Guard are complementary but separate security features. RunAsPPL does not by itself enable the VBS-based secret isolation provided by Credential Guard.
Security
Running LSASS as a protected process prevents unprotected processes from performing certain memory accesses and makes untrusted code injection into LSASS more difficult. This reduces the opportunity for malware to extract credentials managed by LSASS through process-memory access or code injection.
The UEFI-locked mode adds resistance to attempts to disable the protection through registry or policy changes. Without a UEFI lock, an attacker who has sufficient privileges can alter the configuration; disabling the protection takes effect after a restart.
This value does not protect every credential in every circumstance and is not a replacement for Credential Guard or other controls that protect privileged accounts and authentication data.
Possible side effects
LSA plug-ins and drivers must satisfy the signing and security requirements for protected processes. Incompatible components cannot load into LSASS. Examples can include smart card drivers, cryptographic plug-ins, password filters, and password-change notification components.
A component can also be rejected if it uses disallowed shared sections or otherwise fails the protected-process requirements, even when it is signed. Authentication, smart card, or password-related functionality supplied by that component can consequently stop working. Custom LSA plug-ins also cannot be debugged by attaching a debugger to LSASS while it is running as a protected process.
Notes
Microsoft documents the registry-based RunAsPPL configuration for Windows 8.1 and later and Windows Server 2012 R2 and later. The non-UEFI-locked value 2, however, is enforced only on Windows 11, version 22H2 and later.
The ADMX policy with the same display name under “System > Local Security Authority” is a separate policy interface for Windows 11, version 22H2 and later and is mapped to the Software\Policies\Microsoft\Windows\System policy branch. It should not be treated as the same registry location as the direct RunAsPPL system value documented here.
An absent RunAsPPL value does not necessarily mean that protection is disabled on a newly installed Windows 11 system. Starting with Windows 11, version 22H2, Windows can automatically enable LSA protection without a UEFI lock on eligible enterprise-joined, HVCI-capable client devices.
Microsoft documentation
Microsoft Learn: Configure added LSA protection
Microsoft Learn: LocalSecurityAuthority Policy CSP