Stop Credential Theft: The Windows Setting Nobody Enables

February 20, 2026 • February 20, 2026 • Read: 22 min • Views: 1

Was this helpful?

Most Windows credential theft isn’t magic. It’s plumbing. Attackers don’t need Hollywood “hacks” when your endpoints quietly store reusable secrets in places that were designed for convenience, not for hostile networks.

The setting that changes the economics for attackers is Windows Defender Credential Guard. It’s not new. It’s not exotic. It’s just… rarely turned on consistently. And that’s why it keeps showing up in post-incident reports like a missing smoke detector: you only notice after the fire.

The setting: Credential Guard (and what it really does)

Credential Guard is Microsoft’s attempt to stop Windows from being a buffet of reusable secrets. Specifically, it uses Virtualization-Based Security (VBS) to isolate secrets so that even if an attacker reaches admin on the box, the “good stuff” is harder to extract and replay.

Without Credential Guard, the Local Security Authority Subsystem Service (LSASS) is the bouncer and the bar. It authenticates users and also keeps credential material in-process. If a threat actor can dump LSASS memory (or coerce it via signed drivers, debug privileges, or token games), they can often harvest:

NTLM hashes (Pass-the-Hash fuel)
Kerberos Ticket Granting Tickets (Pass-the-Ticket fuel)
Cached domain credentials (offline cracking fuel)
Sometimes even plaintext secrets, depending on configuration and legacy auth components

With Credential Guard, the sensitive bits are moved into a protected environment (isolated user mode) backed by the hypervisor. LSASS can still ask for authentication operations, but it doesn’t get to hold the crown jewels in a way that’s easy to scrape.

Is Credential Guard perfect? No. Nothing is. It’s a control that raises attacker cost and reduces blast radius. In production security, that’s the whole job.

What Credential Guard does not do

It does not fix weak passwords, over-permissioned accounts, or “Domain Admin everywhere.”
It does not stop phishing from capturing user credentials before they reach your machine.
It does not stop a logged-in attacker from doing damage as that user.
It does not make legacy authentication magically safe; it often breaks it (which is a feature, not a bug).

Why nobody enables it (and why that’s a bad excuse)

Credential Guard is ignored for three reasons: fear, inertia, and “compatibility.” Most orgs have at least one crusty line-of-business app, one vendor VPN client, or one “special” authentication plugin that was last updated when people still argued about whether Wi‑Fi would catch on.

So teams do what teams do under delivery pressure: they avoid changes that might cause tickets. They keep the endpoint credential surface area wide open because it’s “how it’s always worked.”

Meanwhile, attackers automate credential theft. They don’t need your helpdesk schedule. They run at machine speed.

Here’s the uncomfortable truth: compatibility is a solvable problem; credential theft at scale is a business-ending problem. Your goal is to find the small number of endpoints and workflows that truly can’t run with Credential Guard, isolate them, and stop pretending that the entire enterprise needs to be insecure for their sake.

Joke #1: If your security strategy relies on “nobody will ever get local admin,” I have a bridge to sell you—payment accepted in NTLM hashes.

What you’re actually stopping: LSASS, hashes, tickets, and replay

Credential Guard is aimed at a very specific and very common kill-chain segment: post-compromise credential replay and lateral movement. The pattern looks like this:

Initial access (phishing, browser exploit, stolen VPN creds, exposed RDP, malicious macro—pick your poison).
Local privilege escalation or token theft to get high integrity.
Dump credentials from LSASS (or coerce auth material) and reuse them.
Move laterally to file servers, RDP into desktops, hit AD, grab more creds, escalate to domain dominance.

Credential Guard makes step 3 materially harder by isolating secrets, limiting what LSASS exposes, and reducing the value of “dump and go” tooling.

It’s worth calling out the parts that keep showing up in incidents:

Pass-the-Hash (PtH)

