Enable Credential Guard only after testing authentication dependencies

Source facts: Credential Guard changes how selected credentials are available

Microsoft’s Credential Guard considerations and known-issues guidance documents compatibility implications and scenarios that require planning. Credential Guard uses virtualization-based security, and enabling or disabling it can interact with operating-system defaults, policy, firmware, virtual machines, and deployment method.

Microsoft’s technical overview explains that isolated LSA stores selected Kerberos, NTLM, and Credential Manager secrets outside the ordinary operating-system process using VBS. It also states protection limits. Credential Guard does not protect credentials managed outside Windows protections, keyloggers, physical attacks, the Active Directory database on a domain controller, or every credential supplied to legacy authentication.

The documentation describes protocol effects: certain uses of NTLMv1, MS-CHAPv2, Digest, CredSSP, unconstrained delegation, and DES can no longer use signed-in credentials as before. Exact defaults, hardware requirements, support, and behavior vary by Windows edition, version, device role, virtualization platform, and policy. Review current Microsoft and product-vendor documentation for the target fleet.

DSE recommendation: use deployment to expose and retire weak dependencies

Do not begin by forcing the policy across the fleet. Build a readiness inventory that connects devices to business workflows and authentication dependencies. Include privileged workstations, standard laptops, shared workstations, kiosks, jump hosts, servers used interactively, virtual desktops, VPN, Wi-Fi, RDP, file and print, line-of-business applications, smart cards, third-party credential providers, endpoint security, and backup or recovery tools.

Confirm platform readiness. Verify supported Windows edition and build, firmware, Secure Boot, virtualization extensions, TPM state where applicable, VBS and hypervisor compatibility, driver and security-software support, and virtual-machine configuration. Remediate unsupported firmware and drivers before attributing failures to authentication.

Find legacy protocols. Use approved directory, network, endpoint, and application evidence to identify NTLM versions, MS-CHAPv2, Digest, CredSSP, unconstrained delegation, DES, saved credentials, and non-Microsoft security packages. Validate each dependency with its owner; a log event does not by itself prove safe removal.

Define the pilot. Include each hardware model, Windows build, user type, location, network, privileged workflow, remote-access method, and critical application. Provide a control group, change window, support contact, stop threshold, and documented recovery that does not require an unavailable credential path.

Exercise real workflows. Test sign-in with and without domain connectivity, lock and unlock, password and authenticator change, VPN, Wi-Fi, RDP, file shares, print, administration, application single sign-on, scheduled work, sleep, hibernate, restart, patching, and disaster-recovery access. Include help-desk and break-glass procedures.

Observe and remediate. Collect supported Credential Guard state, VBS status, authentication events, application and driver errors, help-desk cases, latency, and fallback authentication. Fix the protocol or application where possible rather than creating broad exclusions that restore credential exposure.

Stage enforcement. Expand by well-understood rings, monitor after each wave, and pause on systemic failure. Keep policy ownership and rollback controlled. A device that reports the feature enabled but cannot perform its required recovery path is not production-ready.

Separate Credential Guard from Remote Credential Guard, LSA protection, Windows Hello, and other related features in design and test records; they have different requirements and boundaries. Protect the hypervisor and host of virtual machines, because in-guest isolation does not defend against a privileged host attack.

Retest after major Windows, firmware, hypervisor, VPN, security-agent, or application changes. The completion record should list supported devices, workflows exercised, remaining legacy dependencies, exceptions, and recovery results. Credential Guard reduces specific credential-theft paths; it is not a substitute for privileged-access separation, patching, phishing resistance, endpoint protection, or least privilege.

Use an exit gate for every deployment ring: all required workflows pass, recovery was demonstrated, state reporting is reliable, support can recognize known errors, and every exception has an owner and end condition. Stop on widespread fallback prompts, lost remote administration, incompatible security software, or inability to boot and recover. Preserve diagnostic evidence, restore the approved configuration, remediate the dependency, and rerun the full ring.

Official references

Microsoft, Considerations and known issues when using Credential Guard.

Microsoft, How Credential Guard works.