How to Configure LSA Protection and Audit Mode in Windows 11 Using PowerShell

The Local Security Authority Subsystem Service (LSASS) is the central security process responsible for authenticating users, managing password hashes, and generating Kerberos access tokens in the Windows operating system. Because LSASS maintains credentials in active memory, it is the primary target for credential-dumping tools like Mimikatz, ProcDump, and Cobalt Strike beacons. Windows 11 includes Local Security Authority (LSA) Protection, which runs LSASS as a Protected Process Light (PPL). Running LSA Protection in Audit Mode via PowerShell allows administrators to identify incompatible third-party drivers or authentication packages before enforcing strict blocking.

Understanding LSA Protection as a Protected Process Light (RunAsPPL)

In standard Windows configurations, any process running with local Administrator or SYSTEM privileges can acquire the PROCESS_VM_READ permission and inspect LSASS process memory space.

When LSA Protection is configured with RunAsPPL:

• The kernel restricts memory access to LSASS strictly to processes signed with a verified Microsoft certificate.
• Non-PPL administrative processes—even running as elevated Administrator—cannot attach debuggers or read LSASS virtual memory.
• Any third-party Authentication Packages (such as custom smart card drivers, VPN plug-ins, or legacy biometric filters) must be digitally signed with a WHQL or Microsoft Authenticode certificate, or they will be blocked from loading into the LSA process space.

Prerequisites and Environment Setup

• Windows 11 Pro, Enterprise, or Education edition.
• Secure Boot enabled in firmware (recommended for tamper protection).
• An elevated PowerShell session running as Administrator.

Configuring LSA Protection in Audit Mode via PowerShell

Before enforcing PPL protection, always run in Audit Mode. In Audit Mode, Windows permits third-party unsigned plugins to load into LSASS normally, but logs an event whenever an unsigned DLL or unauthorized memory access attempt occurs.

To enable LSA Audit Mode, write the AuditLevel value to the Windows Registry:

# Registry path for Local Security Authority
$LsaPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"

# Configure LSA Audit Mode (Value 8 = Audit Mode enabled)
Set-ItemProperty -Path $LsaPath -Name "AuditLevel" -Value 8 -Type DWord

After setting AuditLevel to 8, restart the workstation to begin logging audit events:

Restart-Computer -Force

Reviewing LSA Audit Events in Windows Event Viewer

Once rebooted, Windows logs LSA audit events under the CodeIntegrity channel:

• Event ID 3065: Code integrity determined that a process attempted to load a driver or plug-in that did not meet the signing requirements for a protected process, but allowed it due to audit policy.
• Event ID 3066: Code integrity generated an audit report for an unsigned binary loaded into LSA.

To query these audit events directly from PowerShell without manually navigating Event Viewer:

Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-CodeIntegrity/Operational"
    Id = 3065, 3066
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message | Format-List

Inspect the logged binary file paths. If third-party authentication drivers (e.g., legacy smart card middleware) appear in the logs, contact the vendor for updated, signed versions before enabling full PPL enforcement.

Enforcing Full LSA Protection (RunAsPPL)

Once you have validated that no critical software triggers audit warnings, enforce full LSA Protection:

# Configure LSA to run as Protected Process Light (Value 1 = Enabled with UEFI Lock, Value 2 = Enabled without UEFI Lock)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1 -Type DWord

# Remove the temporary audit flag
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "AuditLevel" -ErrorAction SilentlyContinue

Restart the computer to initialize LSASS inside the PPL boundary:

Restart-Computer -Force

Verifying LSA Protection Status Post-Reboot

After restarting, open PowerShell as Administrator and verify that LSASS is running with PPL protection:

Get-WinEvent -FilterHashtable @{
    LogName = "System"
    ProviderName = "Microsoft-Windows-Wininit"
    Id = 12
} -MaxEvents 1 | Select-Object TimeCreated, Message | Format-List

When active, Event ID 12 explicitly confirms: “LSASS.exe was started as a protected process with level: 4” (Protected Process Light).

Best Practice Tips for Enterprise Deployment

• Enforce via Group Policy: For domain-wide deployments, configure Computer Configuration > Administrative Templates > System > Local Security Authority > Configure LSA to run as a protected process.
• Complement with Credential Guard: Run LSA Protection alongside Virtualization-Based Security (Credential Guard) for multi-tiered hardware memory isolation.