# Enable Credential Guard only after testing authentication dependencies > Windows Credential Guard isolates selected secrets with virtualization-based security, but legacy protocols, delegation, security packages, remote access, firmware, virtualization, and applications can change behavior. Discover and pilot before enforcement. - Canonical URL: https://update.dsesecurity.com/updates/enable-credential-guard-after-testing-authentication-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:58:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Windows Credential Guard isolates selected secrets with virtualization-based security, but legacy protocols, delegation, security packages, remote access, firmware, virtualization, and applications can change behavior. Discover and pilot before enforcement. ## Potentially affected Supported Windows 10, Windows 11 and Windows Server devices; virtualization-based security, Secure Boot and TPM; Kerberos, NTLM, Credential Manager, CredSSP, delegation, RDP, VPN and Wi-Fi authentication; security packages; hypervisors; help desk; and recovery. ## DSE recommendation Confirm supported hardware and operating systems, inventory authentication and credential dependencies, establish a compatible firmware and virtualization baseline, pilot representative devices and workflows, collect errors and user impact, remediate dependencies, stage enforcement, and retain recovery procedures. ## Article ## Source facts: Credential Guard changes how selected credentials are available Microsoft’s [Credential Guard considerations and known-issues guidance](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues) 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](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/how-it-works) 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](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues). - Microsoft, [How Credential Guard works](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/how-it-works). ## Primary reference - Name: Microsoft Learn: Considerations and known issues when using Credential Guard - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable Credential Guard only after testing authentication dependencies,” DSE Security, https://update.dsesecurity.com/updates/enable-credential-guard-after-testing-authentication-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.