How to Enable or Disable Local Security Authority Protection in Windows 11

Local Security Authority (LSA) protection in Windows 11 plays a central role in managing authentication, enforcing security policies, and storing protected credentials, all critical tasks in today’s threat landscape. To enhance the security posture of this subsystem, Microsoft provides LSA protection, which keeps users from tampering with the LSA and prevents severe attacks on the system.

If you’re an IT administrator, this guide will help you turn Local Security Authority (LSA) protection on or off using Windows Security, Registry Editor, PowerShell, and Group Policy to ensure security when managing devices and deploying configurations at scale.

What is Local Security Authority Protection?

Local Security Authority (LSA) is a critical Windows component that handles authentication, security policy, and credential storage. It is the computer’s gatekeeper, verifying credentials, managing password changes, and creating access tokens when users attempt to log on to the system. The LSA subsystem (LSASS) is the executable process that runs the LSA and implements its functionality.

LSA protection makes LSASS more secure. This security feature runs LSASS as a protected process (PPL), which prevents untrusted code (even with administrative rights) from injecting into it. This ensures that only trusted services and processes are loaded, and they can’t be easily interfered with by malicious or less-privileged processes that may open the system to credential theft and malware execution.

Methods for enabling or disabling Local Security Authority protection

Managing LSA protection is not a one-size-fits-all task. Choosing the correct method depends on your environment (personal vs. enterprise), scale of deployment, automation needs, and security and compliance requirements. (Check if you meet the prerequisites before you begin.)

Method 1: Enable or disable Local Security Authority protection via the Windows Security GUI

This is the simplest and most user-friendly method, as it shows visual feedback on LSA status without requiring scripting knowledge or advanced skills. It is best for home users and IT support staff who are doing one-off manual configuration on individual devices. However, this method is only executable on devices that support virtualization-based security (VBS) configurations.

1. Open Settings > Privacy & security > Windows Security > Device Security.
2. Under the Core isolation section, click Core isolation details.
3. Locate the Local Security Authority protection section and toggle the setting on or off.
4. Reboot your device to apply the changes.

Method 2: Enable or disable LSA protection via Registry Editor

This method is best for advanced users, IT admins, and technicians who want to manually tweak LSA behavior on groups of machines. It is recommended for use in automation, provisioning, and deployment scenarios.

⚠️Note: Incorrect registry edits can cause serious system issues, so consider backing up the registry before proceeding. Administrator rights are required to make changes in the registry.

1. Open the Registry Editor as Administrator. Press Windows key + R, type “regedit,” and press Ctrl + Shift + Enter.
2. On the left pane of the Registry Editor, follow this path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. On the right pane of the Lsa key:
   • Double-click RunAsPPL and change its value to 1 (enable LSA protection) or 0 (disable it).
   • You can also do the optional step of changing the value of RunAsPPLBoot to 1 to ensure LSA is protected at boot time.
     Note: If these DWORD values don’t exist, create them. Right-click on an empty area in the right pane of the LSA key, hover over New, select DWORD (32-bit) Value, and name it “RunAsPPL” or “RunAsPPLBoot.”
4. Restart the computer to apply the changes.

Method 3: Enable or disable LSA protection using PowerShell

Using PowerShell may be the best method for system administrators working on bulk device configuration via remote scripts or deployment tools. This supports repeatable, scalable, and auditable deployments and can be easily incorporated into provisioning scripts, Intune scripts, or SCCM.

Note: Requires administrator privileges

To enable LSA protection:

1. Open an elevated PowerShell. Press Windows key + R, type “powershell,” and press Ctrl + Shift + Enter.
2. Copy and paste this command before hitting Enter:
   Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Lsa” -Name “RunAsPPL” -Value 1 -Type DWord
   Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Lsa” -Name “RunAsPPLBoot” -Value 1 -Type DWord
3. Reboot your device to apply the changes.

To disable LSA protection:

1. Open an elevated PowerShell. Press Windows key + R, type “powershell,” and press Ctrl + Shift + Enter.
2. Copy and paste this command before hitting Enter:
   Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Lsa” -Name “RunAsPPL” -Value 0 -Type DWord
