Wi-Fi or VPN Won’t Connect After KB5127648: MS-CHAPv2 Fix

Office Wi-Fi or VPN stopped signing in after the October update? Windows now blocks the old login method MS-CHAPv2 relies on.

If company Wi-Fi, wired 802.1X or VPN stopped signing in automatically after the October 13, 2026 Windows update, Windows is now blocking the single sign-on that MS-CHAPv2 depends on. Users can still connect by typing their username and password when prompted. The lasting fix is moving those connections to certificate-based PEAP-TLS or EAP-TLS.

MS-CHAPv2 is an older login method many office Wi-Fi networks and VPNs still use, usually as PEAP-MSCHAPv2 against a Windows NPS or RADIUS server. It relies on leftover NTLMv1 cryptography, and Microsoft’s October security update, KB5127648 on Windows 11, turned the block on that by default.

What Changed in the October Update

Microsoft added a registry value called BlockNtlmv1SSO in August 2025 and ran it in audit mode, logging a warning but letting the sign-in through. Starting with the October 13, 2026 security update, a device with no BlockNtlmv1SSO value behaves as if it were set to 1, which is enforce mode. Windows blocks the request to build NTLMv1-derived credentials for single sign-on.

The update does not create the registry value, so looking for it in the registry will not tell you the mode. Absent now means enforce.

Three things decide whether a machine is affected. It runs Windows 11 24H2 or later, or Windows Server 2025. Credential Guard is off. The network or VPN profile uses PEAP-MSCHAPv2 or EAP-MSCHAPv2 with saved Windows credentials.

Confirm It in Event Viewer

On an affected laptop, open Event Viewer and go to Applications and Services Logs, Microsoft, Windows, NTLM, Operational. Event ID 4025 with the text “An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy” is the smoking gun. Event 4024 is the older audit warning and means the device was still in audit mode at that time.

This pulls the recent ones from PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 200 |
  Where-Object Id -in 4024, 4025 |
  Select-Object TimeCreated, Id, Message -First 10

To see the registry value, if anyone has set it:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue

No output means the value is absent, which after the October update means enforce.

Get Users Connected Today

Manual sign-in still works in enforce mode. When the Wi-Fi or VPN prompt appears, have the user enter their domain username and password instead of relying on the saved Windows sign-in. That keeps people working while you fix the network side.

If a critical connection cannot wait, Microsoft allows setting BlockNtlmv1SSO to 0 as a scoped, temporary exception. Run this from an elevated prompt on the affected device. No restart is needed:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Treat that as a stopgap only. Audit mode puts back the weak cryptography Microsoft is removing, and Microsoft describes it as a temporary exception while you migrate. Push it through Group Policy Preferences or Intune to a named group of devices, never the whole fleet, and set a date to remove it.

The Real Fix: Certificate-Based Authentication

Microsoft’s recommendation is to move Wi-Fi and VPN from PEAP-MSCHAPv2 or EAP-MSCHAPv2 to certificate-based authentication, either PEAP-TLS or EAP-TLS. Devices authenticate with a certificate instead of a password hash, so NTLMv1 never comes into it, and stolen passwords stop being enough to join the network.

That means three pieces: a certificate authority that issues device or user certificates, a way to deploy them such as Group Policy auto-enrollment or an Intune certificate profile, and NPS or RADIUS network policies changed to accept EAP-TLS. Run both methods side by side on the server while certificates roll out, then remove MS-CHAPv2 once every device has one.

Turning on Credential Guard does not fix Wi-Fi on its own. With Credential Guard on, the October change does not apply, but Credential Guard already blocks MS-CHAPv2 single sign-on, so users get the same password prompt.

Who Should Care

If your office Wi-Fi uses a shared password, often labeled WPA2-Personal or WPA3-Personal, none of this applies. The change only hits networks where each person signs in with their work account, which is common in offices with a Windows server and in many VPN setups. If staff suddenly see a Wi-Fi or VPN password prompt they never saw before, forward this to whoever manages your network.

This change is one of several in October’s updates. The rest are in our October 2026 Patch Tuesday known issues roundup.