Windows LSA Protection Operations: Audit Plug-Ins, Enable PPL, and Verify LSASS Startup

Local Security Authority (LSA) protection runs LSASS as a protected process so that nonprotected processes cannot read its memory or inject code into it under the supported Windows security model. This helps protect credentials and authentication components from some local attacks, but it does not make an administrator-level compromise harmless or replace Credential Guard, endpoint protection, application control, or least privilege. LSA protection and Credential Guard are complementary: LSA protection constrains which code can interact with LSASS, while Credential Guard uses virtualization-based security to protect supported secrets in an isolated environment.

Enabling protection without inventorying the software that loads into LSA can break sign-in or security integrations. Smart-card and cryptographic providers, password filters, credential providers, and third-party identity/security products can depend on plug-ins that must meet the required signing and protected-process constraints. Use audit mode, inspect Code Integrity evidence, test all authentication paths, and only then enforce. Choose UEFI lock with explicit recovery planning because changing a registry value alone cannot remove the firmware variable.

Inventory the platform and LSASS integrations

Inventory Windows editions, builds, firmware and Secure Boot state, domain or management enrollment, Credential Guard/HVCI configuration, and the installed authentication stack. Include interactive, remote, service, smart-card, VPN, biometric, password-change, and break-glass logons. Ask product owners to identify components that install LSA plug-ins, password filters, SSP/AP packages, or drivers that interact with LSASS. Do not treat a successful local password sign-in as coverage for every authentication path.

Record how LSA protection is currently configured: policy source, registry state, whether a UEFI variable is present, audit value, restart status, and the endpoint population. Windows 11 version 22H2 and later can enable LSA protection by default on qualifying new installations, but that does not imply all upgraded devices or every server has the same effective state. Confirm the actual startup evidence on each build family.

Use audit mode before enforcement

Audit mode records plug-ins and drivers that would fail protected-process requirements without blocking them. Microsoft’s documented audit-level value is 8 at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe\AuditLevel. Deploy it to a pilot through a managed policy, reboot as required, then review Microsoft-Windows-CodeIntegrity/Operational. Events 3065 and 3066 identify audit findings for shared sections and signing-level requirements. Check the exact event text, binary path, publisher, file version, and owning product instead of treating every entry as a generic compatibility defect.

$auditPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe'

Get-ItemProperty -Path $auditPath -Name AuditLevel -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id = 3065, 3066
    StartTime = (Get-Date).AddDays(-14)
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, ProviderName, Message

This command is read-only and queries the local event log. Centralized collection, event retention, and the correct time range must be designed for a fleet rollout. Microsoft notes audit events are not generated when Smart App Control is enabled and when a kernel debugger is attached and enabled; absence of an event is therefore not proof that every plug-in is compatible. Do not disable another security feature broadly just to make an audit appear clean. Instead verify the documented audit conditions and use a representative test ring.

Classify findings into supported updates, vendor fixes, obsolete software removal, or approved exceptions. Confirm the signed version of each plug-in is the version installed in the pilot. Microsoft recommends identifying all LSA plug-ins and drivers, ensuring they meet signing requirements, and verifying they load and function as expected before enforcement. Test password change and reset workflows, smart-card and certificate logon, remote access, service startup, and any custom authentication provider with the exact policy intended for production.

Choose a deployment mode and understand the lock

LSA protection can be configured through supported Group Policy or device-management policy. On supported Windows 11 releases, the RunAsPPL setting can enable protection with a UEFI variable (1) or without a UEFI variable (2, enforced only on Windows 11 version 22H2 and later according to the current Microsoft instructions). The Group Policy UI exposes the UEFI-lock choice on the relevant Windows 11 releases. Windows Server and older client releases have their own supported procedures; do not assume the Windows 11 value 2 has the same effect on every server build.