NTLM hashes are reusable in too many places. If you can harvest a hash for a privileged account, you can often authenticate without ever knowing the password. Credential Guard reduces the availability of those hashes in LSASS.

Pass-the-Ticket (PtT)

Kerberos tickets can be replayed. If attackers can extract ticket material, they can impersonate users and services. Credential Guard reduces exposure of ticket-granting secrets.

WDigest and legacy credential providers

Windows has carried legacy authentication behaviors for compatibility. Some of those behaviors are basically “store secrets in a way that’s convenient for attackers.” You want them off.

RDP credential exposure

RDP isn’t evil. But letting high-privilege users RDP into low-trust endpoints is how you donate admin creds to the first malware sample that gets lucky. Credential Guard helps, but so do Remote Credential Guard and sane admin workstation design.

Facts and history that explain today’s mess

Security controls make more sense when you understand why the weak defaults exist. Here are some concrete points—historical context, not nostalgia:

LSASS has been a high-value target for decades because it’s where Windows authentication happens and where credential material accumulates during normal use.
“Pass-the-Hash” got mainstream attention in the late 2000s, and it stayed relevant because NTLM lingered in enterprises like an unpatched printer: always there, quietly critical.
WDigest was designed for compatibility with older authentication schemes; the problem is that compatibility sometimes means “easier plaintext handling.” Modern Windows versions tightened defaults, but upgrades and policy drift keep the risk alive.
Credential Guard arrived with Windows 10 Enterprise / Windows Server 2016 era capabilities, tied to VBS and hypervisor isolation—security built into the platform rather than bolted on.
Virtualization became the security boundary because the classic OS boundary failed under kernel drivers, admin rights, and memory scraping; the hypervisor is harder to tamper with than a user-mode process.
Attack tooling professionalized: what used to be a niche skill became push-button frameworks that extract credentials quickly and quietly.
“Protect LSASS” (RunAsPPL) predates widespread Credential Guard adoption; many orgs enabled PPL without finishing the job, leaving other credential material still accessible.
Microsoft’s modern guidance increasingly assumes “assume breach”, focusing on minimizing credential exposure rather than pretending endpoints never get compromised.

Fast diagnosis playbook

When you suspect credential theft exposure—or you’re prepping rollout and want to know what will break—don’t wander. Start with a tight loop: verify platform prerequisites, verify the control is actually running, then identify legacy dependencies.

1) Check first: Is Credential Guard actually on?

Look for VBS status and Credential Guard running state.
If it’s “configured” but not “running,” you have a platform/prereq issue (firmware, virtualization, policy, driver conflicts).

2) Check second: Are you still leaking credentials via legacy settings?

WDigest, NTLM usage, cached logons, and “convenient” delegation settings.
If you’re still allowing NTLM everywhere, Credential Guard helps but you’re leaving a side door open.

3) Check third: Are admins logging into the wrong places?

Privileged accounts on user workstations are an incident waiting for a calendar invite.
Fix workflows: admin workstations (PAWs/SAWs), Remote Credential Guard, and clear separation of roles.

4) Check fourth: Are you blocking the common dumping techniques?

LSASS PPL, Attack Surface Reduction (ASR) rules, driver control, and EDR tamper protection.
If you can’t stop a signed vulnerable driver from loading, your isolation story is weaker than it looks.

Practical tasks: 12+ checks with commands, outputs, decisions

These are “do it on a box” tasks. Each one includes a realistic command, what the output means, and what decision you make next. Run them in an elevated PowerShell session unless noted. The prompt in the blocks is fixed by design.

