How to Configure Local Security Authority (LSA) Protection in Windows 11

The Local Security Authority Subsystem Service (lsass.exe) handles user authentication, password changes, and access token creation in the Windows operating system. Because LSASS maintains active Kerberos tickets, NTLM password hashes, and smart card credentials in memory, it is the primary target for attackers using credential dumping tools like Mimikatz. In Windows 11, Local Security Authority (LSA) Protection isolates the LSASS process as a Protected Process Light (PPL), preventing unauthorized processes and unverified drivers from reading credential memory.

Understanding Protected Process Light (PPL) Architecture

Protected Process Light is a security boundary enforced by the Windows kernel. When LSA Protection is enabled:

• Memory Reading Blocked: Unprotected administrative processes cannot open a handle to lsass.exe with PROCESS_VM_READ or PROCESS_ALL_ACCESS rights, neutralizing common memory extraction utilities.
• Code Injection Prevention: Third-party dynamic link libraries (DLLs) cannot inject code into LSASS unless they possess a valid cryptographic signature from Microsoft.
• Kernel-Level Defense: LSA Protection operates independently of third-party antivirus, providing an immutable barrier against credential theft even if an administrative user account is compromised.

Enabling LSA Protection in Windows Security Settings

Windows 11 surfaces LSA Protection directly in the graphical security dashboard:

1. Press Windows Key + I to open the Settings app.
2. Navigate to Privacy & security > Windows Security.
3. Click Device security.
4. Under the Core isolation heading, click Core isolation details.
5. Locate the Local Security Authority protection toggle switch.
6. Toggle the switch to On.
7. Windows prompts for an administrative system reboot. Restart your computer to initialize LSASS inside a protected process light container.

Enforcing LSA Protection via Windows Registry

To automate LSA Protection across standalone machines or custom image deployments using PowerShell:

# Create or update RunAsPPL directive
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" -Name "RunAsPPL" -Value 1 -Type DWord

# Enable RunAsPPLBoot to require hardware UEFI validation
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" -Name "RunAsPPLBoot" -Value 2 -Type DWord

A value of 1 enables standard PPL enforcement, while 2 requires that LSA Protection initialize with UEFI hardware secure boot validation, preventing registry tampering from disabling protection.

Deploying Group Policy for Active Directory and Intune

In managed corporate domains, enforce LSA Protection centrally via Group Policy (gpedit.msc):

1. Navigate to:
   Computer Configuration > Administrative Templates > System > Local Security Authority
2. Double-click the policy setting labeled Configures LSASS to run as a protected process.
3. Select Enabled.
4. In the dropdown under Configure LSASS to run as a protected process, choose Enabled with UEFI Lock (prevents disabling via registry without modifying firmware).
5. Click Apply and OK.

Auditing and Validating LSA Protection in Event Viewer

To confirm that LSASS is running as a protected process without driver conflicts:

1. Press Windows Key + R, type eventvwr.msc, and press Enter.
2. Expand Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.
3. Filter for Event ID 3065 or Event ID 3066.
4. Event ID 3065 confirms that LSASS successfully booted as a protected process with valid cryptographic certificate verification, proving that credential dump attacks are actively mitigated.