Credential Guard Disabled After Upgrade: Verify and Remediate

What Is Credential Guard Disabled After Upgrade?

Credential Guard disabled after upgrade can be an inherited configuration, even on a Windows release that enables the feature by default. An eligible upgrade does not erase an earlier explicit decision to turn it off. Before treating a current operating system as proof of credential protection, check the machine's edition, deployment history, policy and running services. Microsoft's configuration guidance documents this persistent exception.

Credential Guard isolates selected domain secrets using virtualization-based security (VBS). The practical task is to establish whether that isolation is running on the devices where domain users sign in. A deployment policy and a successful operating system upgrade answer different questions from a runtime check.

This guide reflects Microsoft Learn pages checked on 3 October 2026. It covers eligible Windows 11 devices from version 22H2 and eligible Windows Server 2025 domain members. The commands below are quoted from documentation; they were not executed against a Windows estate for this article. No prevalence of inherited exceptions is asserted.

How Default Enablement Works

Microsoft's Credential Guard overview describes default enablement beginning with Windows 11 22H2 and Windows Server 2025. Its introduction frames this around eligible domain-joined systems that are not domain controllers; its Windows-specific conditions list licensing, hardware/software eligibility and absence of an explicit disable. Keep those qualifications when reviewing an AD fleet.

For the historical Pro case, Microsoft identifies HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret as the registry indicator to inspect. It identifies that history; it is not a live measurement of isolation. The licensing table does not give Pro, Pro Education or SE the same entitlement as Enterprise and Education. Microsoft overview

Hardware eligibility also needs review. The overview lists VBS and Secure Boot for protection and recommends TPM rather than making TPM a blanket Credential Guard requirement. It separately notes that VBS can reach a running state without Secure Boot. Preserve that distinction: a running VBS service alone does not certify the intended platform protections. The VBS platform documentation details virtualization extensions, SLAT and firmware/DMA requirements.

Why an Explicit Disable Survives the Upgrade

Microsoft states that explicitly configured values override default enablement after reboot. A device explicitly disabled before an upgrade remains disabled afterwards. The upgrade is therefore a useful audit boundary, not a remediation for an old exception. Configure Credential Guard

Review LsaCfgFlags in both HKLM\SYSTEM\CurrentControlSet\Control\Lsa and HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Microsoft documents 0 for explicit disable, 1 for enablement with UEFI lock, and 2 for enablement without lock. In GPO, review Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security, including its nested Credential Guard configuration. Microsoft configuration and disablement procedures

An exception may have been introduced for a real application dependency. Microsoft's known issues discuss MS-CHAPv2/NTLMv1 single sign-on, saved CredSSP credentials and CredSSP-based Hyper-V live migration. Establish which workflow originally needed the exception, whether it still does, and who owns the decision. Avoid assuming either that the exception remains necessary or that it can be removed without testing.

The Attack Chain: What Missing Isolation Changes

Without Credential Guard's isolation, sufficiently privileged local compromise can make domain secrets present on the host more accessible to theft from LSASS. Protected secrets are instead handled through an isolated LSA component when Credential Guard runs. Theft and reuse still depend on the secrets present, attacker privileges and an available authentication path; a disabled control is not automatic domain compromise. How Credential Guard works

Our Pass-the-Hash in Active Directory article explains how stolen NTLM material can support lateral movement when the destination accepts NTLM and the account has useful rights. It already discusses Credential Guard as a mitigation. This guide adds the inherited-disable investigation and runtime verification needed to establish whether that mitigation is actually in place.

Credential Guard has limits even when active: local/Microsoft accounts, Kerberos service tickets, manually supplied NTLM credentials, keyloggers and abuse of an existing session's privileges remain relevant risks. Cached domain logon verifiers are also not NTLM hashes that can simply be presented to another machine. Microsoft protection limits

Detection: Measure the Running Service

On the target Windows device, use an elevated PowerShell session and the exact command Microsoft provides in Verify if Credential Guard is enabled:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Interpret the result as a set of service identifiers. Presence of 1 means Credential Guard is running; 2 means memory integrity. A result containing both 1 and 2 includes Credential Guard. SecurityServicesConfigured describes configuration, while SecurityServicesRunning describes execution; VirtualizationBasedSecurityStatus describes VBS. These are separate observations. Microsoft's Win32_DeviceGuard property reference

