MSCHAPv2 Security Risks and Alternatives

Organizations need wired and wireless (Wi-Fi) connections to perform important business functions, but these connections are susceptible to various ever-evolving cyber threats.

As a result, many ways to protect networks exist, including authentication protocols such as MSCHAPv2, EAP-MSCHAPv2, and PEAP-MSCHAPv2, along with EAP-TTLS/PAP and EAP-TLS.

PEAP-MSCHAPv2 (a combination of the Protected Extensible Authentication Protocol and the Microsoft Challenge Handshake Authentication Protocol Version 2) remains a standard method of securing networks. However, PEAP security becomes increasingly unreliable by the year.

In this analysis, we’ll explore MSCHAPv2 and the popular combined protocols EAP-MSCHAPv2 and PEAP-MSCHAPv2, how they work and the most modern threats to these authentication protocols. We’ll also share why EAP-TLS is the best alternative to all forms of MSCHAPv2.

What Is MSCHAPv2 and What Is It Used For?

MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol Version 2) is a challenge-response network security method developed by Microsoft to verify a user’s Active Directory (AD) credentials before granting access to network environments.

The authenticator devises a random challenge and delivers it to the client, who responds with their password and a hashed value — a one-way function that proves the validity of the password without revealing it. The server uses that response to determine whether to grant access.

This password-based authentication method uses only credentials, not device information. MSCHAP vulnerabilities are easy to exploit because shared or stolen credentials can be used to gain network access.

MSCHAPv2 is typically used for virtual private network (VPN) connections. It’s a familiar protocol, but there are many more secure alternatives.

What Is EAP-MSCHAPv2 and What Is It Used For?

EAP-MSCHAPv2 (Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol Version 2) is a combined protocol that secures MSCHAPv2 with EAP’s stronger hashing algorithms for additional protection.

Unlike solo MSCHAPv2, EAP-MSCHAPv2 supports optional mutual authentication to verify both the client and server identities. It also produces a distinct session key used to encrypt future communications for secure confidentiality.

EAP-MSCHAPv2 is often used for Wi-Fi networks (especially WPA2-Enterprise environments), VPN connections, wired networks, and remote access.

However, much like standalone MSCHAPv2, it’s not the modern standard due to security limitations: it’s a password-based authentication protocol prone to credential theft and attacks.

What Is PEAP-MSCHAPv2 and What Is It Used For?

PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol Version 2) is a password-based authentication method that uses a challenge-response handshake, optional mutual authentication and a Transport Layer Security (TLS) tunnel to encrypt client-server communications.

What distinguishes PEAP-MSCHAPv2 from MSCHAPv2 or EAP-MSCHAPv2 is the encrypted tunnel. PEAP-MSCHAPv2 automatically encrypts all communications before, during and after authentication.

PEAP-MSCHAPv2 is commonly used for Wi-Fi, wired, and VPN connections. However, mutual authentication is optional with this protocol, and it is password-based.

So, despite the security of strong hashing algorithms and an encrypted TLS tunnel, PEAP-MSCHAPv2 is not the recommended authentication method for secure enterprise deployments. But it is still commonly used today.

How PEAP-MSCHAPv2 Works

PEAP-MSCHAPv2 aims to secure user authentication by encrypting the credentials sent within the PEAP tunnel, where it performs the “handshake” with the corresponding Remote Authentication Dial-In User Service (RADIUS) server to begin the actual authentication process.

Authentication begins when a client connects to the network via username and credentials. It follows these steps:

1. Encrypted tunnel: PEAP creates an encrypted tunnel, and MSCHAPv2 verifies the user’s password through a challenge-response handshake.
2. Certificate validation: Working at the Transport Layer, MSCHAPv2 concurrently authenticates both the client and server certificates while keeping the user’s password “blank” to maintain security. The server certificate validation confirms that the user connects to the correct server.
3. Challenge-Response authentication: MSCHAPv2 presents a challenge-response that the user must complete for the server. After the server verifies the user’s response, it grants the user access to the network.

