LSA Protection, RunAsPPL and Credential Guard: Three Defences for One Target, and the Driver That Stops Them All

Every credential on a Windows device passes through one process. Its name is lsass.exe, the Local Security Authority Subsystem Service. It validates your sign-in, holds your Kerberos tickets, and answers when an application asks who you are. That makes it the single highest-value target on the machine. Windows offers three overlapping ways to defend it, and almost every engineer I speak to has enabled one while believing they enabled another.

This post separates them. It explains what a protected process actually is, how that differs from virtualisation-based credential isolation, and why a single third-party smartcard or anti-virus driver can silently stop either one from loading. Most importantly, it shows you how to prove from a device which protections are genuinely running, rather than merely written into the registry.

The problem: three defences, one target, and a config that lies

Here is the ticket, roughly as it always arrives. A security review asks for LSA protection. An engineer opens Intune, searches the Settings Catalog for anything containing the word "guard", finds Credential Guard, sets it to Enabled, and closes the ticket. Six months later an auditor asks for evidence that LSASS runs as a protected process, and there is none, because nobody ever configured that.

The reverse failure is quieter and worse. An engineer does the right thing. They set RunAsPPL to 1, reboot, and move on. The registry value is there. The device reports compliant. And LSASS is running completely unprotected, because a smartcard mini-driver on that hardware model is not signed for LSA, so the loader declined the whole request at boot.

Three separate mechanisms sit on top of lsass.exe. They are frequently conflated, so here is what each one actually stops.

Notice the third row. Microsoft is explicit that if you have enabled LSA protection, that attack surface reduction rule "isn't required" and "doesn't provide extra protection", because the two work similarly. Defender for Endpoint even reclassifies it as not applicable. The rule exists for the organisations that cannot enable the other two, and Microsoft names the reason: "compatibility issues with custom smartcard drivers or other programs that load into the LSA."

Why it happens: a protected process is not a virtual machine

Let us build this up from nothing, because the difference between the two features only makes sense once you know what the LSA is.

What the LSA is, in plain English

The Local Security Authority, or LSA, is the part of Windows responsible for authentication. It checks passwords, issues access tokens, enforces the local security policy, and holds the derived credentials that let single sign-on work. It lives in a user-mode process called lsass.exe, started at boot by wininit.exe.

The LSA is deliberately extensible. Third parties plug into it. A smartcard vendor supplies a mini-driver. An enterprise password-policy product supplies a password filter. A single sign-on product supplies a Security Support Provider, or SSP, and an Authentication Package, or AP. Each of these is a DLL that LSASS loads into its own address space at startup.

That extensibility is exactly the problem. Anything loaded into LSASS runs with LSASS's access to credentials. And because those DLLs are registered by name in the registry, the list is short and readable.

What LSA protection does

LSA protection, configured through a registry value named RunAsPPL, marks lsass.exe as a protected process. Two things follow.

First, non-protected processes can no longer read LSASS memory or inject code into it. That is the part that stops credential-dumping tools cold.

Second, and this is where deployments break, every plug-in loaded into the LSA must now be digitally signed with a Microsoft signature. Microsoft is precise about what that means. LSA plug-ins that are drivers, such as smartcard drivers, need Windows Hardware Quality Labs (WHQL) certification. Plug-ins with no WHQL path must be signed through the file signing service for LSA. And even a correctly Microsoft-signed plug-in can still fail to load if it does not conform to Microsoft's Security Development Lifecycle process guidance, or if it uses shared sections.

A valid Authenticode signature from the vendor is not enough. This catches people constantly. The DLL is signed, the certificate chains, Windows Explorer shows a clean signature tab, and LSA still refuses it.

The load chain, in order

Here is what happens on every boot, step by step.

1. wininit.exe starts and creates the LSASS process.
2. If LSA protection applies, LSASS is created at protection level 4. wininit.exe writes event 12 to the System log recording that fact.
3. LSASS loads lsasrv.dll, the LSA server itself.
4. lsasrv.dll reads the package lists under the Lsa registry key and loads each named DLL.
5. For each DLL, code integrity, implemented in ci.dll, checks the signing level and the shared-section rules.
6. A DLL that fails is refused, and code integrity writes event 3033 or 3063 to the CodeIntegrity operational log.

