How to Verify Local Security Authority Protection in Windows 11

The LSASS (Local Security Authority Subsystem Service) process is a core Windows component responsible for user authentication, enforcing security policies, and generating access tokens that control access to system resources. Because LSASS processes and stores sensitive credential material (e.g., password hashes, Kerberos tickets), it is a high-value target for attackers. If compromised, attackers can extract credentials from memory, escalate privileges, and move laterally across systems.

Local Security Authority (LSA) protection is a critical Windows 11 security control designed to reduce this risk. It protects the LSASS process by running it as a protected process and restricting access to trusted, signed components only. This helps prevent unauthorized memory access, code injection, and common credential-theft techniques. However, verifying that LSA protection is enabled requires checking several system indicators rather than a single user-interface toggle.

Keep reading to discover a practical workflow for administrators and managed service providers (MSPs) to verify LSA protection in Windows 11.

How to check if Local Security Authority protection is on

It’s important to validate LSA protection from multiple angles, especially in managed environments. The following steps will walk you through UI checks, registry values, event log evidence, policy context, and supporting security features to ensure LSASS is running as a protected process.

📌 Prerequisites:

• Local administrator rights on the endpoint
• Access to Windows Security, Event Viewer, and an elevated shell (e.g., PowerShell, Command Prompt)
• Formal change record for any remediation

Step 1: Check Windows Security

First, verify the status in Windows Security to confirm how the system currently reports LSA protection. In this step, you’ll also see if there are any warnings or recommendations that need your immediate attention.

1. Navigate to Settings > Privacy & security > Windows Security > Device security > Core isolation details.
2. Find the Local Security Authority protection toggle and confirm that it’s On.
3. Review any recommendations or warnings shown to the user.
4. Capture a screenshot if evidence is required for auditing or ticketing.

Step 2: Confirm via registry

Next, check the registry to know if LSA protection is also configured at the system level. This will let you distinguish between UI display issues and actual protection intent.

1. Open the Registry Editor with administrative rights.
2. Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Review RunAsPPL and confirm it is set to 1 or 2, enabling LSA protection (with or without UEFI Lock), so LSASS runs as a protected process after reboot.
4. Review RunAsPPLBoot and confirm it is set to 1 or 2, enforcing LSA protection earlier in the boot process, with 2 providing stronger enforcement by locking the setting against tampering on supported systems.
5. Use these values alongside event logs in the next step to confirm runtime behavior.

Step 3: Validate with event logs

Event logs can also provide authoritative confirmation of whether LSASS actually started as a protected process and reveal any plug-ins that failed to load under protection requirements.

1. Open Event Viewer.
2. Browse to Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.
3. Look for Code Integrity events (e.g., Event ID 3065 or 3089) that indicate LSASS started as a protected process and flag any LSA plug-ins that were blocked or failed to load.
4. Follow Microsoft’s audit guidance for further analysis.

Step 4: Verify with PowerShell and policy context

Additionally, PowerShell and policy validation can help confirm that LSA protection is enabled and enforced by management tools, so the setting survives OS updates and cannot be changed by end users.

1. Use an elevated PowerShell session to confirm LSA-related registry values and verify the configured state using this command:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL","RunAsPPLBoot" -ErrorAction SilentlyContinue

2. Check that Group Policy or MDM enforces LSA protection so it persists across updates and overrides local UI settings.

Step 5: Cross-check LSASS and Credential Guard posture

You should also validate how LSA protection interacts with Credential Guard, as both features rely on protected LSASS behavior and virtualization-based security. However, they are separate hardening features, so confirming their alignment prevents misconfigurations that could weaken isolation or cause unexpected warnings.

1. Confirm Credential Guard is enabled.
2. Confirm LSASS is running as a protected process by validating RunAsPPL registry values and protected startup events identified in earlier steps.
3. Check Code Integrity and LSA audit logs for errors indicating blocked components or conflicts between Credential Guard and LSA protection
4. Record any mismatches between expected and actual posture so they can be remediated before further validation.

Step 6: Record evidence for audit

To ensure you can review findings later and make troubleshooting much easier, always collect clear and verifiable evidence.

1. Capture screenshots of the Windows Security LSA protection state.
2. Export the relevant registry keys from HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Record the event IDs that confirm protected LSASS startup or identify plug-in issues.
4. Note the device name, Windows build, and applicable policy scope, then store the evidence in your RMM or ticketing system.

Step 7: Remediate status inconsistencies

Finally, make sure to take action when LSA protection signals don’t match across the UI, registry, and event logs. Address these inconsistencies to ensure the device is actually protected and that the reported posture is accurate.

• Re-apply the relevant policy if the UI shows LSA protection is off, but registry and policy values indicate it’s on.
• Reboot the device, and repeat if necessary, until Windows Security, registry values, and Code Integrity events consistently show LSASS starting as a protected process.
• Investigate warning states or unsigned LSA package messages shown in Windows Security.
• Use your existing fix or remediation article to resolve non-compliant plug-ins or drivers.
• Revalidate the configuration after remediation to confirm the state is consistent across all sources.

Best practices summary

Below are some best practices to help ensure that LSA protection is consistently validated and reliably enforced. These should reduce ambiguity and speed up investigations.

What’s LSA protection, and why verify it?

LSA protection is a Windows security feature that runs the LSASS as a protected process, preventing untrusted code from injecting into it and blocking attempts to steal credentials stored in memory. It hardens one of the most sensitive components of the operating system and is foundational to modern credential-security controls, such as Credential Guard.

Verification is crucial to:

• Ensure LSASS is not just configured, but fully running as a protected process.
• Detect mismatches between UI, registry, and policy enforcement.
• Ensure protection persists after upgrades or policy changes.
• Identify unprotected or incompatible LSA plug-ins that weaken security.
• Provide evidence for audits, compliance checks, and security investigations.

Troubleshooting

You may encounter some common issues while verifying LSA protection. Consider the following troubleshooting steps to ensure the device accurately reports its security posture.

LSA shows off after upgrade

Confirm that the enterprise policy is still applied and that RunAsPPL values remain configured. Some Windows upgrades reset security settings, so a reboot may be required. If the setting does not persist, reapply the policy and verify again.

UI toggle is missing or greyed out

This usually means the setting is governed by enterprise policy rather than local configuration. Check policy precedence and confirm the registry reflects the enforced state. Unsupported or legacy configurations can also render the toggle unavailable.

Warnings about plug-ins not protected

Review Microsoft’s audit guidance to identify which plug-ins or drivers failed to load as protected. Update, remove, or replace the non-compliant components to restore proper LSA behavior. You should also recheck event logs afterward to ensure no additional plug-ins are affected.

Analysts confuse LSA and LSASS

Clarify that LSA is the subsystem responsible for authentication policy, while LSASS is the process that implements it. Adding a brief internal explainer should help reduce recurring confusion.

Validating LSA protection for long-term security

Verifying LSA protection should be a structured approach to ensure that LSASS is truly running as a protected process. By following the discussed workflow, from validating registry values to addressing inconsistencies, MSPs and administrators can maintain stability in the long term.

Related topics:

• How to Enable Credential Guard and LSA Protection Across Client Devices
• How to Enable or Disable Local Security Authority Protection in Windows 11
• How to Fix “LSA Package is Not Signed as Expected” Warning in Windows 11
• How to Reset All Local Security Policy Settings to Default in Windows