This authentication process has been highly secure for the most part, which is why so many organizations have implemented it. Unfortunately, this authentication method has a growing number of software issues and other vulnerabilities.

Is PEAP-MSCHAPv2 Secure?

PEAP-MSCHAPv2 is more secure than MSCHAPv2 alone. That’s because it employs stronger hashing algorithms and uses a TLS tunnel to encrypt communication between the client and authentication server.

However, it is still a password-based authentication method. Even with encryption during authentication, credentials remain vulnerable to brute-force attacks, dictionary attacks, phishing and more.

Mutual authentication is optional with PEAP-MSCHAPv2, creating additional vulnerabilities if attackers spoof servers.

But if no form of MSCHAPv2 is secure, what are the alternatives? Let’s compare PEAP-MSCHAPv2 to other types of EAP.

PEAP-MSCHAPv2 vs. Other Extensible Authentication Protocols

EAP has many variations, but the types we see most often are PEAP-MSCHAPv2, EAP-TTLS/PAP, and EAP-TLS.

The table below takes you through a quick comparison of these.

Except for EAP-TLS, the most common EAP methods rely on passwords rather than certificates for authentication. They can also be slower, offer weaker credential protection, and depend on specific directory services. For example, PEAP-MSCHAPv2 relies on Active Directory, while EAP-TTLS/PAP is often slower than other authentication methods.

When it comes to EAP vs. PEAP, PEAP-MSCHAPv2 is an obsolete option for modern enterprise deployments. Compared to the alternatives, its vulnerabilities leave your organization exposed.

Vulnerabilities That Impact PEAP-MSCHAPv2 in 2026 & Beyond

Despite its encrypted authentication process, PEAP-MSCHAPv2 remains vulnerable to modern attacks and configuration issues.

The following sections examine some of the most significant risks organizations should consider in 2026 and beyond.

Windows Credential Guard Issues With PEAP-MSCHAPv2

PEAP-MSCHAPv2 and Windows Credential Guard can cause security and organizational productivity issues. Users still face authentication vulnerabilities despite the tunnel encryption and challenge-response security implementations.

SecureW2 investigated the issue to determine whether using PEAP-MSCHAPv2 and Windows Credential Guard was a true error in a sandbox environment.

The main issue is that Windows Credential Guard doesn’t allow users to save PEAP credentials, so end-users must manually enter their credentials for each authentication. Each time you send credentials over the air in this way, you expose them to various attack scenarios.

One example of an attack that could exploit this vulnerability is an evil twin attack. In this scenario, attackers can imitate a trusted access point (AP) from their device and position themselves near a public place where people might connect to the false SSID, such as a college campus.

A student whose device has not been appropriately configured for the school’s legitimate SSID will connect automatically to the nearby imitation SSID and attempt to auto-authenticate with the attacker’s spoofed network. In doing so, it sends encrypted packets containing the user’s password to the attacker’s computer.

Because of a weakness in the MD4 hashing algorithm used by PEAP-MSCHAPv2, the attacker can easily decrypt the packets containing the user’s login credentials.

Since many people reuse passwords across multiple accounts, the hacker has likely gained access to more than just the fictional student’s school Wi-Fi credentials.

Wi-Fi Authentication Bypass Vulnerability for Android & ChromeOS Devices

The National Institute of Standards and Technology (NIST) discovered a new vulnerability affecting networks that use PEAP-MSCHAPv2. The vulnerability can lead to authentication bypass attacks on WPA2 and WPA3 networks in Enterprise mode with a misconfigured server certificate.

It explicitly impacts the following types of devices and systems:

• Intel’s iNet Wireless Daemon (IWD)
• WPA_supplicants on ChromeOS devices
• WPA_supplicants on Android devices
• Linux distributions using a default Wi-Fi client

For Android devices, 802.1X configuration can be a bit more time-consuming because users must manually configure network settings to trust server certificates.