Step 2 is the one that matters. Windows does not partially apply LSA protection. Either the process is created protected or it is not. If a critical component cannot survive that, the practical outcome on many devices is that the protection does not come up, and you are left with the registry value and nothing else.

What Credential Guard does instead

Credential Guard takes a completely different approach. Rather than hardening lsass.exe, it removes the secrets from it.

With Credential Guard running, LSASS talks over remote procedure calls to a separate process, the isolated LSA process, LSAIso.exe. Kerberos ticket-granting tickets, NTLM password hashes and Credential Manager domain credentials live in there. That process runs inside virtualisation-based security, isolated at runtime by the hypervisor using Virtual Secure Mode, underneath the secure kernel, securekernel.exe. Microsoft states that the isolated LSA process hosts no device drivers at all, only a small subset of operating system binaries, all signed with a certificate that virtualisation-based security trusts.

That is the crucial architectural difference, and it explains the compatibility story. Your smartcard driver cannot break Credential Guard by failing a signature check, because your smartcard driver is never invited into LSAIso.exe in the first place. Credential Guard breaks things a different way: by refusing to hand out credential material that insecure protocols need.

The default-on behaviour nobody briefed you on

Both features now arrive switched on, and the rules differ per feature and per install type. This is where the confusion in most estates originates.

For LSA protection, Microsoft documents automatic enablement on Windows 11 version 22H2 and later when three conditions are all true: the device is a new installation rather than an upgrade, the device is enterprise joined (Active Directory domain joined, Microsoft Entra joined, or hybrid joined), and the device is capable of hypervisor-protected code integrity. Automatic enablement does not set a UEFI variable.

Then there is the upgrade path, which is documented separately in the Windows 11 security book and is easy to miss. "LSA protection is enabled by default on all devices to help safeguard credentials. For new installations, it activates immediately. For upgrades, it becomes active after a five-day evaluation period followed by a system reboot." Microsoft adds that enterprise policy settings for LSA protection override the default upgrade behaviour.

For Credential Guard, default enablement starts in Windows 11 22H2 on devices meeting the licence and hardware requirements. It is Enterprise and Education only; Windows Pro is not entitled. The default enablement is without UEFI lock, so it can be turned off remotely. And critically: a device that had Credential Guard explicitly disabled before the upgrade stays disabled afterwards.

How to verify: every surface, in the order that answers the question

There are seven surfaces worth reading. Take them in this order, because each one narrows the question.

1. Registry: the whole feature area

Two parent keys carry almost everything. Here is the first.

The two rows marked undocumented deserve a word. Both exist on the Windows 11 Enterprise build 26200 device I used for this post. Neither name appears anywhere in Microsoft's documentation. An undocumented value can change meaning, or vanish, in any monthly update, so read them for interest and never for compliance.

The second parent key is the virtualisation-based security tree.

Two more paths complete the picture. Group Policy and the Intune Settings Catalog write LSA protection to HKLM\SOFTWARE\Policies\Microsoft\Windows\System, value name RunAsPPL, which I confirmed by reading LocalSecurityAuthority.admx in C:\Windows\PolicyDefinitions. Credential Guard policy lands in HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard.

2. Event Viewer: the events that decide it

Two channels matter. The first is where you learn whether the protections came up.

The second channel is where you learn which component is to blame.

3. System files and DLLs

Naming the binaries makes the flow concrete. All of these live in C:\Windows\System32 and all were verified present on the test device.

4. Services and scheduled tasks

There is no service and no scheduled task that drives either feature, and it is worth saying so plainly rather than sending you hunting. Both are boot-time decisions. There is nothing under \Microsoft\Windows\... in Task Scheduler to check, and nothing to restart.

