I have a 25H2 installation here. Applied the above, ran the DG Readiness tool successfully, but the hypervisor continued to load:
Get-WinEvent -LogName system | Where-Object { $_.ProviderName -like 'Microsoft-Windows-Hyper*' }
ProviderName: Microsoft-Windows-Hyper-V-Hypervisor
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
2026-02-06 22:09:42 165 Information Hypervisor configured mitigations for CVE-2019-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 for virtual machines.…
2026-02-06 22:09:42 156 Information Hypervisor configured mitigations for CVE-2018-3646 for virtual machines.…
2026-02-06 22:09:42 129 Information Hypervisor initialized I/O remapping.…
2026-02-06 22:09:42 2 Information Hypervisor scheduler type is 0x1.
2026-02-06 22:09:42 1 Information Hypervisor successfully started.
Let's see if I can disable the hypervisor without help from Group Policy as several Windows editions have no such thing.
I've unlinked the relevant GPO from the domain, restored Device Guard to "not configured" in local Group Policy, run a gpupdate, then re-ran the DG Readiness ps1 script.
Then I rebooted TWICE -- 1st time so that whatever might alter the config has a chance to do so and 2nd for said alterations to go into effect.
On the first reboot I hit F3 at the "F3 to disable" blah-blah UEFI loader prompt; there's no hypervisor load this time. Sure enough on the 2nd reboot I have Microsoft-Windows-Hyper-V-Hypervisor | Hypervisor successfully started in the event log. Oof.
Windows Defender has no knob to turn Credential Guard off:
Per MS website
Cred Guard does use Virtualization-based Security (VBS). Check the registry and I have:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard]"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\KeyGuard\Status]
"IsTestConfig"=dword:00000000
"LsaIsoLaunchAttempted"=dword:00000001
"LsaIsoLaunchError"=dword:00000000
"ExecSystemProcessesError"=dword:00000000
"NumAttemptedRestarts"=dword:00000001
"NumSuccessfulRestarts"=dword:00000000
"KeyGuardEnabled"=dword:00000001
"CredGuardEnabled"=dword:00000001
"IsSecureKernelRunning"=dword:00000001
"EncryptionKeyAvailable"=dword:00000001
"EncryptionKeyPersistent"=dword:00000001
"SecretsMode"=dword:00000001
Flipped "KeyGuardEnabled" and "CredGuardEnabled" to 0 then reboot. No dice. Still have a hypervisor.
Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Key name: LsaCfgFlags
Type: REG_DWORD
Value: 0
Key path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard
Key name: LsaCfgFlags
Type: REG_DWORD
Value: 0
Now we're getting somewhere! Applied these, making sure the earlier reg keys were also returned to 0. Boom, 1-2-3 reboots and no hypervisor!🎉
---
What's going wrong?
How about line 1207 of theDG_Readiness_Tool_v3.6.ps1PowerShell script:
ExecuteCommandAndLog 'REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "LsaCfgFlags" /f'
...but Microsoft's Disable Credential Guard guidance (linked above) has:
[RageNoises.wav]
So anyway, I reckon
DG_Readiness_Tool_v3.6.ps1 remains useful as it chains the "
press F3 to disable Credential Guard" shim into UEFI boot (thus performing
Disable Credential Guard with UEFI lock for us).
I've also stumbled across these:
My system does have this key. I wonder if its presence was helping to keep "default enablement" in a state of, uh, enablement.
Going forward, to OP's guide I'd add something about:
- doing all steps in one go (i.e. no reboot until the end) since Credential Guard re-enabling itself during the next boot may undo one or more steps (e.g. it re-creates reg keys which we do not want and may re-implement UEFI lock).
- rechecking everything if hypervisor removal fails, given the way "default enablement" can take over.
- after execution then both before and after the first reboot, checking
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard]to ensure there's no "Enabled"=dword:00000001for any of the VBS-dependent technologies.
- leave nothing to chance by creating explicit
"Enabled"=dword:00000000keys for all VBS-dependent technologies under theCredentialGuardkey. I don't have a full list but I'll bet we can crowdsource one...
- adding a check for the two
LsaCfgFlags reg keys; user shall create/modify if needed.
- Group Policy may be ineffective in some cases. In my case it was definitely not working. I'm contemplating a hand-crafted .ADMX/.ADML we might use to help with this project.