There are currently no alternative methods of configuration, and Android users may need to wait a while before a security patch is available to address the issue with wpa_supplicants.

Linux devices running older versions of IWD may put home networks at risk, while vulnerabilities affecting wpa_supplicant can put enterprise networks at risk. Because this article focuses on enterprise security, we'll concentrate on how these vulnerabilities affect enterprise networks.

As with the previous vulnerability, attackers can use an evil twin strategy to exploit this weakness. They create a spoofed network that resembles a legitimate network and trick users into connecting their devices to it.

The vulnerability occurs when a device running a vulnerable version of wpa_supplicant uses PEAP without properly validating the authentication server's TLS certificate. During the PEAP handshake, the supplicant may accept the spoofed network as legitimate because it doesn't verify the server certificate's authenticity. This can allow an attacker to bypass network authentication and gain unauthorized access.

The level of access an attacker gains depends on the vulnerability and the network's security controls. If they gain access using compromised user credentials, they may also attempt to escalate their privileges to reach additional network resources.

Security Standards Are Driving the Move Away From PEAP-MSCHAPv2

For many years, security researchers have warned about the weaknesses of PEAP-MSCHAPv2. The protocol is vulnerable to password-based attacks, does not provide forward secrecy and often depends on users correctly validating the server certificate.

These concerns are no longer just security recommendations. They are increasingly reflected in operating system behavior, government guidance, and industry standards.

Windows Credential Guard Is Changing Authentication Requirements

One example is Microsoft Windows 11. Windows Defender Credential Guard is enabled by default on many Windows 11 Enterprise and Education devices. Credential Guard protects NTLM password hashes by isolating them from the operating system.

Because PEAP-MSCHAPv2 depends on these password hashes for authentication, users may experience repeated credential prompts or failed Wi-Fi authentication. This behavior is intentional and is designed to better protect user credentials.

NIST Guidance Is Driving the Shift Toward Certificate-Based Authentication

Government guidance is also moving toward stronger authentication methods.

In November 2024, NIST published IR 8547, which outlines the transition to post-quantum cryptography. The guidance explains how organizations should prepare to replace today’s public key algorithms with quantum-resistant alternatives over the coming years.

Certificate-based authentication is well positioned for this transition because organizations can adopt new cryptographic algorithms by updating their public key infrastructure (PKI). EAP-TLS can evolve alongside these changes as new certificates and algorithms become available.

PEAP-MSCHAPv2 does not have the same path forward. It is based on password authentication rather than certificates, so it cannot benefit from the same cryptographic upgrades.

As organizations modernize their authentication infrastructure, password-based methods become increasingly difficult to support alongside newer security requirements.

Combined with recent updates to RADIUS security and the growing adoption of certificate-based authentication, these changes signal a clear industry direction.

Organizations planning for the future should evaluate whether PEAP-MSCHAPv2 still meets their security and operational needs or whether it is time to migrate to EAP-TLS and a certificate-based authentication model.

Protecting Your Organization’s Network from PEAP-MSCHAPv2 Vulnerabilities

While PEAP-MSCHAPv2 deployments can be made more secure through proper configuration, they still inherit the limitations of password-based authentication.

Organizations can reduce their risk by enforcing server certificate validation and, where possible, migrating to certificate-based authentication with EAP-TLS.

Enforce Server Certificate Validation on Every Device

By checking the authentication server’s certificate, server certificate validation is verifying you are connecting to the correct network. This prevents evil twin attacks from occurring and provides enhanced security.

Setting up server certificate validation is device-specific and difficult for many users to configure independently. Relying on end-users to manually configure their devices poses a security risk because users tend to miss steps and accidentally trust rogue networks.

Using auto-configuration technology such as JoinNow MultiOS to automate the process saves time for your administrators and saves you end-users the headache of configuration for their BYODs.

JoinNow correctly configures the device to check for specified certificates to verify that the device is connected to the trusted network.

Consider Using More Secure Authentication Protocols Like EAP-TLS

