How do you know if LSA Protection is actually enabled on a Windows machine?

How to verify LSA Protection on Windows

The practical check is simple: inspect the RunAsPPL registry value on the target machine. A value of 1 means LSA Protection is enabled. A value of 0, or the absence of the property, means the protection is not active as intended and the machine should be remediated before you rely on it for security assurance.

For Windows hardening, that registry state is the most direct confirmation because it reflects whether the operating system is configured to run Local Security Authority as a protected process. You should treat the result as an evidence check, not an assumption based on policy intent or baseline documentation.

When you validate the setting, make sure you are checking the correct host and the current live state. A machine can be documented as hardened while the local setting has drifted, was never applied, or was reverted by image changes, troubleshooting, or an exception that was not closed out.

What the registry check tells you about real protection

RunAsPPL is a configuration signal for a security control that helps protect LSASS from tampering and credential theft. That makes the check useful both for baseline verification and for incident triage, because the presence of the setting does not just show intent, it shows whether the host is actually configured in the hardened state you expect.

The result is most valuable when you interpret it alongside the broader Windows protection stack. LSA Protection is usually part of a layered hardening posture that may also include Credential Guard, attack surface reduction rules, tamper protection, and exploit mitigations. If you only confirm one control in isolation, you can still miss adjacent weaknesses that leave credential material exposed.

On hardened Windows endpoints and servers, the setting is often paired with other Windows endpoint hardening measures. That matters because the control is not a theoretical checkbox, it is a runtime protection state that should survive reboots, imaging, and routine administration.

Why this check matters when credential theft is the threat

LSA Protection is relevant because attackers commonly target Windows authentication material through LSASS memory access, process injection, and related credential access techniques. If the control is not enabled, an attacker who gains local execution has a much easier path to dumping secrets, tokens, or reusable credentials from memory.

That is why this check belongs in both hardening verification and post-compromise assessment. If the host was expected to have LSA Protection but the registry says otherwise, you should assume the machine had a weaker defensive posture than planned and investigate whether credential access or tampering was possible during that window.

Useful context on that attack class is covered in the MITRE ATT&CK T1556 Modify Authentication Process Guide, ATT&CK Credential Access Tactic Guide, and Credential Dumping Guide, which all place LSA Protection in the context of how attackers abuse Windows authentication subsystems.

What to check if the setting is missing or false

If RunAsPPL is 0 or absent, verify whether the issue is a local misconfiguration, a policy drift problem, or an unsupported host state. The operational question is not just whether the registry value exists, but whether the machine is supposed to be enforcing the control and has any exception, remediation gap, or compatibility issue that prevented it.

If patching or reconfiguration is delayed, treat the host as exposed to credential theft until the control is restored. That usually means tightening administrative access, reducing interactive logon exposure, and checking whether the endpoint belongs to a higher-value tier where secrets or privileged sessions are especially sensitive.

For environments where Windows hardening is managed centrally, the most practical next step is to compare the live setting against your baseline and then review whether other protections in the same hardening set are also missing. The Windows Server Hardening Guide and Windows Internals for Defenders Guide are useful for understanding where LSA Protection fits in the broader server and endpoint trust model.

Risk and Threat Considerations

If LSA Protection is disabled on a machine that handles administrative logons, interactive support sessions, or sensitive service activity, the main risk is credential exposure from memory inspection or tampering. That weakens the host’s resistance to post-exploitation access and can turn a single foothold into broader lateral movement.

Failure mechanism: An attacker or local adversary obtains code execution, then targets LSASS or related authentication components to extract material that would have been harder to access if the process were protected.

Impact: Reusable credentials, session material, or authentication secrets may be exposed, which can expand the blast radius from one endpoint to adjacent systems, privileged accounts, or higher trust tiers.

Practitioner Guidance

What to verify: Confirm the live RunAsPPL state on the host, then verify that the result matches the intended baseline for that machine class. If the value is missing or 0, treat that as a control failure until you have a documented reason for the exception.

What to prioritise: Prioritise hosts that hold privileged access, support administrative workflows, or are frequently used for interactive troubleshooting. On those systems, a disabled setting is more than a hygiene issue because it increases the chance that credential material can be harvested during a compromise.

Practitioner takeaway: The important judgement is not merely whether the registry value exists, but whether the machine is demonstrably in the protected state you expect before you trust it for privileged operations.

Related resources from NHI Mgmt Group

• Why should LSA protection (RunAsPPL) be enabled on Windows and how do you detect tampering?
• How do you know if machine identity automation is actually working?
• How do you know if agent access is actually governed instead of merely enabled?
• How do you know if bot protection is actually working?