Task 1: Check whether Credential Guard is running (WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

What it means: The numeric array lists security services currently running under Device Guard/VBS. Commonly, 1 indicates Credential Guard and 2 indicates Hypervisor-protected Code Integrity (HVCI), though exact mappings can vary by build.

Decision: If you don’t see expected values, Credential Guard isn’t running. Move to prerequisites and policy verification (Tasks 2–4).

Task 2: Check whether VBS is enabled (WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, RequiredSecurityProperties, AvailableSecurityProperties | Format-List"
VirtualizationBasedSecurityStatus : 2
RequiredSecurityProperties       : {1}
AvailableSecurityProperties      : {0, 1, 2, 3}

What it means: VirtualizationBasedSecurityStatus typically: 0=off, 1=configured but not running, 2=running. Required/available properties hint at whether hardware/firmware supports the security model.

Decision: If status is 1, you likely need a reboot, firmware virtualization, or driver remediation. If 0, policy is not applied.

Task 3: Verify Hyper-V hypervisor is present (system info)

cr0x@server:~$ powershell -NoProfile -Command "systeminfo | Select-String -Pattern 'Hyper-V Requirements|A hypervisor has been detected|Virtualization' -Context 0,1"
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

What it means: Firmware virtualization and SLAT are required for many VBS scenarios. If “Virtualization Enabled In Firmware: No,” you’re dead in the water.

Decision: If virtualization is disabled, plan BIOS/UEFI change and maintenance window. If missing SLAT, that hardware won’t be a good citizen for VBS.

Task 4: Confirm Credential Guard policy in registry

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard' /v EnableVirtualizationBasedSecurity & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v LsaCfgFlags"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
    EnableVirtualizationBasedSecurity    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    LsaCfgFlags    REG_DWORD    0x1

What it means: These values commonly reflect VBS and Credential Guard configuration. LsaCfgFlags values can indicate disabled/enabled with or without UEFI lock depending on org choices.

Decision: If policy is set but WMI says “not running,” troubleshoot prerequisites (drivers, hypervisor state, Secure Boot, reboot required).

Task 5: Check if LSASS is running as a Protected Process Light (PPL)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Name lsass | Select-Object Name,Id,Path | Format-List"
Name : lsass
Id   : 628
Path : C:\Windows\System32\lsass.exe

What it means: PowerShell doesn’t directly show PPL. This task confirms the process path and sanity before you check registry and eventing in the next step.

Decision: If lsass is not at the expected path, treat as suspicious and investigate immediately.

Task 6: Verify “RunAsPPL” setting for LSASS

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v RunAsPPL"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    RunAsPPL    REG_DWORD    0x1

What it means: RunAsPPL=1 enables LSASS as a protected process light, which blocks many user-mode dumping techniques unless the attacker has kernel-level tricks.

Decision: If it’s 0 or missing, enable it in your baseline. Credential Guard and PPL are complementary; don’t pick one and call it done.

Task 7: Check WDigest usage (plaintext exposure risk)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
    UseLogonCredential    REG_DWORD    0x0

What it means: 0 generally means WDigest is not caching credentials in a way that exposes plaintext. 1 is a bright red flag unless you have a very specific legacy need.

Decision: If it’s 1, fix it via policy and audit which apps are forcing it. If someone “needed it,” make them prove it and isolate that system.

Task 8: Identify NTLM usage on the endpoint (local events)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 30 | Where-Object {$_.Properties[10].Value -like 'NTLM*'} | Select-Object -First 5 | ForEach-Object { $_.Properties[5].Value + ' ' + $_.Properties[10].Value }"
jdoe NTLMv2
svc_backup NTLMv2
jdoe NTLMv2

What it means: Recent logons using NTLM are showing up. Event parsing varies; the point is to find whether NTLM is still active in workflows.

Decision: If NTLM is common for admin accounts or server access, you have a lateral movement accelerant. Plan NTLM restrictions and move services to Kerberos where possible.

Task 9: Check cached logon count (offline credential cache exposure)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount"
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

What it means: Windows caches a number of previous domain logons for offline use. Higher numbers mean more cached material worth attacking on stolen laptops.

Decision: Reduce it where business allows (especially for privileged users), and pair with BitLocker and strong device controls. Don’t break road warriors without warning; pilot first.

Task 10: Verify Remote Credential Guard readiness (RDP client / server capability)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SecurityLayer,UserAuthentication | Format-List"
SecurityLayer      : 2
UserAuthentication : 1

What it means: Settings indicate RDP security negotiation and NLA. Not a full Remote Credential Guard check, but it’s a fast signal that you’re not running completely naked RDP.

Decision: If NLA is off, turn it on. Then design admin access to use Remote Credential Guard or equivalent hardened jump hosts.

Task 11: Confirm Secure Boot state (often required for locked-down modes)

cr0x@server:~$ powershell -NoProfile -Command "Confirm-SecureBootUEFI"
True

What it means: Secure Boot is enabled. Some Credential Guard deployment modes (especially with UEFI lock) assume Secure Boot to raise tamper resistance.

Decision: If false, decide whether to accept “configured but easier to tamper” or plan Secure Boot enablement. For privileged endpoints, plan it.

Task 12: Check if you’re in a VM (and whether VBS is supported there)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Model,Manufacturer"
Model        Manufacturer
-----        ------------
Virtual Machine Microsoft Corporation

What it means: This host is virtualized. VBS/Credential Guard support in VMs depends on your hypervisor, version, and features (nested virtualization, vTPM, etc.).

Decision: If critical servers are VMs, validate the hypervisor supports the security features you’re mandating. Don’t “require VBS” and then deploy on a platform that can’t run it.

Task 13: Spot potentially dangerous delegation settings on accounts (AD query from an admin host)

cr0x@server:~$ powershell -NoProfile -Command "Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | Select-Object SamAccountName,TrustedForDelegation | Sort-Object SamAccountName | Select-Object -First 5"
SamAccountName TrustedForDelegation
------------- --------------------
svc_app01     True
svc_legacy02  True

What it means: Accounts trusted for delegation can increase the impact of credential theft and ticket abuse.

Decision: Audit why each one exists. Prefer constrained delegation and modern auth patterns. If you don’t know why it exists, that’s your answer.

Task 14: Confirm ASR rule state relevant to credential theft (Defender)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids | Select-Object -First 5"
D4F940AB-401B-4EFC-AADC-AD5F3C50688A
9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2

What it means: ASR rules are configured. You still need to map GUIDs to rule intent in your standard, but this tells you whether the endpoint is even in the game.

Decision: If ASR isn’t used, Credential Guard alone leaves other credential theft paths open (scripted dumping, suspicious process behaviors). Plan ASR in audit mode, then enforce.

Task 15: Confirm crash dump settings (prevent “oops we wrote LSASS to disk” moments)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v CrashDumpEnabled & reg query 'HKLM\SYSTEM\CurrentControlSet\Control\CrashControl' /v DumpFile"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    CrashDumpEnabled    REG_DWORD    0x2

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    DumpFile    REG_EXPAND_SZ    %SystemRoot%\MEMORY.DMP

What it means: Kernel/memory dumps can contain sensitive material depending on crash context and tooling. This isn’t “Credential Guard off” bad, but it’s a data handling risk.

Decision: Ensure dumps are protected (ACLs, encryption at rest, limited access), and that your incident process treats dumps as high sensitivity.

Three corporate mini-stories from the real world

Mini-story 1: The incident caused by a wrong assumption

A mid-sized enterprise had a strong EDR and a proud patch cadence. Their assumption was simple: “If Defender and EDR are installed everywhere, credential dumping will be detected.” They treated credential theft as a detection problem, not an exposure problem.

A phishing campaign landed on a finance workstation. The initial malware didn’t do anything fancy. It waited for a local admin token (someone from IT remoted in to “fix Outlook”), then used that privilege to attempt LSASS access. The EDR blocked one known dumping technique. Everyone breathed. Ticket closed.

Two days later, a file server showed strange access patterns. Then a domain controller. The attacker didn’t need to dump LSASS the “loud” way. They used alternate paths: token impersonation, harvested cached material, and replayed credentials using built-in Windows plumbing. They weren’t faster than the blue team. They were just more patient.

The postmortem was painful because the controls were “there,” but the secrets were still reachable. Credential Guard wasn’t enabled because “we heard it breaks some VPN stuff.” That was true for a handful of endpoints, not for 18,000.

The fix wasn’t heroic. They rolled out Credential Guard to standard users first, then to IT, then to a carefully designed admin workstation tier. The biggest change was cultural: admin accounts stopped logging into random endpoints. The attacker’s favorite move—grab a privileged hash from a workstation—stopped being reliable.

Mini-story 2: The optimization that backfired

A global company had a performance obsession. They optimized boot times and remote access at scale. Part of that optimization included keeping credential caching generous (“users travel”), allowing NTLM broadly (“legacy shares”), and leaving a handful of convenience policies enabled because they reduced helpdesk calls.

Then they turned on Credential Guard for a pilot group of developers. A small set of remote workflows slowed down. Some older authentication handshakes failed. The loud conclusion became: “Credential Guard causes problems.” The quiet reality was: “We’ve been relying on insecure fallbacks as performance optimizations.”

Instead of fixing the dependency chain, they rolled back. Six months later, an attacker landed on a dev workstation, scraped what they could, and used NTLM-based lateral movement to reach a build server. From there they tampered with artifacts, and incident response became a software supply chain problem—expensive, reputation-heavy, slow to unwind.

Afterward, the “optimization” got renamed to what it was: a security debt instrument with compounding interest. They reintroduced Credential Guard, but this time they paired it with remediation: migrating specific services to Kerberos, tightening NTLM scope, and using hardened jump hosts for admin paths. Performance was fine. The insecure fallback had been the actual bottleneck—just not the one measured on dashboards.

Mini-story 3: The boring but correct practice that saved the day

A healthcare org ran a strict endpoint baseline. It wasn’t glamorous. It was a pile of group policies, VBS where possible, Credential Guard enforced on most endpoints, and a hard rule: privileged accounts only log into privileged access workstations. They also kept a small exception list for systems that could not support VBS, and those were isolated like radioactive material.

They still got hit with malware. Everyone does. The difference was what the malware couldn’t do. It landed on a nursing station PC, got user-level access, and tried to move laterally. It found little to reuse. Admin creds weren’t present. Credential material was less accessible. The obvious PtH and PtT routes were unreliable.

The attacker pivoted to opportunistic ransomware behavior. The blast radius was ugly but contained: a subset of desktops and a couple of file shares. Domain controllers stayed clean. Core clinical systems stayed online. The org had a bad week instead of a catastrophic month.

The post-incident review was almost boring: “Baseline worked as designed.” That’s the goal. Reliability isn’t fireworks; it’s the absence of surprise.

Checklists / step-by-step plan (rollout that won’t blow up your helpdesk)

Credential Guard is not a checkbox. It’s a deployment. Do it like an SRE would: staged, measurable, reversible where appropriate, and with tight feedback loops.

Step 1: Inventory and segment endpoints (don’t boil the ocean)

Tier 0/1/2 model: domain controllers and identity infrastructure; server tiers; user endpoints.
Identify endpoints that must support legacy auth (vendor systems, old VPN clients, specialty hardware drivers).
Create an “exception ring” with compensating controls (network isolation, restricted admin logons, stronger EDR policies).

Step 2: Enable prerequisites cleanly

Firmware virtualization enabled.
Secure Boot enabled where feasible (especially privileged endpoints).
Driver hygiene: remove or update incompatible kernel drivers.

Step 3: Pilot in rings

Ring 0: IT security team laptops and a few friendly power users.
Ring 1: standard user population.
Ring 2: developer workstations (often the messiest auth stack).
Ring 3: privileged access workstations and jump hosts.

Step 4: Pair with the boring controls that make it stick

Enable LSASS PPL (RunAsPPL) where supported.
Disable WDigest plaintext caching (verify it stays disabled).
Use Attack Surface Reduction rules (start in audit, then enforce).
Reduce NTLM footprint; restrict where it can be used.
Separate admin identities and restrict where privileged accounts can log in.

Step 5: Monitor and enforce

Report “configured but not running” states.
Track exception devices and justify them periodically.
Alert on suspicious access to LSASS and credential material.

Step 6: Document the failure modes users will report

Old VPN clients that try to hook authentication providers.
Legacy SSO plugins.
Smart card middleware or security tools with outdated drivers.

Joke #2: The only thing more permanent than a temporary exception is a temporary exception that “just needs one more quarter.”

Common mistakes: symptom → root cause → fix

1) “Credential Guard is enabled by policy, but it’s not running.”

Symptom: WMI shows VBS status “configured” or “off,” and SecurityServicesRunning is empty.

Root cause: Missing firmware virtualization, Secure Boot state mismatch, incompatible drivers, or no reboot after enabling.

Fix: Validate firmware virtualization (Task 3), Secure Boot (Task 11), and remediate driver conflicts. Reboot. If on VMs, confirm hypervisor support (Task 12).

2) “After enabling, VPN/SSO broke.”

