Credential Guard LSA protection needs checking and enforcing in Intune

In a lot of Windows 11 22H2+ Enterprise environments I work in, Credential Guard has become the default without anyone really noticing. It simply runs on modern hardware with little admin effort. LSA protection (Local Security Authority protection, RunAsPPL) is another story. Out-of-the-box security won't cover it, so if you want Credential Guard LSA protection that actually holds, you need to check it, enforce it and be prepared for compatibility issues. I've seen plenty of environments where the gap between "we assumed it was secure" and "it is actually protected" came down to how LSA protection was handled after upgrades or during onboarding.

Credential Guard is usually active while LSA protection often is not

On most recent enterprise devices, Credential Guard turns on automatically if the hardware is VBS-capable and Secure Boot is enabled. You can confirm this quickly in msinfo32 under "Virtualization-based security". LSA protection is a different case. It runs LSASS as a protected process (RunAsPPL) and blocks credential dumping tools like mimikatz, but it isn't consistently enabled, particularly after upgrades or when settings have drifted. I see a lot of variation from one fleet to the next. If you want more detail, Credential Guard events appear in the Event Log under Applications and Services Logs → Microsoft → Windows → DeviceGuard → Operational. For LSA protection, look for security events 3065/3066.

The diagram below shows how Credential Guard and LSA protection work together to protect credentials, including when old plugins are still around:

flowchart TD
    Userlogin["User signs in"] --> LSASS["LSASS process"]
    LSASS --> CredentialGuard["Credential Guard (VBS)"]
    LSASS --> LSAProtection["LSA protection (RunAsPPL)"]
    LSASS -.-> OldPlugin["Old LSA plugin"]
    LSAProtection -.-> PluginBlock["Plugin blocked"]
    CredentialGuard --> Attacker["Attacker (dumping)"]
    LSAProtection --> Attacker
    Attacker -->|"Attack blocked"| Stop["Protection active"]

Figure: Interaction between Credential Guard, LSA protection and plugins

Intune can enforce LSA protection, but audit mode should come first

If you run Intune, enforcing LSA protection is simple on paper. You configure it in Endpoint security → Account protection or in the Settings catalog (search for the Device Guard and Local Security Authority settings). The setting that matters is "Configure LSASS to run as a protected process", and current policies now include an audit mode option. I strongly recommend starting with audit mode, above all in mixed fleets or where older clients are still in use. Compatibility problems with old VPN clients, legacy Wi-Fi (MSCHAPv2) or unsigned LSA plugins then show up in the event log, and production keeps running.

Field tip: Keep a dynamic Azure AD group of devices that don't have LSA protection enabled yet and use it to track the rollout. Phased deployment and troubleshooting get much easier that way.

The problems I run into most often come from older third-party smartcard, VPN or Wi-Fi plugins. Many of them are unsigned, LSA protection blocks them, and users end up with failed logins or broken connections. Check the official Microsoft documentation for Credential Guard and for LSA protection to see the compatibility notes and mitigation options.

Reporting tools show the status across the whole fleet

Manual checks in msinfo32 or the Event Log are fine for a single machine, but at scale you need reporting. For Intune-managed devices, device security reports let you report on Credential Guard and LSA protection status. Microsoft Defender for Endpoint gives a good overview as well, since the Device inventory → Device security configuration blade lists which endpoints have VBS and LSA protection active. On a single device you can run this PowerShell query with local admin rights:

Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning

A value of "1" stands for Credential Guard and "2" for HVCI. For LSA protection, look at the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa and the value RunAsPPL (1 = enabled).

Not every device is ready for LSA protection

Some organizations get caught out when they turn on LSA protection and old VPN clients stop working or Wi-Fi logon fails. The cause is nearly always legacy LSA plugins or outdated drivers. In that case, leave audit mode on until you have a clear list of the affected devices. Specialized security or management tools that rely on custom LSA extensions can cause trouble too, so I always work closely with the endpoint and network teams before enforcing it for everyone.

If you have no other option, limit enforcement to device groups you know are compatible. Dynamic groups and compliance policies in Intune keep that manageable. And if passkeys are on your roadmap, be aware that the new requirements for device and authentication security are not trivial. I covered them in my recent post on passkey profiles in Entra ID.

LSA protection is essential, but the rollout needs care

LSA protection isn't optional anymore. Every modern Windows device should have it enforced alongside Credential Guard. That said, technical debt and legacy software still get in the way in real environments. If you go about it carefully, start in audit mode, watch the results closely and make compatibility issues visible to management, most environments can get there step by step. Credential theft attacks are still common, so the effort pays off.