What does matter is which services are hosted inside LSASS, because these are what you affect when the process changes. On the test device, querying Win32_Service for a path containing lsass.exe returned six: SamSs (Security Accounts Manager), Netlogon, KeyIso (CNG Key Isolation), VaultSvc (Credential Manager), EFS (Encrypting File System) and LocalKdc (Kerberos Local Key Distribution Center). Three were running.

5. Log files

Neither feature writes a plain-text log, and there is no equivalent of a CBS or setup log to grep. What exists is the backing store for the two event channels, which you can copy off a device for offline analysis.

6. PowerShell

Now the part you can copy. This first block reads the configured state from both registry surfaces. It writes nothing.

This second block reads the running state, which is the answer you actually came for. There is no supported way to read a running process's protection level from PowerShell, so the WinInit event is the evidence, exactly as Microsoft documents.

7. Defender and security policy

The Defender surface is the attack surface reduction rule named "Block credential stealing from the Windows local security authority subsystem", GUID 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2. It is a standard protection rule, depends on Microsoft Defender Antivirus, and in Intune it is configured through an Endpoint security > Attack surface reduction profile.

Microsoft's own notes on the rule are unusually candid, and they change how you should think about it. It blocks access to LSASS process memory, not the running of processes. It produces a large volume of audit events, "almost all of which are safe to ignore". And if you have LSA protection enabled, the rule is not required and adds nothing.

The fix: audit first, then enable, in both consoles

Order matters here more than in almost any other hardening task, because the failure mode is silent. Audit, remediate, then enable.

Step 1: confirm audit mode, then read the audit events

Audit mode logs what would fail without blocking anything. Microsoft documents it as on by default from Windows 11 22H2, so on a modern device you usually have nothing to do. Confirm it, because it is not where you would guess.

The value is AuditLevel, type REG_DWORD, data 00000008. Note carefully that this is not under the Lsa key, which is where most people look first and find nothing. It is an Image File Execution Options subkey named after the executable. Then read events 3065 and 3066 in the CodeIntegrity operational log and act on whatever they name.

Step 2: enable LSA protection with Intune

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration, then select Create and New policy.
3. For Platform choose Windows 10 and later. For Profile type choose Settings catalog. Select Create.
4. Give the policy a name, for example Win11 - LSA protection - pilot ring. Select Next.
5. On Configuration settings select Add settings.
6. In the settings picker, browse to the category Local Security Authority and select Configure Lsa Protected Process. Close the picker.
7. Set the value to Enabled without UEFI lock for a pilot. Choose Enabled with UEFI lock only once you are certain, and read the red callout above first.
8. Select Next, add scope tags if you use them, and select Next.
9. On Assignments, assign to a small pilot device group. Select Next.
10. Review and select Create. Restart the targeted devices, because neither feature takes effect until a reboot.

If your tenant does not surface the Settings Catalog entry, the custom OMA-URI still works. Create a Templates > Custom profile and add a row with OMA-URI ./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/ConfigureLsaProtectedProcess, data type Integer, and value 1 for UEFI lock or 2 without.

Step 3: enable LSA protection with Group Policy

1. Open the Group Policy Management Console with gpmc.msc, or the Local Group Policy Editor with gpedit.msc for a single machine.
2. Create or edit a Group Policy Object linked to the organisational unit holding your computer accounts, then right-click and choose Edit.
3. Expand Computer Configuration, then Administrative Templates, then System, then Local Security Authority.
4. Open Configures LSASS to run as a protected process and set it to Enabled.
5. Under Options, choose Enabled without UEFI Lock for a pilot, or Enabled with UEFI Lock for the locked variant.
6. Select OK, run gpupdate /force on a target, and restart it.

Step 4: enable Credential Guard, which is a different policy in a different place

1. Create a Settings catalog policy exactly as in step 2, steps 1 to 5.
2. In the settings picker, browse to the category Device Guard and select Credential Guard.
3. Choose Enabled with UEFI lock or Enabled without lock. Microsoft's guidance is direct: if you want to be able to turn Credential Guard off remotely, choose Enabled without lock.
4. Assign and create, then restart the devices.