Symptom: Authentication prompts loop, SSO fails, or a client won’t connect.

Root cause: Legacy credential providers, authentication hooks, or drivers not compatible with VBS isolation.

Fix: Upgrade the client, move to a supported auth method, or isolate that workflow to hardened jump hosts. Don’t roll back globally—create an exception ring with compensating controls.

3) “RDP into servers now asks for credentials differently / automation broke.”

Symptom: Scripts that rely on stored creds fail; admin complains about extra prompts.

Root cause: You were depending on credential delegation patterns that are risky by design.

Fix: Use Remote Credential Guard where appropriate, move automation to managed identities/service principals, and stop embedding reusable secrets in scripts.

4) “EDR says LSASS access blocked; users report random app failures.”

Symptom: A security tool blocks a process from reading LSASS; a “password manager” or “monitoring agent” complains.

Root cause: A legitimate (or not-so-legitimate) tool is attempting credential access behavior indistinguishable from dumping.

Fix: Remove the tool or get a vendor-supported version that doesn’t require LSASS scraping. Treat “needs LSASS read” as a design flaw, not a requirement.

5) “We enabled Credential Guard, but attackers still moved laterally.”

Symptom: Lateral movement still occurred via SMB/RDP/WinRM.

Root cause: Credential Guard reduces certain credential theft paths; it doesn’t fix poor admin hygiene, excessive privileges, NTLM sprawl, or credential phishing.

