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 of protecting networks exist, including using 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 used 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.

Developed by Microsoft, this password-based authentication method works with credentials only not device information. It’s easy to exploit MSCHAP vulnerabilities since 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 encrypts 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’s 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’s still commonly used today.

How PEAP-MSCHAPv2 Works

PEAP-MSCHAPv2 is a network security protocol that combines the PEAP-TLS protocol and Microsoft Challenge Handshake Authentication Protocol Version 2. It aims to secure user authentication by encrypting the credentials sent within the PEAP tunnel, where it performs the “handshake” with the corresponding 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. The PEAP protocol creates an encrypted tunnel, and MSCHAPv2 verifies the user’s password through a challenge handshake response mechanism.
2. Working at the Transport Layer, MSCHAPv2 concurrently authenticates both the client and server certificate while keeping the user’s password “blank” to maintain security. The server certificate validation confirms that the user connects to the correct server.
3. 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. 

The image below shows how PEAP works.

Is PEAP-MSCHAPv2 Encrypted?

Thanks to the encrypted TLS tunnel provided by Protected Extensible Authentication Protocol (PEAP), PEAP-MSCHAPv2 includes encryption. This protects the confidentiality of authentication credentials (usernames and passwords) during network communications.

When a user attempts to authenticate, the network authentication server and client create an encrypted tunnel for communication. Then, the authenticator sends a challenge to the client. The client responds with a hashed value that securely communicates knowledge of the valid password.

However, if a user shares their credentials, or if a bad actor discovers or steals them, this authentication process encryption can’t protect the user or network. Bad actors could still connect with the user’s password and username unless the organization employs additional device verification strategies.

Is PEAP-MSCHAPv2 Secure?

PEAP-MSCHAPv2 is more secure than MSCHAPv2 alone. That’s because it uses a secure tunnel for client-server communications and employs stronger hashing algorithms.

However, it’s still a password-based authentication method. Regardless of encryption during authentication, credentials are vulnerable to brute-force attacks, dictionary attacks, phishing, and more.

Plus, 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

There are numerous variations of EAP, 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.

WPA2 & WPA3 Enterprise Common Protocols	Level of Encryption	Authentication Speed	Directory Speed	Credentials
EAP-TLS	Public-private cryptography	Fast – 12 steps	Universal	Passwordless
PEAP-MSCHAVPv2	Bad encryption (MD4, compromised since 1995)	Slow – 22 steps	Active Directory	Passwords
EAP-TTLS/PAP	No credential encryption	Slowest – 25 steps	Non-AD LDAP servers	Passwords

Except for EAP-TLS, all the most common EAP methods we listed above rely on passwords for authentication. They’re also slow (especially EAP-TTLS), poorly encrypted (or totally unencrypted), and reliant on specific directory types, or in the case of PEAP-MSCHAPv2, just one directory (Active Directory).

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 a scenario that could exploit this vulnerability is an evil twin AP attack. In this scenario, attackers can imitate a trusted access point 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 impacts explicitly 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 that carry older versions of IWD put their home network at risk, while wpa_supplicants put enterprise networks at risk. Because this article focuses more on enterprise networks, we’ll limit our discussion to how home networks are impacted and discuss the threat to enterprise networks in more detail. 

The hacker will use the evil twin strategy we discussed to carry out the authentication bypass attacks. This is done by tricking the victim into connecting their device to a spoofed network that resembles the name of a legitimate network. From then on, they can see what credentials were used to login to that spoofed network and begin infiltrating it.

When exploiting wpa_supplicant vulnerabilities, the attacker will have limited access depending upon the user credentials they have stolen and will look to start privilege escalation to attain their goal.

For wpa_supplicants implementing PEAP to be compromised, the device must be configured not to require verification of the authentication server’s TLS certificate.

During the PEAP handshake, the supplicant will connect to the spoof network because it is not correctly configured to validate the server certificate’s authenticity. 

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.

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

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.

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 AP attacks from occurring and provides enhanced security.

Unfortunately, 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, digital certificates are used by both clients and authentication servers.

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

Once configured, it’s 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 grants protection from network-based attacks because only devices enrolled with a certificate can access the network and domain’s resources.

The main challenge to implementing EAP-TLS is establishing the Public Key Infrastructure (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 virtual private networks (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 inner method MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol Version 2). 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 transport layer security (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.