Why PEAP-MSCHAPv2 fails on Windows 11 and how to fix it

If Windows 11 computers stopped joining your corporate Wi-Fi after mid-October patching, or users suddenly started seeing credential prompts they never saw before, you're not alone. After the October 13, 2026 Windows security update, many domain-joined devices that use PEAP-MSCHAPv2 with their Windows logon can no longer sign in to Wi-Fi, wired 802.1X, or VPN automatically.

This is planned hardening from Microsoft. Microsoft announced the change in August 2025 as part of its effort to retire NTLM, and October's update switched it on by default for devices that hadn't been configured either way.

This guide explains what changed, which devices are affected, how to confirm the update is the cause, and how to get users reconnected today. It also covers the fix that holds up long term: moving network authentication from passwords to certificates with EAP-TLS.

What the October 2026 Windows update changed

Microsoft removed the NTLMv1 protocol from Windows 11 version 24H2 and Windows Server 2025. Some NTLMv1 cryptography still remains in certain scenarios, most notably: MS-CHAPv2, the inner method behind PEAP-MSCHAPv2 and EAP-MSCHAPv2, when it runs in a domain-joined environment.

A registry value called BlockNtlmv1SSO controls whether Windows allows those NTLMv1-derived credentials to be used for single sign-on. A value of 0 (Audit mode) allows the request and logs a warning. A value of 1 (Enforce mode) blocks it and logs an error.

Starting with the October 13, 2026 security update, Windows treats a missing BlockNtlmv1SSO value as Enforce mode. The update doesn't create or change the registry value. It changes what Windows does when the value isn't there, which is why so many fleets were caught off guard even though nothing in Group Policy or Intune changed.

Only the single sign-on path is blocked. Users who type their username and password at the prompt can still connect.

The rollout happened in stages. Audit events began appearing on Windows 11 24H2 and newer in late August 2025, the rollout reached Windows Server 2025 in November 2025, and Enforce became the default in October 2026. Microsoft added a note about the change to the KB5127648 release notes on October 15, two days after the update shipped, so admins who checked the notes on release day didn't find it there.

Windows Server 2025 received the same change in KB5126646, released the same day.