Fix: Enforce admin workstation model, restrict NTLM, reduce local admin membership, and harden remote management. Assume endpoint compromise and design for containment.

6) “Helpdesk disabled it on a few machines to fix a ticket—and forgot.”

Symptom: Drift: some endpoints no longer run VBS/Credential Guard.

Root cause: No enforcement/reporting loop; exceptions are not tracked as operational debt.

Fix: Monitor running state (Tasks 1–2) centrally, enforce policy, and require time-bound exceptions with review.

One quote worth keeping on your wall

Paraphrased idea — Werner Vogels: you build systems assuming things fail, and you make them resilient by design, not by wishful thinking.

What to avoid: the “security theater” version of this control

Credential Guard is often deployed in a way that looks good on a slide and does little in practice:

Enabled on a subset of endpoints with no measurement of “running state.”
Admins continue logging into everything, so privileged credentials still land on low-trust boxes.
NTLM remains everywhere, and exceptions multiply silently.
No plan for legacy apps, so teams roll back at the first complaint.

Don’t do that. If you’re going to take the political and operational heat of tightening authentication, you should get the security benefit.

How Credential Guard changes attacker math (practically)

In incident response, you’re constantly asking: “If they had admin on a workstation, could they have taken the domain?” Credential Guard makes that question less terrifying because it reduces the chance that a single compromised endpoint becomes a credential fountain.

