The October 13, 2026 Windows security update (KB5127648 on Windows 11 24H2, 25H2 and 26H2) silently flipped a default that PEAP-MSCHAPv2 has quietly depended on for twenty years. Wi-Fi and wired 802.1X single sign-on now fails on patched clients. Here is what happened, the registry workaround that buys you time, and why the real fix is certificates: EAP-TLS, or TEAP with EAP-TLS inside.
Starting Tuesday evening, Windows 11 devices that installed KB5127648 (OS builds 26100.9711, 26200.9711 and 26300.9711) stopped authenticating to WPA2-Enterprise Wi-Fi and wired 802.1X networks that use PEAP with MS-CHAPv2 and "Use my Windows user account" (domain SSO). Microsoft Q&A, Spiceworks and vendor knowledge bases filled up within hours.
The symptoms are consistent across every report we have seen:
wusa /uninstall /kb:5127648) restores authentication; reinstalling it reproduces the failure.Microsoft's October release notes do not list this as a known issue, and there is no fix coming, because from Microsoft's side it is not a bug.
In August 2025 Microsoft published "Upcoming changes to NTLMv1 in Windows 11 version 24H2 and Windows Server 2025" (KB5066470). Windows had already removed the NTLMv1 protocol, but NTLMv1-derived cryptography survived in one place: the MS-CHAPv2 exchange that PEAP and EAP-MSCHAPv2 use when the supplicant signs on with the logged-on user's Windows credentials. Microsoft gave the plan a timeline:
BlockNtlmv1SSO registry value from Audit (0) to Enforce (1), when the value has never been set. In Enforce mode the SSO request is blocked and logged as event 4025.That is exactly what KB5127648 did. The update did not create or change a registry value on your machines; it changed what Windows does when the value is absent. Nearly every enterprise fleet never set it, so nearly every enterprise fleet went to Enforce on Tuesday night.
Two groups did not notice. Devices with Credential Guard enabled have blocked MS-CHAPv2 SSO since Windows 11 22H2, so those organizations already moved or already typed credentials. And anyone already on EAP-TLS or TEAP with certificates never used the MS-CHAPv2 path at all. That second group is where you want to be.
Before you open a TAC case or blame the wireless controller, check the client. The signature is unmistakable.
On an affected device, open Event Viewer and look at Applications and Services Logs → Microsoft → Windows → NTLM → Operational. An event 4025 at the moment of each failed 802.1X attempt is the confirmation: Windows itself refused to hand the supplicant an NTLMv1-derived credential. If you see 4024 instead, that device is still in Audit mode (either unpatched or already carrying the workaround) and the failure is something else.
Microsoft's own guidance allows a scoped, temporary exception: explicitly set the value the update left undefined. Because you are setting it yourself, the new default no longer applies.
| Key | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 |
| Value name | BlockNtlmv1SSO |
| Type | REG_DWORD |
| Data | 0 (Audit mode: allowed and logged as event 4024) — the default now behaves as 1 (Enforce) |
| Reboot | Not required |
From an elevated prompt on a single machine:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /fAt fleet scale, push it the way you push everything else: a Group Policy Preferences registry item (Computer Configuration → Preferences → Windows Settings → Registry) scoped to the OUs that still use PEAP, or an Intune remediation script for Entra-joined devices. Target only the devices that need it, so your audit trail stays honest about who is still on MS-CHAPv2.
Three caveats, because this is a workaround and not a fix:
Do not uninstall KB5127648 to get around this. It is a cumulative security update, and the registry value gets you the same result without giving up October's fixes.
PEAP-MSCHAPv2 has been on borrowed time for years. It depends on users validating a server certificate they do not understand, it hands a password-derived response to anyone who can stand up a convincing evil twin, and it is now fighting the operating system it runs on. The October update is the push most organizations needed to finish a migration they already knew they owed.
EAP-TLS authenticates with an X.509 certificate instead of a password. There is no inner method, no MS-CHAPv2 and no NTLM anywhere in the exchange, so nothing in the October change can touch it. It is supported by every Windows supplicant you have, every Cisco ISE release you are running, and every switch and wireless controller on your network. If you have a PKI (Active Directory Certificate Services or a cloud CA) and a way to auto-enroll certificates (Group Policy for domain-joined devices, Intune SCEP or PKCS for Entra-joined devices), you have everything EAP-TLS needs.
TEAP (RFC 7170) is a TLS tunnel that carries one or more inner EAP methods and, crucially, supports EAP chaining: the machine certificate and the user certificate are both presented in a single authentication, and ISE sees both identities in one session. That lets you write the policy everyone actually wants, "this domain user on this corporate-owned device," without the awkward machine-access-restriction workarounds that plain EAP-TLS needs. The native Windows supplicant has supported TEAP since Windows 10 2004, and Cisco ISE has supported it since 2.7.
One rule: the inner method must be EAP-TLS. TEAP with an EAP-MSCHAPv2 inner method carries the same NTLM dependency as PEAP and breaks the same way. If you are going to the trouble of deploying TEAP, go all the way to certificates for both legs.
BlockNtlmv1SSO override, and let the devices return to Enforce, which is where Microsoft wants them and where you want them.For a typical mid-size enterprise with a working PKI, this is a four-to-eight-week project. Without a PKI it is longer, and the certificate work is the part worth getting help on.
ModernCyber has been moving customers from PEAP to EAP-TLS and TEAP on Cisco ISE for years; the October update just put a date on it. If you want a second set of eyes on your plan, help with the ISE policy and certificate design, or someone to run the migration end to end, book time with one of our ISE engineers.
Schedule time with ModernCyber →
And if the thing keeping you on PEAP is that nobody has time to own ISE, that is a different conversation: ModernISE Platform is Cisco ISE delivered as a managed service, and certificate-based authentication is how we build every one of them.
Sources