Windows Defender Credential Guard and PEAP: What to Know

Starting with Windows 11 22H2, Microsoft enabled Credential Guard by default on Enterprise and Education devices. If your organization uses password-based 802.1X authentication for Wi-Fi or VPN, this is a problem. That’s because Credential Guard blocks PEAP-MSCHAPv2 authentication, meaning users will either be prompted to re-enter their credentials at every connection, or lose access entirely.

This article explains what Credential Guard does, why it conflicts with PEAP-MSCHAPv2, and how to resolve the issue permanently by migrating to certificate-based authentication with EAP-TLS.

What Is Windows Credential Guard?

Windows Credential Guard is a security feature available in Windows 10, Windows 11, and Windows Server 2016 and later. It uses virtualization-based security (VBS) to isolate sensitive credentials, protecting NTLM password hashes, Kerberos-derived credentials including Supplementary KW Kerberos Ticket Granting Tickets (TGTs), and domain credentials stored in Credential Manager. Through hardware virtualization, Credential Guard keeps these credentials inside a protected virtual container that the operating system itself cannot access.

The feature runs the Local Security Authority Subsystem Service (LSASS) process inside a Virtual Secure Mode (VSM) environment. This isolation means that even if malware gains administrative privileges on the host operating system (OS), it cannot extract credential material from LSASS memory.

Credential Guard is sometimes confused with Device Guard, but they aren’t the same. While Credential Guard protects user credentials, Device Guard protects devices from unauthorized code and malicious applications.

How Does Credential Guard Work?

Credential Guard places user credentials inside protected containers with hardware-backed virtualization-based security features. Since these containers are stored separately from the operating system, any attacks on the OS won’t expose the secret, contained credentials.

Any attempt to access the protected environment must pass through the LSASS, which validates requests independently through an isolated LSA process before accessing or modifying the protected container. This secure, certificate-based process protects against credential theft attacks.

What Does Credential Guard Protect Against?

Credential Guard specifically blocks attack techniques that rely on dumping or replaying cached credentials:

• Pass-the-hash attacks: Attackers steal NTLM hashes from LSASS memory and use them to authenticate as the victim without knowing the plaintext password.
• Pass-the-ticket attacks: Attackers extract Kerberos TGTs and use them to impersonate users across the domain.
• LSASS credential dumping: Tools like Mimikatz extract plaintext passwords, hashes, and tickets directly from LSASS process memory.
• Credential replay: Stolen domain credentials are reused to move laterally across the network.

These are among the most common techniques in targeted attacks against enterprise networks, making Credential Guard a valuable layer of defense for government agencies, financial institutions, and many other organizations handling sensitive data.

Use Cases for Credential Guard

Here’s where to deploy Credential Guard strategically to protect your organization:

• Workstations: User workstations are prone to credential theft; if a workstation is compromised, Credential Guard can limit privileges and movement
• Servers: Server attacks can compromise entire organizations and sensitive data; Credential Guard can prevent unauthorized server access
• Remote access: Remote-access authentication is vulnerable to credential theft; Credential Guard isolates and protects credentials
• Access controls: Normal users may attempt to extract higher-level credentials outside their purview; Credential Guard can detect and stop this
• Compliance: Credential protection is an essential component of modern cybersecurity requirements; Credential Guard may help you meet requirements
• Active attack mitigation: If attackers get past your security, Credential Guard makes it harder to move across the network or access additional credentials

Key Features & Benefits

Credential Guard is valuable because of its numerous security features and benefits.

• Hardware-backed security: Secure Boot offers strong hardware security, while Credential Guard keeps credentials locked away in virtual containers that only privileged system software can access.
• Virtual credential isolation: VBS creates a protected environment, separating credentials from the main operating system to prevent credential theft in standard attacks.
• Advanced persistent threat mitigation: Credential Guard protects against common attack tools and credential theft attack techniques. Attackers that penetrate standard security services have limited lateral movement, even in the case of malware running with administrative privileges.
• Integration with Windows systems and tools: Enterprise policy configuration with Group Policy Editor, Mobile Device Management (MDM) with Intune, event logging with Windows Event Viewer, and PowerShell verification are some of the seamless integrations available with Credential Guard. This multi-dimensional protection maximizes all platform security features.
• Automatic protection: Credential Guard is enabled by default on all supported hardware running Windows 11 22H2 or later — but depending on your authentication method, this may not be a benefit. Although both are Microsoft-derived, Credential Guard breaks PEAP-MSCHAPv2.

Known Limitations of Credential Guard