But it only works if you treat it as part of an identity containment strategy:

Reduce credential presence: Don’t log privileged accounts onto untrusted devices.
Reduce credential reuse: Fewer shared local admin passwords, fewer service accounts with broad rights.
Reduce legacy auth: NTLM scope reduction, remove old providers.
Reduce extraction: Credential Guard + LSASS PPL + EDR/ASR + driver control.

This is the SRE view of security: control the blast radius, remove single points of catastrophic failure, and measure your controls as running systems, not intentions.

FAQ

1) Is Credential Guard the same as “LSASS protection”?

No. LSASS protection (RunAsPPL) makes it harder for processes to read LSASS. Credential Guard uses VBS to isolate secrets so they aren’t sitting in LSASS memory in the first place. Use both when you can.

2) Will Credential Guard stop Mimikatz?

It can significantly reduce what common credential dumping tools can extract from LSASS on properly configured systems. It won’t stop every post-exploitation technique, and it won’t stop phishing. It changes what’s available to steal.

3) Why do I hear “it breaks things”?

Because some software relies on legacy credential provider behavior or kernel drivers that don’t behave well with VBS. That’s a software quality issue you can usually remediate with upgrades, configuration changes, or workflow redesign.

4) Do I need Windows Enterprise?

Credential Guard is generally positioned for Enterprise/Education editions and managed environments. In practice, what you can enable depends on OS edition, build, and management approach. Validate against your fleet before promising anything.