Who is affected (and who isn't)

A device is affected when all four of these conditions apply:

• It runs Windows 11 version 24H2 or later, or Windows Server 2025, with the October 2026 update installed.

• Credential Guard isn't running.

• The BlockNtlmv1SSO registry value hasn't been set.

• Its Wi-Fi, wired, or VPN profile uses MS-CHAPv2 with Windows logon single sign-on, as PEAP-MSCHAPv2 and EAP-MSCHAPv2 profiles typically do.

Devices with Credential Guard running were already in this position before October. Credential Guard blocks MS-CHAPv2 single sign-on on its own, and it has been on by default since Windows 11 version 22H2 for eligible devices on Enterprise and Education licenses and some Pro licenses. The registry value does nothing for those devices. Either way, PEAP single sign-on on managed Windows devices is coming to an end.

The block happens on the Windows device, before an authentication response ever reaches the RADIUS server. That's why RADIUS logs often show nothing useful during these failures, and why no server-side setting brings single sign-on back.

How to confirm the update is the cause

Before changing any settings, confirm the October update is what's blocking the connection. These checks take a few minutes on an affected device:

1. Check whether the update is installed. Go to Settings > Windows Update > Update history and look for KB5127648, or run winver and compare the build number to the table above.

2. Open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > NTLM > Operational.

3. Look for event ID 4025 (Error) at the time of the failed connection. Its text reads: "An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy."

4. Check the network profile. If it uses PEAP-MSCHAPv2 with "Automatically use my Windows logon name and password" selected, you've found the cause.

Event ID 4024 is worth checking too. It's the Audit mode warning in the same log, and on devices that haven't installed the October update yet, it marks the machines that will break when they do. Collecting 4024 and 4025 events across your fleet gives you an inventory of every device and profile that still depends on PEAP single sign-on, which you'll need for the migration later in this guide.

The short-term workaround, and why it's only temporary

There are a few ways to get users reconnected while you plan a lasting fix. Each one buys time and leaves the underlying dependency in place.

Set BlockNtlmv1SSO to 0

Setting BlockNtlmv1SSO to 0 explicitly puts the device back in Audit mode, which restores PEAP-MSCHAPv2 single sign-on while keeping the October security update installed. No restart is required.

At scale, deploy the value through a Group Policy Preferences registry item or an Intune remediation script. Plan a way to reach devices that are already off the network, such as a wired port, a guest network, or a typed-credential sign-in, since they can't receive policy until they reconnect. The setting has no effect on devices where Credential Guard is running.

Microsoft describes Audit mode as something that "should only be considered as a scoped, temporary security exception," because it reduces the protection Enforce mode provides. Scope it to the devices that need it, set an end date, and track it like any other open risk.

Have users type their credentials

Users can forget the saved network and reconnect by entering their username and password at the prompt. It works without any configuration change, but it adds friction for every user, doesn't help devices that need network access at the login screen, and keeps passwords in the network sign-in path.

Why uninstalling the update is a poor option

Uninstalling KB5127648 restores the old default, but it also removes the month's security fixes. Later cumulative updates carry the same change, so the problem returns the next time the device updates. Microsoft documents the registry value as the supported exception path.

Why MS-CHAPv2 is being retired, on Windows and beyond

The registry workaround keeps PEAP-MSCHAPv2 running, but the protocol it preserves has well-documented weaknesses, and pressure to retire it is coming from more than one direction.

The weaknesses behind the change

Microsoft's own guidance states that Wi-Fi and VPN endpoints based on MS-CHAPv2 are subject to attacks similar to those against NTLMv1. The main problems are well established:

• It relies on legacy password hashing. The MS-CHAPv2 response is built from an MD4 hash of the user's password using the same DES-based challenge-response design as NTLMv1, which is why Windows treats it as an NTLMv1-derived credential.

• It was publicly broken in 2012. At DEF CON 20, researchers Moxie Marlinspike and David Hulton showed that a captured MS-CHAPv2 exchange can be reduced to cracking a single 56-bit DES key, with a 100% success rate regardless of password strength.

• Its protection depends on every client being configured correctly. PEAP wraps MS-CHAPv2 in a TLS tunnel, but only clients that validate the RADIUS server certificate get that protection. A client that skips validation can be tricked into authenticating to an evil twin access point that captures the exchange.

• It's still a password. Passwords can be phished, shared, and reused, and every reset or expiry can knock a device off the network until the user signs in again.

The protocol itself is next

Microsoft is restricting MS-CHAPv2 on the client side. The standards body that maintains RADIUS is working on the protocol side.

The IETF RADEXT working group's current draft, "Deprecating Insecure Practices in RADIUS," includes a section that formally deprecates MS-CHAP. The same draft deprecates RADIUS over UDP and TCP outside of secure networks and calls for secure transports such as RadSec (RADIUS over TLS). It's still a work in progress, but it shows where RADIUS security standards are heading. For background on the transport side, see our comparison of RADIUS vs RadSec.

Setting BlockNtlmv1SSO to 0 addresses neither trend. Moving off MS-CHAPv2 addresses both.

The permanent fix: move Windows devices to EAP-TLS

Microsoft recommends moving Wi-Fi and VPN connections from MS-CHAPv2 to certificate-based authentication, such as EAP-TLS or PEAP-TLS. For most organizations, EAP-TLS is the most direct path.

Why EAP-TLS isn't affected

EAP-TLS authenticates the device or user with a certificate and private key. No password is involved, and Windows doesn't need a saved logon credential, so the BlockNtlmv1SSO change never applies. Credential Guard doesn't block certificate-based authentication either.

The move also solves problems that PEAP-MSCHAPv2 has always had:

• There's no password to phish, crack offline, or capture with an evil twin access point.

• A device certificate lets a laptop connect at the login screen, before anyone signs in.

• Password resets and expirations no longer disconnect devices from Wi-Fi.

• The same certificate-based approach works for Wi-Fi, wired 802.1X, and VPN.

How to migrate without downtime

PEAP and EAP-TLS can run side by side during the transition, so devices can move in groups instead of all at once. These steps work with any identity provider and any MDM platform:

1. Build an inventory. Use the 4024 and 4025 events to list affected devices and the network profiles they use. Separate company-managed devices from personal and unmanaged ones, since they'll receive certificates differently.

2. Decide how certificates will be issued. An on-premises certificate authority such as Active Directory Certificate Services is one option. A cloud-hosted certificate authority removes the need to run that infrastructure yourself.

3. Deliver certificates to managed devices. Use your MDM's SCEP certificate profile, whether that's Microsoft Intune, Jamf, Workspace ONE, Kandji, or Google Admin for Chromebooks.

4. Give unmanaged and BYOD devices a self-service path. An enrollment flow that installs the certificate and network profile lets users onboard their own devices without an IT ticket.

5. Configure your RADIUS server to accept EAP-TLS alongside PEAP during the transition.

6. Push an EAP-TLS network profile. Configure it to validate the RADIUS server certificate by trusted root and server name.

7. Pilot with one team or site. Confirm devices connect at the login screen and stay connected after a password change.

8. Roll out in waves by department, location, or device group.

9. Retire PEAP. Remove the old profile from devices, delete any BlockNtlmv1SSO exceptions, and disable MS-CHAPv2 on the RADIUS server.

Macs, phones, and Chromebooks aren't affected by the October update, but if your goal is to retire PEAP on the network entirely, they'll need certificates too. Our guide to certificate-based Wi-Fi for managed Chromebooks covers the ChromeOS side.

How Foxpass helps you get off PEAP-MSCHAPv2

Foxpass, from Splashtop, provides cloud-hosted RADIUS authentication for Wi-Fi, VPN, and wired networks, along with a cloud PKI for issuing device and user certificates. Together, Foxpass Cloud RADIUS and Foxpass Cloud PKI cover each stage of the migration above without on-premises servers to build or maintain.

• Certificate issuance without on-premises infrastructure: Foxpass Cloud PKI acts as your certificate authority, and Foxpass Cloud RADIUS validates the certificate on every connection attempt.

• Certificate delivery through the MDM you already use: Managed devices receive certificates through the Foxpass SCEP endpoint from Microsoft Intune, Jamf, Kandji, Addigy, Workspace ONE, Mosyle, NinjaOne, and Google Admin for Chromebooks. Teams that manage Windows endpoints with Splashtop AEM can deliver certificates through Splashtop AEM as well.

• Access tied to the identity provider you already use: Foxpass syncs users and groups from Microsoft Entra ID, Google Workspace, Okta, and OneLogin, so network access follows the same directory as everything else. We cover the Okta and Google Workspace side in more detail in certificate-based authentication for Okta and Google Workspace.

• A self-service path for BYOD and unmanaged devices: The Foxpass BYOD Certificate Installer lets users enroll Mac, Windows, iOS, Android, and Chromebook devices themselves.

• Access that ends when someone leaves: Because a certificate can carry the user's email address or device ID, Foxpass can confirm at connection time that the user or device is still active in your directory.

• A phased cutover: Foxpass Cloud RADIUS supports EAP-TLS and EAP-TTLS side by side, so you can move devices to certificates in waves.

• Encrypted RADIUS traffic: Foxpass supports RadSec, which protects authentication traffic between your access points and the RADIUS server with TLS.

Learn more about passwordless Wi-Fi and VPN access with Foxpass.

Retire PEAP for good with certificate-based Wi-Fi

The BlockNtlmv1SSO setting can get Windows 11 users back online today, but it keeps your network sign-in tied to a protocol that Microsoft recommends moving away from, and the IETF is moving to deprecate at the protocol level. Certificate-based authentication removes that dependency, so future Windows hardening doesn't turn into another wave of Wi-Fi tickets.

Foxpass Cloud RADIUS and Foxpass Cloud PKI let you make that move with the identity provider and MDM you already run. Start a free trial or schedule a demo to see how Foxpass fits your environment.