Credential Guard users must stay mindful of its limitations:

• May not save remote desktop (RDP) credentials: While Credential Guard is compatible with remote access, it may not save remote server credentials.
• Doesn’t protect third party-managed credentials: Credentials stored or managed locally or by other third-party software may not be protected by Credential Guard.
• Breaks legacy authentication capabilities: With Credential Guard enabled, existing protocols including NTLMv1, MS-CHAPv2, or Kerberos DES encryption will not work.
• No physical machine attack protection: Credential Guard can’t protect credentials from physical device attacks.
• No SAM or AD database protection: Any credentials protected by Kerberos or NTLM for local accounts also appear in the Security Accounts Manager (SAM), and in the Active Directory (AD) database for domain controllers; Credential Guard doesn’t protect those.
• Limited VM protection: While Credential Guard protects credentials from most attacks on virtual machines (VMs), privileged system attacks originating from the host may compromise credentials.

A robust security architecture requires a layered approach. However, Credential Guard isn’t compatible with many other preferred systems and authentication protocols. So, building the right system can be a challenge.

Credential Guard System Requirements

Not every Windows device supports Credential Guard. The requirements include:

• OS edition: Windows Enterprise or Education (Pro is excluded unless the device previously ran Credential Guard on an eligible license)
• Hardware: 64-bit CPU with SLAT (Second Level Address Translation) support
• Firmware: UEFI with Secure Boot enabled
• Trusted Platform Module (TPM): Version 1.2 or 2.0 (recommended but not strictly required)
• Hyper-V: VBS requires the Hyper-V hypervisor platform

Credential Guard Default Enablement in Windows 11

Starting with Windows 11 version 22H2 and Windows Server 2025, Credential Guard is enabled by default on devices that meet the hardware and licensing requirements. The default enablement uses no UEFI lock, so administrators can disable it remotely if needed.

This default-on behavior is the primary reason organizations are suddenly experiencing VPN and Wi-Fi authentication failures after upgrading to Windows 11 22H2 or later. Devices that worked fine on Windows 10 or earlier Windows 11 builds now have Credential Guard active without any explicit configuration change.

What Is PEAP-MSCHAPv2?

PEAP-MSCHAPv2 combines two protocols into one authentication flow for 802.1X networks:

1. PEAP (Protected Extensible Authentication Protocol) establishes an encrypted TLS tunnel between the client device and the RADIUS server. 
2. MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol v2) authenticates the user inside that tunnel using a challenge-response exchange based on the user’s Active Directory password.

This protocol is the most widely deployed 802.1X authentication method in Microsoft-centric enterprise environments. It is used for Wi-Fi, wired Ethernet, and VPN connections where organizations want to authenticate users with their AD domain credentials.

Why PEAP-MSCHAPv2 Is Vulnerable

Despite the PEAP tunnel, MS-CHAPv2 has well-documented weaknesses:

• Dictionary attacks:The challenge-response exchange is based on the user’s NT hash. Captured exchanges can be cracked offline.
• Credential exposure:The protocol transmits credential material (hashed, but crackable) to the RADIUS server.
• Over-the-air theft:An attacker running a rogue access point (Evil Twin) can capture the MS-CHAPv2 handshake and attempt offline cracking.
• No device identity:PEAP-MSCHAPv2 authenticates the user’s password, not the device itself. There is no way to verify that the connecting device is managed, compliant, or authorized.

These weaknesses are exactly why Credential Guard blocks MS-CHAPv2 from using cached credentials. From a security perspective, Credential Guard is doing the right thing — it just happens to break the workflow organizations depend on.

Why Credential Guard Breaks PEAP-MSCHAPv2

When Credential Guard is enabled, Windows blocks several protocols from accessing saved credentials for SSO:

Protocol	Impact with Credential Guard
MS-CHAPv2	SSO blocked; user must re-enter password
NTLMv1	SSO blocked
WDigest	SSO blocked
Kerberos unconstrained delegation	Fully blocked (SSO and supplied credentials)
PKINIT with RSA encryption	Fully blocked

For organizations using PEAP-MSCHAPv2 for Wi-Fi or VPN, this means:

• Users are prompted to enter credentials at every connection instead of using saved domain credentials for SSO.
• Some devices fail to connect entirely, especially when the 802.1X profile is deployed via Group Policy with “use Windows credentials” selected.
• Helpdesk ticket volume increases as users report that “Wi-Fi stopped working” after a Windows update.