5) Can I enable it on servers?

Yes, in many scenarios, but treat servers like production infrastructure: test driver compatibility, security tooling, and remote management workflows. Some servers (especially older or specialized) may need exceptions with isolation.

6) If I use smart cards or Windows Hello for Business, do I still need this?

Yes. Stronger user authentication helps, but Credential Guard is about protecting derived credential material and reducing replay opportunities on compromised endpoints.

7) How do I prove to auditors that it’s actually enabled?

Don’t prove “policy is set.” Prove “it is running.” Use WMI signals (Tasks 1–2) collected centrally and report drift. Auditors love evidence; attackers love drift.

8) What’s the biggest reason it fails as a security investment?

Admin behavior. If privileged accounts still log into user workstations, you can still lose the domain through alternate paths. Credential Guard reduces one big avenue; it doesn’t excuse bad identity hygiene.

9) Should I disable NTLM after enabling Credential Guard?

Not as a big-bang change. Measure NTLM usage first, then restrict it surgically. The goal is to reduce NTLM where it’s unnecessary and contain it where it’s unavoidable.

10) Is this worth doing if I already have an EDR?

Yes. EDR is detection and response. Credential Guard is exposure reduction. You want both: fewer secrets available to steal, and better chances to catch the attacker anyway.

Next steps you can do this week

If you want this to be real—not a policy PowerPoint—do these practical steps:

Measure reality: Run Tasks 1–2 across a representative sample. Count “running” vs “configured” vs “off.”
Find your blockers: For systems not running, collect firmware virtualization state (Task 3) and Secure Boot (Task 11). Identify driver conflicts and vendor agents.
Kill obvious legacy exposure: Ensure WDigest is disabled (Task 7) and enable LSASS PPL where supported (Task 6).
Fix admin logon paths: Stop logging privileged users into random desktops. Build a privileged access workstation/jump host workflow.
Start an exception registry: Every device that can’t run Credential Guard goes on a list with a business owner, justification, compensating controls, and a review date.
Roll out in rings: Pilot, measure ticket types, remediate, expand. Don’t turn this into a Friday-night “surprise.”

Credential theft is popular because it works. Credential Guard is unpopular because it changes defaults. That’s exactly why you should enable it: it’s one of the few Windows controls that meaningfully reduces the value of a compromised endpoint.