Alternatively, open msinfo32.exe, select System Summary, and look for Credential Guard in Virtualization-based Security Services Running. Microsoft advises against using the presence of LsaIso.exe in Task Manager as the verification method. Microsoft verification guidance

When configuration and runtime differ, inspect Windows Logs → System, source WinInit. Microsoft documents these startup signals on the same configuration page:

These events describe protection state, not proof that credentials were stolen. A failed collection is unknown, not disabled. Record the host, collection time and reboot context so an old event or inaccessible endpoint is not mistaken for current coverage.

Remediation: Replace the Exception and Verify After Reboot

1. Build an exception inventory

For each candidate, record version, edition/licensing, platform eligibility, domain/DC role, explicit local and managed settings, and runtime result. Separate confirmed non-running devices from hosts that could not be measured. Prioritize investigation where domain credentials are used, while retaining the exclusions documented above.

2. Test the dependency that justified disabling it

Use representative devices and the actual authentication workflows. Microsoft recommends certificate-based Wi-Fi/VPN authentication instead of MS-CHAPv2, and Kerberos Constrained Delegation or Resource-Based Kerberos Constrained Delegation for affected Hyper-V migration workflows. These changes address the dependency rather than perpetuating the disable. Record an owner and review date for exceptions that must remain. Microsoft compatibility guidance

3. Set an explicit supported configuration

For domain-managed devices, follow Microsoft's GPO procedure: enable Turn On Virtualization Based Security under Computer Configuration → Administrative Templates → System → Device Guard, then choose Enabled with UEFI lock or Enabled without lock under Credential Guard Configuration. Scope and test the deployment before broad rollout. Restart after policy application. Intune also provides these Credential Guard options. Microsoft deployment instructions

The documented registry alternative uses EnableVirtualizationBasedSecurity=1 under HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard, with LsaCfgFlags=1 or 2 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. RequirePlatformSecurityFeatures under the DeviceGuard path selects Secure Boot (1) or Secure Boot plus DMA protection (3). Follow the full documented procedure and resolve conflicting managed configuration. Microsoft registry settings

Choose the lock deliberately. Default enablement is without UEFI lock; removing a UEFI-locked configuration requires Microsoft's firmware procedure and physical confirmation. A registry edit alone does not remove that firmware state. Document recovery capability before selecting the lock. Microsoft UEFI-lock procedure

4. Verify and retain evidence

After reboot, repeat the documented CIM command or msinfo32.exe check and review WinInit errors. Close the remediation when the intended service runs and required workflows pass testing, not merely when a GPO exists. Keep unresolved devices in the inventory with their actual evidence and next action.

This runtime check does not establish whether credentials were exposed before protection started. Microsoft recommends enabling Credential Guard before domain join or the first domain user sign-in, because secrets used earlier may already have been compromised. Microsoft deployment guidance

Review adjacent credential exposure too. Our WDigest enabled article explains how UseLogonCredential and stale exceptions can increase the credential material exposed in LSASS. That is a complementary review of credential storage, not a substitute for measuring Credential Guard isolation.

How EtcSec Detects This

EtcSec's etc-collector includes CREDENTIAL_GUARD_DISABLED, a Medium-severity GPO configuration check. Its Detect() reads collected GPO policies and looks for a VBS value of 1 and a Credential Guard LsaCfgFlags value of 1 or 2. If either condition is missing, it records a configuration finding.

The lookup takes the first setting found through Default DC Policy, Default Domain Policy, then other GPOs; the two values can come from different policies. It does not calculate every endpoint's resultant policy, query each host's CIM state or identify automatic enablement on each machine. GPO configuration is not effective runtime state. An absent GPO value can coexist with a running default-enabled service; a present setting does not prove execution across the fleet.

Use the finding to open the configuration investigation, then attach host-level measurements to the remediation record. The useful evidence chain is eligibility, explicit settings, applied configuration, reboot and runtime verification. Keep unknown results visible so configuration coverage is not reported as measured protection.