Credential Guard and LSA Protection: Stopping Credential Theft at the Endpoint
Enable Credential Guard with UEFI lock, harden LSASS with PPL, and catch compatibility fallout in audit mode before your users notice anything.
C
CloudEngineerHub Team
Published: September 24, 2026· Last Updated: September 28, 2026·9 min read
Credential Guard and LSA Protection: Stopping Credential Theft at the Endpoint
Every pass-the-hash engagement since 2012 starts the same way: malware or an operator with local admin touches LSASS and walks out with every domain credential that machine has seen. Credential Guard and LSA Protected Process Light (PPL) are the two Windows controls that close that door — one by isolating secrets inside virtualization-based security, one by preventing unsigned code from injecting into LSASS at all. Both are free with the OS, both are two settings in Intune, and both break things quietly when you deploy them without a compatibility pass. Here's the deployment that works.
Visual Walkthrough
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Each layer assumes the previous one failed — depth is the strategy.
Credential Guard — Isolation Stack. 1. VBS boots the hypervisor: Virtual Secure Mode isolates a protected memory region. — 2. LSASS isolated (LsaIso): Credentials live in the isolated LSA process, not LSASS. — 3. HVCI enforces code integrity: Kernel-mode code must be signed and virtualization-backed. — 4. Theft attempts fail silently: Mimikatz-class tools read nothing usable. — 5. LSA protection audits first: Audit LSA protection, fix incompatibles, then enforce. — 6. Fleet verified: Device Guard/Win11 defaults + policy confirm state.
Prerequisites
Hardware: 64-bit CPU with virtualization extensions and SLAT; UEFI firmware with Secure Boot; TPM 2.0. Hypervisor-protected Code Integrity (HVCI/Memory Integrity) benefits from IOMMU (VT-d/AMD-Vi) support.
Edition: Credential Guard runs on Windows 11/10 Enterprise and Education; since Windows 11 22H2 it is enabled by default on Enterprise editions that meet requirements — know your fleet's state before you "deploy" anything.
Intune: Endpoint Security Manager role; the controls live under Endpoint security > Account protection and the Settings catalog.
A pilot ring with the estate's weirdest software: credential providers, smartcard middleware, AV agents, backup tools — those are the components that touch LSA.
Licensing is OS-based; there's no Entra or Defender SKU gate for Credential Guard or LSA PPL themselves.
The attacks you're closing
LSASS holds what every domain user on the machine has left behind: NTLM hashes, Kerberos tickets, plaintext from custom auth flows. Memory-dumping tools (mimikatz and its many descendants) read it from kernel or user mode. Credential Guard moves the secret store into a VBS-protected process that normal code — including code running as SYSTEM — cannot read. LSA PPL independently prevents non-protected processes from loading into or injecting into LSASS. Together they convert "local admin = domain compromise" into something an attacker has to work much harder for.
They do not make the machine invulnerable: hardware attackers, kernel exploits with arbitrary read against VBS itself, and credential material outside LSASS remain. Defense in depth, not a force field.
VBS: the foundation
Credential Guard is a guest of Virtualization-Based Security: the hypervisor creates an isolated memory region where the secret-handling process runs. If VBS isn't actually running, Credential Guard is theater. Check the foundation before touching policy:
A healthy endpoint reports VirtualizationBasedSecurityStatus: 2 with SecurityServicesRunning containing both 1 and 2. Devices showing configured-but-not-running usually lack virtualization enabled in firmware, fail Secure Boot, or carry an incompatible driver blocking HVCI. Fix the fleet report before the policy deployment, not during the helpdesk wave.
HVCI alongside, not instead
Memory Integrity (HVCI) is a separate toggle in the same VBS family that validates kernel-mode code. It has its own compatibility exposure — old drivers are the usual casualty — so treat it as its own pilot with its own driver inventory. The enterprise pattern is one VBS baseline: HVCI and Credential Guard together, rolled with the same rigor.
Enabling Credential Guard with Intune
Intune exposes this under Endpoint security > Account protection, in a Credential Guard profile for Windows, with three enforcement states:
Enable with UEFI lock — the setting persists in UEFI and can't be casually undone by policy.
Enable without UEFI lock — reversible from management.
Disable — for the inevitable exclusion list.
On Windows 11 22H2+ Enterprise clean installs, Credential Guard is already on by default; your Intune policy's job there is standardization and drift control, not first enablement. Run the Account protection profile against all device groups and let the report tell you where the gaps are.
UEFI lock: the one-way door
Choose the lock deliberately. With UEFI lock, disabling Credential Guard requires physical presence at the machine — a documented recovery procedure, not a helpdesk call. That's exactly what you want on executives and developers, and exactly what you don't want if a critical vendor app turns out to be incompatible with no workaround: you'll be visiting desks, not pushing a profile. Standard guidance: lock for high-value user populations, no-lock during the pilot rings, revisit after the compatibility soak.
Field note: VDI and multi-session hosts are a design decision, not an afterthought. Some session-host estates disable Credential Guard because each logon's secrets multiply; others enable it precisely because sessions share the host. Make the call per platform and write it into the host build docs — discovering it via "the RDS farm is slow" at 2 a.m. is the expensive path.
LSA protection: PPL for the rest of the estate
LSA Protected Process Light predates Credential Guard and covers a different gap: it stops unsigned or unprotected code from running inside LSASS, which blocks injection-style dumping even where secrets aren't virtualized. Windows 11 22H2+ enables it by default on new installs, but fleets upgrade in place and inherit nothing.
The classic control is the registry value RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa — 1 enforces, 2 enforces in audit mode, logging what would be blocked:
Windows 11 24H2 adds a dedicated MDM policy (LocalSecurityAuthority/ConfigureLsaProtectedProcess) that makes LSA protection a first-class management setting — including an audit mode — so you can move off hand-rolled registry payloads in your Settings catalog profiles. Use audit mode everywhere for two to four weeks; the System log tells you what your estate would lose.
Reading the events before users feel them
LSA writes the compatibility story into the System log, source LsaSrv:
Event 3065 — audit mode: a process didn't meet security requirements and would not have been allowed to run with LSA.
Event 3033 — enforcement: the process was actually blocked.
Query them fleet-wide through your SIEM or via Intune-collected diagnostic logs; each 3065 names the offending binary. Most hits are legacy security agents, credential middleware, or monitoring tools that read LSASS — vendor updates or targeted exclusions resolve them, and the ones without fixes are your exclusion list with a business case attached.
Visual Walkthrough
Every security control on this site maps to one of these five layers.
Layered StackDefense in Depth — Five Aligned Layers6/6
Client-side NTLM single sign-on stops working; Negotiate falls back to prompts
Users of legacy intranet apps and old file servers
Cached domain credentials
Domain credentials are no longer cached in LSASS for offline-style access
Laptop users on flaky VPN who relied on silent NTLM
Kerberos DES / weak crypto
Removed for credential operations
Applications configured for ancient crypto
Unconstrained delegation from clients
Not honored
Legacy three-tier apps doing double-hop
Third-party credential providers
May fail if unprotected
Password-manager and smartcard middleware users
The audit modes give you the real list — 3065 events for LSA, plus sign-in log and app telemetry for the NTLM SSO symptoms. Fix order: vendor updates, then protocol modernization (Kerberos/Negotiate), and only then exclusions with an expiry date. LSA PPL's fixes are usually simpler: the blocked agent needs a signed, PPL-compatible build, which most security vendors shipped years ago.
Verification checklist
Before you call a ring done, verify on representative devices:
msinfo32 — System Summary shows Virtualization-based security: Running, with Credential Guard (and HVCI, if deployed) listed among the running services.
Win32_DeviceGuard — status 2, with SecurityServicesRunning including 2 (Credential Guard); script it per ring and keep the CSV.
LSA — RunAsPPL (or the new policy CSP state) reads as intended, and 3033/3065 volumes match expectations for the phase.
Negative tests — a known dump tool fails, and an NTLM SSO test app prompts rather than silently passing through. Proving the control works matters as much as proving nothing broke.
Field note: Collect the Win32_DeviceGuard output as part of device compliance reporting, not as a one-time audit. Devices drift — firmware updates, BIOS "optimizations," and reimaged machines are how Credential Guard quietly ends up off on the CFO's laptop eight months after your deployment.
Key takeaways
Credential Guard isolates LSASS secrets with VBS; LSA PPL stops code injection into LSASS — deploy both, pilot both.
Since Windows 11 22H2 Enterprise, Credential Guard (and LSA protection on new installs) is on by default: audit your estate's actual state first.
Verify VBS with Win32_DeviceGuard (status 2, Credential Guard running) and msinfo32 before declaring success.
Intune's Account protection profile offers UEFI-locked and unlocked enablement; lock high-value populations and think twice before locking pilot rings.
Run LSA in audit mode (RunAsPPL=2 or the 24H2 policy CSP audit state) and read LsaSrv events 3065/3033 to inventory what would break.
The compatibility casualties are predictable: NTLM SSO apps, cached-credential workflows, old security agents, third-party credential providers.
Exceptions get owners and expiry dates; the controls only matter if a compliance report proves they're still on eight months later.
Frequently asked questions
Does Credential Guard stop all credential theft?
No — it removes the easy, dominant path. Secrets held outside LSASS (browser-stored credentials, files on disk, tokens in user processes) and kernel-level attacks beyond VBS remain in scope. Pair it with phishing-resistant sign-in, ASR rules, and App Control; credential security is a layered system.
We found an app that breaks under Credential Guard. Now what?
Confirm the failure mode first (NTLM SSO versus credential provider versus LSASS access — the fixes differ), then escalate to the vendor for a compatible build. Interim exclusions exist but carry real risk: an exclusion list is a map of your weakest endpoints. Keep entries short, owned, and expiring.
Is LSA protection still needed if Credential Guard is on?
Yes. They protect different failure modes: Credential Guard secures the secrets, LSA PPL hardens the process — blocking unsigned injection and dumping tooling that operates on LSASS itself. Both are default-on in current Windows 11 installs for good reason, and fleets upgrading in place need to deploy both explicitly.
Comments
0No comments yet — be the first to share your thoughts.