Disable Credential Guard on Windows 11
Read the risks section before doing this. Credential Guard is one of the most effective mitigations against credential theft on Windows, and on Windows 11 22H2+ it's enabled by default on hardware that supports it. This guide covers how to disable it when there's a genuine need to, what those legitimate reasons actually look like, and — more importantly — the recommended best practice for handling this without leaving an endpoint permanently exposed.
What Credential Guard Actually Protects
Credential Guard uses Virtualization Based Security (VBS) to run LSASS-related secrets in an isolated, hypervisor-protected enclave, separate from the normal Windows kernel and separate from LSASS.exe itself. Even a process running as SYSTEM cannot read NTLM password hashes or Kerberos ticket-granting tickets out of that enclave the way tools like Mimikatz read them out of ordinary LSASS memory. This is the specific control recommended for enablement in Windows Workstation Hardening and Windows Server Hardening — this how-to exists for the narrower case where you have a specific, documented reason to turn it off.
Reasons You Might Need to Disable It
- Application or driver incompatibility. Some legacy line-of-business applications, smart card middleware, or third-party security/remote-access agents with kernel drivers were never updated for VBS isolation and fail, crash, or behave incorrectly with Credential Guard active.
- Nested virtualization conflicts. Credential Guard depends on the Hyper-V hypervisor layer. Running Windows 11 as a guest VM inside a host hypervisor that doesn't support nested virtualization (or doesn't expose it to the guest) can cause boot failures or forces a choice between VBS and the outer virtualization platform.
- Performance-sensitive workloads on older hardware. VBS carries measurable CPU/memory overhead, most noticeable on older CPU generations or latency-sensitive workloads (some gaming, some real-time/creator workloads).
- Diagnostics. Temporarily disabling it to isolate whether VBS/Credential Guard is the actual cause of a specific instability or BSOD, before re-enabling once the real root cause is found elsewhere.
None of these are "Credential Guard is inconvenient" — they're specific, technical incompatibilities. If your actual motivation is "I want the option to turn this off remotely without being at the machine," that's not a reason to disable it — see the best practice below.
Recommended Best Practice
- Default to keeping it enabled. It directly mitigates one of the most common post-exploitation techniques attackers use (see Risks, below). Don't disable it as a default posture or a blanket fleet-wide policy change.
- If you need remote toggle flexibility, configure "Enabled without lock" — don't disable. Credential Guard has two enabled states: Enabled with UEFI lock (tamper-resistant — disabling requires physical presence at the machine, by design) and Enabled without lock (can be turned off remotely via GPO/registry/Intune, no physical access needed). If your concern is operational flexibility rather than a genuine incompatibility, "Enabled without lock" gets you that without actually turning the protection off.
- If you genuinely must disable it, scope the exception as narrowly as possible. Target the specific machine or VM with the actual conflict — never a fleet-wide GPO — and treat it the same way Application Control recommends treating any security exception: documented business justification, an accountable owner, a review/recertification date, and it does not get treated as a permanent state by default.
- For VM-specific needs, disable it from the host, scoped to that VM — not on physical hardware — using
Set-VMSecurity(see below). - Apply compensating controls for the duration of the exception (see below) — disabling Credential Guard should never be a bare, unmitigated action.
Check Current Status First
# Run from an elevated PowerShell session
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
0 = Credential Guard is not running. 1 = it's running.
Or via the GUI: Start → msinfo32.exe → System Summary — confirm whether Credential Guard appears next to Virtualization-based Security Services Running.
This matters because the disable procedure differs depending on whether it was originally enabled with or without a UEFI lock — check which state you're in before picking a method.
Disabling — Without UEFI Lock
If Credential Guard was configured as Enabled without lock, or is running under the Windows 11 22H2+ default-enablement behaviour, a registry or Group Policy change alone is sufficient — no physical presence required.
Group Policy:
Computer Configuration → Administrative Templates → System → Device Guard
→ Turn On Virtualization Based Security → Disabled
Registry (both keys must be set — deleting them is not equivalent to setting them to 0):
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LsaCfgFlags /t REG_DWORD /d 0 /f
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard /v LsaCfgFlags /t REG_DWORD /d 0 /f
Restart the device to apply.
Disabling — With UEFI Lock
If Credential Guard was configured as Enabled with UEFI lock, the configuration is persisted in EFI firmware variables specifically so it can't be turned off by a remote registry/GPO change alone. This requires physical presence at the machine — someone has to press a key at boot to confirm the change.
- Apply the registry changes from the "Without UEFI Lock" section above first.
- From an elevated Command Prompt, remove the EFI variables:
cmd mountvol X: /s copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi" bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215} bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X: mountvol X: /d - Restart the device. Before Windows boots, a firmware prompt appears asking to confirm the security-relevant change — it must be manually confirmed at the keyboard. If nobody confirms it, the change is discarded and Credential Guard remains enabled.
This physical-presence requirement is a deliberate design choice, not friction to work around — it means a remote attacker (or a remote script) cannot silently disable Credential Guard even with administrative credentials.
Disabling for a Virtual Machine (Host-Side)
For the nested-virtualization scenario, disable it from the Hyper-V host for the specific guest VM, rather than touching physical-host configuration:
Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true
Risks of Running With Credential Guard Disabled
| Risk | Detail |
|---|---|
| LSASS credential dumping | Without Credential Guard, NTLM hashes and Kerberos tickets in LSASS memory are readable by SYSTEM-level processes — the exact technique tools like Mimikatz use, and formally tracked as MITRE ATT&CK T1003.001 — OS Credential Dumping: LSASS Memory |
| Pass-the-Hash / Pass-the-Ticket | Harvested NTLM hashes and Kerberos TGTs can be replayed to authenticate as the compromised user elsewhere on the network without ever knowing the plaintext password |
| Increased lateral movement blast radius | A single compromised endpoint with cached privileged credentials becomes a pivot point for broader domain compromise, not just a contained incident |
| Loss of a default-enabled baseline control | Windows 11 22H2+ enables this by default specifically because credential dumping is one of the most common, well-understood post-exploitation techniques — disabling it removes a control Microsoft now treats as standard, not optional |
| Undermines UEFI-lock tamper resistance | If disabling via the physical-presence procedure becomes a routine runbook step in your organisation, it normalises exactly the workflow an attacker would need someone to be talked through via social engineering |
Compensating Controls If You Must Disable It
None of these fully replace Credential Guard, but they reduce the exposure window for the duration of a documented exception:
| Control | What It Mitigates |
|---|---|
LSASS Protected Process Light (RunAsPPL) |
Raises the bar against basic/unsophisticated LSASS dumping tools, though it's bypassable by more capable tooling that Credential Guard's VBS isolation would have stopped |
| EDR alerting on LSASS access | Configure credential-dumping detection specifically (see Endpoint Detection and Response and the LSASS protection settings in CrowdStrike Falcon: Configuration & Settings) so an actual dumping attempt is caught even without Credential Guard blocking it outright |
| Protected Users security group | Enrol privileged accounts to force Kerberos-only authentication (no NTLM) and enforce short TGT lifetimes, independent of Credential Guard — see Windows Server Hardening |
| Application Control / allowlisting | Reduces the chance that a credential-dumping tool can execute on the exception machine at all — see Application Control |
| Network segmentation | Limit the exception machine's ability to reach other high-value systems, containing the blast radius if credentials are harvested |
Re-Enabling
Reverse whichever method was used to disable it (set LsaCfgFlags back to 1 for UEFI lock or 2 for without lock, or re-enable via GPO/Intune) and restart. If it was previously disabled via the UEFI-lock/bcdedit procedure, re-enabling through the registry or Group Policy is sufficient on its own — you don't need to reverse the bcdedit steps separately. If you want the tamper-resistant UEFI-locked state back (recommended), explicitly set LsaCfgFlags to 1, not 2.