The Group Policy equivalent is not in the Local Security Authority node. It is one level away, under Device Guard, and it is a single setting that carries Credential Guard as a dropdown inside it.

1. Expand Computer Configuration, Administrative Templates, System, Device Guard.
2. Open Turn On Virtualization Based Security and set it to Enabled.
3. Under the Credential Guard Configuration dropdown, choose Enabled with UEFI lock or Enabled without lock.
4. Select OK, then gpupdate /force and restart.

For completeness, the CSP route is two settings rather than one: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity set to 1, and ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags set to 1 or 2. Both are integers.

What has no equivalent, and why that matters

Two absences are worth stating explicitly rather than leaving you to search for them.

First, LSA protection has no Security Options entry. It is not under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, and it is not in the Intune LocalPoliciesSecurityOptions area either, despite that being a common assumption. It is an ADMX-backed administrative template policy in the LocalSecurityAuthority.admx file, under System, and the corresponding Settings Catalog category is Local Security Authority.

Second, before Windows 11 22H2 there was no policy at all. The only route was deploying the raw registry value, and Microsoft's own guidance for multiple machines was a Group Policy Preferences registry item under Computer Configuration > Preferences > Windows Settings > Registry. If you still manage Windows 10, that preference item is your mechanism, and the audit-level value is deployed the same way.

Proof it worked: a real run on a real device

Reading eight registry values and two event channels by hand, per device, does not scale. So the companion script for this post does it in one pass and prints the distinction that matters: configured versus running, for both features, plus any event naming a component blocked from loading into LSASS.

It is read-only. It changes no setting, service or registry value, needs no PowerShell module, and runs on both Windows PowerShell 5.1 and PowerShell 7. It refuses to run unelevated on purpose, because without elevation the CodeIntegrity log returns nothing, and nothing looks exactly like a clean result.

Grab it here: Get-LsaProtectionState.ps1.

Below is a genuine run on a Windows 11 Enterprise build 26200 device, trimmed for length, with identifiers replaced. This is real output, not an illustration.

Read the verdict block as four independent facts, not one. Two of them being green tells you nothing about the other two. That separation is the entire point of the exercise.

If your run comes back with LSA protection CONFIGURED ON and NOT RUNNING, section 6 of the output is where you go next, and you are looking for one thing only: an event whose subject process is lsass.exe. The image path in that message is the component to remove or replace. Then reboot and run it again.

References

Microsoft official documentation:

• Configure added LSA protection - the authoritative page for RunAsPPL, its documented values, audit mode via AuditLevel, events 3033, 3063, 3065 and 3066, WinInit event 12, the plug-in signing requirements and the automatic enablement criteria.
• Configure Credential Guard - the Group Policy path, the Settings Catalog entry, the DeviceGuard registry surface, and WinInit events 13 to 17.
• Credential Guard overview - default enablement rules, licence and hardware requirements, and application requirements.
• Credential Guard considerations and known issues - the single sign-on breakage, the blocked protocol list, and the vendor support notes.
• How Credential Guard works - LSAIso.exe, Virtual Secure Mode, the VSM master key, and the documented protection limits.
• LocalSecurityAuthority Policy CSP - ConfigureLsaProtectedProcess and AllowCustomSSPsAPs, with the ADMX mapping.
• Enable memory integrity - the complete Win32_DeviceGuard property value tables.
• Attack surface reduction rules reference - the LSASS credential stealing rule and Microsoft's note that it is not required when LSA protection is enabled.
• Windows 11 security book: advanced credential protection - the five-day evaluation period for upgrades.
• Registering SSP/AP DLLs and Installing and registering a password filter DLL - the Security Packages and Notification Packages registry values.
• Device security in the Windows Security app - the Core isolation user interface and the LSA protection toggle.

Community deep-dives, both fetched and verified on the topic:

One closing thought. LSA protection and Credential Guard are complementary, not alternatives, and Microsoft says so directly: systems that support Credential Guard or enable it by default can also enable and benefit from LSA protection. Deploy both. Just do not deploy one and report the other.