Businesses applying Windows 11's October update KB5127648 have lost connectivity on Wi-Fi and wired networks using 802.1X authentication. The cause is a switch in the default NTLMv1 blocking setting to Enforce; a registry change restores connectivity but only buys time.
Key points
- What happened: After KB5127648 was applied, single sign-on stopped working on enterprise Wi-Fi and wired networks using 802.1X PEAP authentication, prompting more than 90 reports on Microsoft Q&A
- Why it happened: The default NTLMv1 blocking change Microsoft announced in August 2025, from Audit to Enforce, took effect with KB5127648, rejecting MS-CHAPv2-based SSO credentials
- Response and limits: Returning the BlockNtlmv1SSO registry value to 0 restores operation for now, but the plan to retire NTLMv1 remains in place, giving preparations to migrate to options such as EAP-TLS a practical deadline
802.1X networks cannot authenticate after KB5127648
Reports have been appearing in Microsoft's Q&A forums that authentication fails to complete in WPA2-Enterprise environments immediately after applying Windows 11 monthly security update KB5127648, released on October 13, local time. The update covers builds 26300.9711 / 26200.9711 / 26100.9711 for versions 26H2, 25H2, and 24H2. WPA2-Enterprise uses 802.1X/PEAP to authenticate individual devices or users in businesses and universities.
According to the first reporter, authentication begins but stops at Event 12014 (OneX Held State timeout), preventing a network connection. WPA2-Personal is unaffected, and the issue reproduces across wireless chipsets from multiple vendors, including Intel and Qualcomm. Reports indicate that wired LAN 802.1X authentication also stops working, not just Wi-Fi.
The thread has received more than 90 "Same question" responses, showing a global impact that includes administrators in Chinese-speaking regions. Multiple administrators have also independently verified the reproduction steps: uninstalling KB5127648 immediately restores connectivity, and reinstalling it brings the problem back.
Joho no Todai confirmed that, at the time of writing, Microsoft has not listed any known issue involving 802.1X or PEAP in the KB5127648 release notes. An independent community adviser has also pointed out the absence of a corresponding entry on the official release health page.
A previously announced NTLMv1 retirement change took effect in a monthly update
Why did only 802.1X authentication break? The workaround provides a clue.
The first fix shared in the forum was the following registry change.
Under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, create a 32-bit DWORD value namedBlockNtlmv1SSOand set it to0
More than 40 people marked this answer as helpful, and some reported deploying it across multiple devices through Group Policy.
This registry key is described in documentation Microsoft published in August 2025. In that document, Microsoft lays out a roadmap for phasing out cryptography derived from NTLMv1.
The roadmap's key points are as follows. Windows 11 24H2 and later removed the NTLMv1 protocol itself, but NTLMv1-derived credentials remained in single sign-on for MS-CHAPv2 authentication on Wi-Fi, wired networks, and VPNs. The September 2025 updates first introduced Audit mode, recording an event whenever these credentials were used. Microsoft then announced that the October 2026 updates would change the default from Audit (0) to Enforce (1).
KB5127648 arrived in precisely that month: October 2026.
Enforce mode rejects single sign-on using NTLMv1-derived credentials. Microsoft's official documentation explicitly states that, in this case, "single sign-on using MS-CHAPv2 authentication for Wi-Fi, wired LAN, and VPN connections will stop working, but authentication will succeed if credentials are entered manually".
Detailed testing reported in the forum also matched this behavior. Authentication fails with "Use Windows user account" checked (WLAN-AutoConfig Event 12013, Error 0x80070285), but succeeds when it is unchecked and "domain\username" and a password are entered manually. The reporter verified that the BlockNtlmv1SSO registry value was unset both before and after the update.
In other words, if KB5127648 switched the default to Enforce on devices where the registry value had not been set manually, both the symptoms and the workaround are consistent with Microsoft's documentation.
The registry workaround works, but only buys time
Setting BlockNtlmv1SSO back to 0 restores authentication. In environments managing multiple devices, deployment through Group Policy is a practical response.
However, this explicitly continues to allow the NTLMv1-derived authentication Microsoft is trying to retire. Microsoft's official recommendation is to enable Credential Guard; devices already running Credential Guard are unaffected by this change in the first place.
The root problem is the dependence on combining MS-CHAPv2 with single sign-on in 802.1X environments. Unless Microsoft reverses its retirement roadmap, BlockNtlmv1SSO=0 will eventually cease to be usable. Switching to authentication infrastructure that does not depend on NTLMv1, such as migrating to EAP-TLS, has gained a practical deadline through this incident.
"We treated it like an ordinary Patch Tuesday and applied it without testing, only for this to happen. Since when do monthly updates include changes on this scale?"
These words, left by an administrator in the forum, speak for many IT administrators. September's KB5124008 enabled Credential Guard's "Machine Identity Isolation" in enforcement mode, preventing domain-joined PCs from signing in (in Japanese). With KB5127648, the default change to NTLMv1 blocking again arrived in a monthly update and stopped enterprise authentication infrastructure.
The direction of security hardening is right. Retiring NTLMv1 is a necessary transition. But "we announced it" and "administrators were prepared" are different things. Monthly security updates disrupting enterprise authentication infrastructure for two consecutive months points to a structural problem in how updates are delivered.
Originally published on Joho no Todai. The Japanese original is here.
Top comments (0)