IT administrators may not immediately connect the issue to Credential Guard, because the feature was enabled silently during the Windows 11 22H2 upgrade with no warning or event log entry visible to end users.

How to Confirm Credential Guard Is Causing the Issue

To verify that Credential Guard is active and blocking authentication:

1. Check Credential Guard status

Open PowerShell and run: Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

A value of `1` means Credential Guard is running.

1. Check event logs
   Open Event Viewer and navigate to `Application and Services Logs > Microsoft > Windows > NTLM > Operational`. Look for Event ID 4013 (NTLMv1 blocked by Credential Guard) or Event ID 4014 (credential key blocked).
2. Test with Credential Guard disabled
   Temporarily disable Credential Guard via Group Policy (`Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security > Disabled`) and restart. If Wi-Fi or VPN SSO resumes, Credential Guard is the cause.

How to Disable Credential Guard (Temporary Workaround)

Disabling Credential Guard restores PEAP-MSCHAPv2 SSO functionality, but it also removes the protection against pass-the-hash and credential dumping attacks. Use this only as a short-term measure while planning a migration to certificate-based authentication.

Disabling via Group Policy

1. Open `gpedit.msc`
2. Navigate to `Computer Configuration > Administrative Templates > System > Device Guard`
3. Set Turn on Virtualization Based Security to Disabled
4. Restart the device

Disabling via Registry

Enter the following commands in Command Prompt:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /f /v LsaCfgFlags /t REG_DWORD /d 0 reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard /f /v LsaCfgFlags /t REG_DWORD /d 0

If UEFI lock was enabled, additional steps involving the EFI system partition are required. After restart, you may see a “Credential Guard Opt-out Tool” prompt — press F3 to confirm.

Important: Disabling Credential Guard is a security trade-off. You regain SSO for password-based protocols, but you also re-expose NTLM hashes and Kerberos tickets to extraction by tools like Mimikatz. This is not a long-term solution.

The Permanent Fix: Migrate from PEAP-MSCHAPv2 to EAP-TLS

Microsoft’s official recommendation is to move from MSCHAPv2-based connections to certificate-based authentication using EAP-TLS. This is also the recommendation from NIST and the NSA for securing 802.1X network access.

 EAP-TLS replaces the password-based MS-CHAPv2 exchange with mutual certificate authentication. Here’s how that works:

• The RADIUS server presents its certificate to the client.
• The client presents its own X.509 certificate to the RADIUS server.
• Both sides verify the certificate chain. No password is transmitted or cached.

Why EAP-TLS Solves the Credential Guard Conflict

Credential Guard only blocks protocols that rely on password hashes or cached credentials. Certificate-based authentication does not use password material at all, so it is completely unaffected by Credential Guard. Organizations can keep Credential Guard enabled — maintaining protection against pass-the-hash and credential dumping — while delivering seamless, passwordless Wi-Fi and VPN access.

Benefits of EAP-TLS Over PEAP-MSCHAPv2

Feature	PEAP-MSCHAPv2	EAP-TLS
Authentication Factor	Password (knowledge)	Digital Certificate (possession)
Credential Guard Compatible	No (SSO is blocked)	Yes
Over-the-Air Credential Theft	Vulnerable (MS-CHAPv2 challenge/response)	Not possible
Password Reset Disruption	High (users disconnected until updated)	No impact
Device Identity Verification	Not supported	Built-in via certificate attributes
Helpdesk Ticket Load	High (password resets, SSO failures)	Low
Phishing Resistance	Vulnerable	Resistant

The Challenge: PKI and RADIUS Infrastructure

The reason many organizations still use PEAP-MSCHAPv2 is that EAP-TLS requires two things they may not have: a PKI to issue and manage client certificates, and a RADIUS server that supports certificate-based authentication.

Traditional on-premises PKI (such as Microsoft AD CS) and on-premises RADIUS (such as Microsoft NPS) are complex to deploy, maintain, and scale. They require dedicated servers, certificate lifecycle management, CRL distribution, and specialized expertise. For many IT teams — especially in education and mid-market organizations — this complexity has made PEAP-MSCHAPv2 the path of least resistance.

That trade-off no longer holds. With Credential Guard enabled by default, PEAP-MSCHAPv2 is no longer the easier option. It is the option that breaks.

How SecureW2 Makes the EAP-TLS Migration Simple

SecureW2 provides a cloud-native platform that delivers managed PKI and Cloud RADIUS as a service, removing the infrastructure barriers that have kept organizations on PEAP-MSCHAPv2.

JoinNow Dynamic PKI issues and manages X.509 certificates automatically. Certificates are enrolled through your existing MDM (Intune, Jamf, Google Workspace, Kandji) for managed devices, or through JoinNow MultiOS for BYOD devices — a self-service flow where users enroll in a few clicks without IT intervention.

JoinNow Cloud RADIUS authenticates every connection by validating the client certificate and performing a real-time identity lookup against your Identity Provider (Entra ID, Okta, Google Workspace). If a user is disabled in your IdP or a device falls out of compliance, access is revoked immediately — not at the next password change or certificate renewal cycle.

The result:

• Credential Guard stays on. Your devices keep the pass-the-hash and credential dumping protection that Credential Guard provides.
• Wi-Fi and VPN access works seamlessly. EAP-TLS authentication is unaffected by Credential Guard, so SSO is never interrupted.
• No on-premises infrastructure. No NPS servers to patch. No AD CS to maintain. No CRL distribution points to manage.
• Reduced helpdesk load. No password reset disconnections. No “Wi-Fi stopped working” tickets after Windows updates.

Moving Forward With SecureW2

Credential Guard is not going away. Microsoft continues to expand its default enablement across Windows editions, and the trend toward blocking insecure protocols will only accelerate. Organizations that are still running PEAP-MSCHAPv2 for 802.1X authentication need a migration plan — not a workaround.

The path forward is EAP-TLS with certificate-based authentication. It resolves the Credential Guard conflict, eliminates the password-based attack surface entirely, and delivers a better experience for both IT administrators and end users.

Schedule your free demo to learn about migrating from PEAP-MSCHAPv2 to EAP-TLS, or explore the JoinNow Platform to see how cloud-native PKI and RADIUS work together.

---

Frequently Asked Questions

Does Credential Guard break Wi-Fi?

Credential Guard does not break Wi-Fi itself. It breaks password-based 802.1X authentication methods — specifically PEAP-MSCHAPv2 and EAP-MSCHAPv2 — by preventing Windows from using cached credentials for SSO. Certificate-based methods like EAP-TLS are not affected.

Is Credential Guard enabled by default on Windows 11?

Yes. Starting with Windows 11 version 22H2, Credential Guard is enabled by default on devices running Enterprise or Education editions that meet the hardware requirements (VBS-capable hardware, Secure Boot, 64-bit CPU). This applies to both fresh installs and upgrades.

Should I enable Credential Guard?

On most devices running Windows 11 22H2 or later, Credential Guard is enabled by default. If you plan to use it on other devices, make sure to enable it before users join the domain to avoid credential theft. However, Credential Guard isn't a standalone security solution. For comprehensive, secure identity verification, organizations should adopt certificate-based EAP-TLS authentication alongside Credential Guard.

How to tell if Credential Guard is enabled?

To verify your Credential Guard configuration and confirm that it's enabled, check its status in PowerShell. Open PowerShell and run this command: Get-CimInstance -ClassName Win32_DeviceGuard -Namespace rootMicrosoftWindowsDeviceGuard).SecurityServicesRunning If you see a value of 1, Credential Guard is active.

Should I disable Credential Guard to fix Wi-Fi issues?

Disabling Credential Guard is a temporary workaround, not a long-term solution. It restores PEAP-MSCHAPv2 SSO but also removes protection against pass-the-hash and credential dumping attacks. The recommended fix is to migrate to EAP-TLS certificate-based authentication, which works with Credential Guard enabled.

What is the difference between Credential Guard and Remote Credential Guard?

Credential Guard protects locally stored credentials (NTLM hashes, Kerberos TGTs) using virtualization-based security. Remote Credential Guard protects credentials during Remote Desktop sessions by keeping them on the source device rather than sending them to the remote host. Both are part of the Windows Defender security suite, but they address different scenarios.

What is the difference between LSA and Credential Guard?

A Local Security Authority (LSA) is a system to manage Windows security policies and authentication on local devices, typically executed by a Local Security Authority Subsystem Service (LSASS). Credential Guard is an organization-wide security tool that places credentials in a virtual protected environment (container), stored separately from the operating system, to prevent credential theft. Credential Guard works together with the LSA system to protect against code injection and keep credentials safe.

Can I use Credential Guard with PEAP-TLS?

Yes. PEAP-TLS uses certificate-based authentication inside the PEAP tunnel, so it does not rely on cached password credentials. Credential Guard does not block it. However, most organizations deploying certificates choose EAP-TLS directly, as the additional PEAP wrapper adds overhead without significant benefit when both sides present certificates.