3. Reboot your device to apply the changes.

Method 4: Configure via Group Policy or enterprise management tools

This method is designed for enterprise environments where managing hundreds or thousands of devices requires centralized control, consistency, and auditability. Note that there are no widely available native GPO templates for LSA protection in Windows 11 (as of version 22H2+), but you can still configure it with:

• Group Policy Preferences (for registry key deployment)
• Intune (using OMA-URI or PowerShell scripts)

Regardless of the delivery mechanism, you will deploy the RunAsPPL and RunAsPPLBoot keys under HKLM\SYSTEM\CurrentControlSet\Control\Lsa for all users.

Prerequisites before proceeding

Certain system-level and security prerequisites must be met before you start configuring LSA protection to ensure that features work correctly and reliably.

• Windows 11 system: LSA is fully supported, starting with Windows 8.1, but is more tightly integrated in and recommended for Windows 11.
• Administrative privileges: You must run PowerShell or Registry Editor as Administrator. GUI changes will also trigger UAC (User Account Control).
• Virtualization-based security (VBS): VBS enables the isolation of secure processes, including LSASS, using hardware virtualization. LSA protection is designed to work within this model, so protection may silently fail to activate if VBS is not supported.
• UEFI Secure Boot: Enabling Secure Boot is not mandatory, but it is strongly recommended to make LSA protection more effective.

Why manage Local Security Authority protection?

Managing LSA protection is crucial in maintaining security, so the decision to enable or disable it will depend on your Windows environment and situational needs.

Why enable LSA protection

LSA protection is highly recommended in most modern Windows environments due to its many significant security benefits, such as:

• Preventing credential dumping and process injection
• Supporting Secure Boot, VBS, and Credential Guard
• Complying with Windows 11 security baselines
• Enhancing Zero Trust architecture

Why disable LSA protection

If Local Security Authority Protection is off, your system becomes more vulnerable to security breaches. However, specific scenarios may justify disabling it, at least temporarily:

• When there are compatibility issues with legacy software or drivers
• While troubleshooting system instability or login failures
• When LSA plugins or credential providers are incorrectly signed, missing metadata, or misconfigured for protected process compatibility
• While testing in a lab or non-production environment

Other considerations when managing Local Security Authority protection

Implementing LSA protection is not as simple as flipping a switch. You must consider some technical and operational points to ensure smooth deployment.

• Windows Security warnings: You might see the message “LSA protection is on but not configured correctly,” which means your system is still prone to security threats. You must verify that all components (including third-party LSA plugins) are signed. You can use Event Viewer to investigate, audit LSA extensions or credential providers, or update/replace third-party software that fails the signing requirement.
• Event logs: LSA protection events are logged in Event Viewer, which can help validate proper configuration and diagnose issues. To confirm LSA protection is operational and there are no misconfigurations or unsigned modules, check Event Viewer > Windows Logs > System for the following Event IDs for LSA-related activity:
  • 1. 3065: Indicates LSA started as a protected process
    2. 3089: Warns that a plug-in was blocked due to a lack of a valid signature
• Compatibility: Some older applications, such as credential providers, smart card drivers, or antivirus plugins, may be incompatible with LSA protection, so they may fail or crash silently. It is important to conduct compatibility testing in a staging environment before deployment.
• Security baselines: Microsoft’s Windows 11 security baselines recommend enabling LSA protection on all enterprise-managed endpoints, devices with privileged user access, and systems using passwordless, biometric, or SSO authentication.

Building a safer Windows environment with Local Security Authority protection

Enabling LSA protection in Windows 11 is critical for hardening system authentication, preventing credential theft, and aligning with modern security best practices. However, it’s important to recognize that LSA protection may need to be temporarily disabled in specific cases, such as during compatibility testing, when dealing with legacy drivers, or while troubleshooting authentication issues.

With multiple deployment methods, from GUI-based configuration to scalable enterprise tools like Group Policy and Intune, IT administrators can balance security with operational stability and make LSA protection a reliable part of their system hardening strategy.