EAP-TLS is a certificate-based authentication protocol that does not require a password to authenticate securely to the network. Instead, both clients and authentication servers use digital certificates.

Because it’s passwordless, EAP-TLS is inherently more secure than password-based authentication.

“Using certificates instead of passwords gives you phishing-resistant authentication. It prevents over-the-air credential theft, like an evil twin attack or an adversary-in-the-middle attack. That’s a big reason PKI exists.” Micah Spady, Director of Product Marketing at SecureW2

Once configured, EAP-TLS is also easier for the end user because they no longer need to type in passwords repeatedly, deal with disconnects when their passwords expire or develop complex new passwords.

This allows the organization to increase productivity and protects against network-based attacks because only devices enrolled with a certificate can access the network and the domain’s resources.

Learn more about implementing EAP-TLS in your organization by watching this video:

The main challenge to implementing EAP-TLS is establishing the PKI necessary to manage the certificate lifecycle.

Thankfully, more solutions, such as managed PKIs, are available today to make certificates accessible.

Make the Switch From PEAP Security to EAP-TLS With SecureW2

With increasingly complex attack vectors becoming available almost daily, credential-based authentication unnecessarily leaves your organization vulnerable. Switching from credential-based authentication to certificate-driven EAP-TLS doesn’t need to be challenging, either.

The SecureW2 passwordless platform gives you all the tools to implement certificates. We have a managed cloud PKI that can be deployed rapidly and onboarding technology to roll out certificates to your endpoints.

Our advanced gateway APIs can automatically enroll managed devices for certificates, while our self-service JoinNow MultiOS application can empower end-users to configure their unmanaged devices quickly.

Get a free demo and see how simple it can be to adopt secure certificate-based authentication.

---

Frequently Asked Questions

What is MS-CHAPv2 in Wi-Fi?

MSCHAPv2 stands for Microsoft Challenge Handshake Authentication Protocol Version 2; it's a password-based authentication method to verify users attempting to connect to a network, including wireless access points (Wi-Fi).

Organizations can also use MSCHAPv2 to authenticate wired connections, remote access, or VPNs. With the challenge-response handshake, the client sends a hashed password that protects the actual password during authentication.

What is the difference between MS-CHAP and MS-CHAPv2?

MSCHAP (Microsoft Challenge Handshake Authentication Protocol) and MSCHAPv2 (MSCHAP Version 2) use the same challenge-handshake protocol, but v2 employs a more advanced challenge and hashing algorithm. MSCHAP is rarely used today, but MSCHAPv2 isn't considered secure as a standalone protocol.

Today, most organizations employ PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol-MSCHAPv2), which uses an encrypted tunnel for end-to-end encryption during the authentication process.

What is the difference between EAP, PEAP, and MS-CHAPv2?

EAP (Extensible Authentication Protocol) and PEAP (Protected Extensible Authentication Protocol) are both external authentication methods commonly paired with the inner method MS-CHAPv2. MS-CHAPv2 is the challenge-response handshake that confirms the user's password. EAP adds stronger password hashing (obscuring the actual password) and the option for mutual authentication (server verifies client, client verifies server).

Alternately, PEAP includes the advantages of EAP plus a secure TLS tunnel for end-to-end encryption.

How does EAP-MSCHAPv2 work?

EAP-MSCHAPv2 works by establishing a client-server connection, then exchanging a challenge-response handshake to verify the user's password. The authenticator delivers a random challenge; the client sends a hashed response that confirms the password while maintaining its confidentiality.

Optionally, the client may send a random challenge to the server for mutual authentication. If all responses match, it's a successful authentication. Finally, both parties develop a session key to encrypt data transmitted between the server and authorized users.

Is PEAP-MSCHAPv2 encrypted?

Yes. PEAP-MSCHAPv2 uses a TLS tunnel to encrypt communications between the client and authentication server during authentication. However, this encryption doesn't eliminate the risks of password-based authentication. If an attacker steals a user's credentials or exploits improper server certificate validation, they may still gain unauthorized network access.