In Windows operating systems, the Local Security Authority Subsystem Service (LSASS) is the critical security process (lsass.exe) responsible for authenticating users, generating access tokens, validating logon sessions, and enforcing security policies. Because LSASS handles active authentication material, it stores sensitive credentials—including NTLM password hashes, Kerberos tickets, and smart card credentials—directly inside its system memory space. Consequently, LSASS is the primary target for credential-harvesting tools like Mimikatz. To neutralise memory injection and credential dumping attacks, Microsoft introduced Local Security Authority (LSA) Protection in Windows 11.
What Is LSA Protection and How Does It Defend Your PC?
When LSA Protection is active, Windows isolates the lsass.exe executable by running it as a Protected Process Light (PPL):
- Code Signature Enforcement: Windows strictly blocks any non-Microsoft code from loading into the LSASS process space. Third-party DLLs must be digitally signed with a cryptographic Microsoft certificate.
- Memory Injection Prevention: Disallows unprivileged or rogue administrative applications from calling
OpenProcess()or injecting shellcode intolsass.exememory buffers. - Mimikatz and Dump Defense: Blocks credential dumping utilities (such as Task Manager memory dumps, ProcDump, and Mimikatz) from reading password hashes or plaintext credentials.
- Hardware-Enforced Isolation: Works in conjunction with Virtualization-based Security (VBS) and Credential Guard to shield credentials inside a secure virtual container.
Method 1: Enabling LSA Protection via Windows Security Settings
On modern Windows 11 installations, LSA Protection can be activated through the graphical security interface:
- Open the Start Menu, search for Windows Security, and launch the app.
- Click on the Device security tile in the dashboard.
- Under the Core isolation section, click Core isolation details.
- Locate the toggle labelled Local Security Authority protection.
- Switch the toggle to the On position.
- Authenticate through User Account Control (UAC) when prompted.
- Restart your computer to allow the kernel to enforce Protected Process Light rules during boot.
Method 2: Enforcing LSA Protection via the Windows Registry
If the graphical toggle is greyed out or displays false configuration warnings, you can enforce LSA Protection directly via the Windows Registry:
- Press Win + R, type
regedit, and press Enter to launch Registry Editor. - Navigate to the following key path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - Look for a DWORD (32-bit) value named RunAsPPL. If it does not exist, right-click the empty pane, choose New > DWORD (32-bit) Value, and name it
RunAsPPL. - Double-click
RunAsPPLand set its value:1: Enables LSA Protection with UEFI variable lock (cannot be disabled without physical UEFI access).2: Enables LSA Protection without UEFI variable lock (standard software enforcement).
- Also create or verify the DWORD value named RunAsPPLBoot and set its value to
2. - Click OK, exit Registry Editor, and reboot your PC.
Method 3: Enforcing LSA Protection via Group Policy (Pro & Enterprise)
For domain-joined environments or Windows 11 Pro/Enterprise editions, enforce protection across fleet workstations using Group Policy:
- Press Win + R, type
gpedit.msc, and hit Enter. - Navigate to:
Computer Configuration > Administrative Templates > System > Local Security Authority - Double-click the policy setting labelled Configures LSASS to run as a protected process.
- Set the policy state to Enabled.
- In the Options dropdown below, select Enabled with UEFI lock (or Enabled without UEFI lock).
- Click Apply, click OK, and reboot the system.
Verifying LSA Protection Status in Event Viewer
To confirm that the Windows kernel is actively protecting LSASS as a PPL process:
- Right-click the Start menu and select Event Viewer.
- Navigate to Windows Logs > System.
- Filter for Event Source WinInit and look for Event ID 12.
- The event log should state:
LSASS.exe was started as a protected process with level: 4.
Confirming this status ensures your workstation credentials remain fortified against local credential-stealing malware.