With UEFI lock, Windows stores the setting in firmware. A subsequent registry or policy change does not remove that variable. A planned opt-out requires Microsoft’s LSA Protected Process Opt-out procedure and a restart; turning off Secure Boot should not be the routine escape hatch. Before selecting UEFI lock, prove that the organization has console or out-of-band access, knows the applicable opt-out process, and has tested recovery on the same hardware and OS family.

Use a staged deployment: a lab with all integrations, a small IT pilot, representative business-user rings, then broader device groups. Keep audit and enforcement assignments separate, scope the policy narrowly, wait for policy and firmware state to converge, and document reboot timing. Coordinate with help desk, identity, endpoint, and security teams. Avoid combining the rollout with unrelated identity stack changes, because a failure then becomes difficult to attribute.

Verify protected startup and application behavior

After restart, inspect the System log for the documented WinInit event 12 stating that LSASS.exe started as a protected process with level 4. Pair that startup evidence with end-to-end authentication tests and the Code Integrity operational log. Event absence or a green policy report is not enough: confirm the application can still load required components and that the user’s actual login path works. Verify on a non-domain emergency account only through a controlled, preapproved test plan.

The following query checks the documented startup event and recent Code Integrity failures. Run it on each pilot endpoint or collect equivalent telemetry centrally.

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-Wininit'
    Id = 12
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id = 3033, 3063
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

Events 3033 and 3063 can record components blocked after enforcement for Microsoft signing-level or shared-section requirements. Correlate the image path and signature with the audit finding; identify whether a legitimate product was blocked or an untrusted component was prevented from loading. Do not suppress the alert or add a broad signer exception before the product owner and security team review the binary and business need.

Troubleshoot a failed logon or provider after enforcement

Determine whether the failure affects all logons or only a provider, method, user group, or machine build. Preserve event logs, policy result, RunAsPPL state, UEFI-lock decision, restart timeline, and the exact plug-in binary details. Test with a known-good authentication path in an isolated pilot, not by disabling LSA protection across the fleet. If an integration is blocked, update or remove the incompatible component using its supported installer and repeat audit tests before expanding enforcement.

When UEFI lock is set, writing RunAsPPL=0 or unconfiguring policy may not disable the protection. Use the documented opt-out procedure, approved physical/remote-console access, and a maintenance window. Do not switch off Secure Boot merely to clear the setting; Microsoft cautions that this resets Secure Boot and UEFI-related configuration and should be considered only after other methods fail. Keep incident management aware that a device may require reboot and firmware access for recovery.

Distinguish LSASS PPL from Credential Guard and other controls

LSA protection does not move all credential secrets out of LSASS. Credential Guard isolates supported credentials using VBS and the isolated LSA process. Application control limits which code can run; endpoint protection detects and responds to malicious behavior; LSA protection hardens a process boundary. Use a layered design and assess each control’s prerequisites and compatibility. A protected LSASS process does not mean a stolen credential can never be reused, and it does not protect secrets exposed through unrelated channels.

Avoid claiming the feature blocks all debugging or kernel compromise scenarios. Microsoft’s guidance notes that debugging a protected LSASS process is not supported, and that PPL’s guarantees are bounded by its trust model and platform state. Use security baselines and vendor compatibility matrices to choose the control set, and document any required diagnostic access before enabling enforcement.

Acceptance and lifecycle management

Accept the deployment only when pilot systems show expected audit findings resolved or formally accepted, LSASS starts protected, critical authentication paths pass, Code Integrity logs contain no unexplained blocks, UEFI-lock recovery has been rehearsed if selected, and the policy owner can identify the applied configuration. Retain the approved ring list, product compatibility evidence, event samples, change approval, support process, and rollback steps.

Reassess after Windows feature updates, credential-provider upgrades, endpoint-security changes, certificate middleware updates, new smart-card drivers, or policy redesign. Monitor protected-startup state and Code Integrity events, but treat telemetry gaps as an investigation item. LSA protection is strongest operationally when its compatibility assumptions and recovery mechanics are maintained alongside the software that integrates with sign-in.

Related:

Sources: