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. Credential Guard blocks PEAP-MSCHAPv2, 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 — NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and domain credentials stored in Credential Manager — 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 OS, it cannot extract credential material from LSASS memory.

What Credential Guard Protects 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.

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
• 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 Wi-Fi and VPN 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.

2. 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).
3. 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 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.

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.