KB5127648 breaks WPA2-Enterprise (802.1X PEAP) Wi‑Fi authentication on Windows 11

Supply-PWC 1

After installing KB5127648, Windows 11 clients can no longer authenticate to our WPA2-Enterprise (802.1X/PEAP) wireless network. Authentication starts but never completes (Event 12014: OneX Held State timeout). WPA2-Personal networks continue to work. The issue reproduces across multiple hardware vendors and wireless chipsets. Uninstalling KB5127648 immediately restores connectivity. Has anyone else observed this with PEAP-based 802.1X environments?

Shaun 6 Reputation points

2026-10-14T01:38:13.3833333+00:00

Yes, we are experiencing the same issue with our wifi via 802.1X/PEAP. Uninstalling the update and wifi connectivity is restored.
OC 0 Reputation points

2026-10-14T01:44:33.82+00:00

We are also experiencing the same or a very similar issue, we are needing to uninstall the update so our users can access Wi-Fi.
Max Robertson 10 Reputation points

2026-10-14T03:03:43.59+00:00

Same issue observed. Across both WiFi and Ethernet 802.1X.
Trying rollback of KB5127648 to see if this changes anything.
成新斌 0 Reputation points

2026-10-14T03:20:30.0933333+00:00

今天发现公司同仁多台机器遇到类似问题，发现均为今天凌晨打的补丁，卸载KB5127648 更新后，网络恢复正常
K K 0 Reputation points

2026-10-14T03:53:48.28+00:00

遇到同样的问题，卸载KB后正常，用域账号做的wifi认证。
ra-v 5 Reputation points

2026-10-14T07:52:10.79+00:00

Hi,

I can confirm the issue with computer authentication in AD using 802.1x. The first thing I did was remove the recently installed KB5127648 package, which resolved the problem. Next, you need to perform the registry modification to prevent future issues on computers that haven't received the update yet.
Gaurav Kumar 0 Reputation points

2026-10-14T10:42:43.0266667+00:00

Currently we are using Security Protocol WPA2/WPA3-enterprise after uninstall the patch KB5127648 radius authentication is working, if we migrate only to WPA3-Enterprise then radius will work with MS Patch KB5127648 ?
Sam S Ranjith 0 Reputation points

2026-10-14T15:41:23.8933333+00:00

Is this issue occurring only on Windows 11 26H2, or does it also affect Windows 11 25H2 systems with this KB installed?
Nick Haffen 0 Reputation points

2026-10-14T16:48:07.6633333+00:00

The suggested registry fix seems to work fine. Lukily I noticed this before rebooting our other few WiFi clients that need this. I pushed out the registry modification through a group policy. You don't have to uninstall the update if you just modify the registry. I just plug into the network and run 'gpupdate /force' to get it.

14 answers

Shaun 6 Reputation points

2026-10-14T04:57:08.9966667+00:00

For us the fix was - https://support.microsoft.com/en-us/servicing/os/windows/docs/2025/08/upcoming-changes-to-ntlmv1-in-windows-11-version-24h2-and-windows-server-2025

Open regedit as admin. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 Create a DWORD 32 bit with the name of BlockNtlmv1SSO and assign the value to 0.
Was this answer helpful?

50+ people found this answer helpful.
SD Daniel 0 Reputation points

2026-10-14T08:38:58.8433333+00:00

Pefect it works. Thanks !
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Jim Tolson 0

For us it was the following, setting the reg key back to 0 fixed the issue. But that's only bought us time...
https://support.microsoft.com/en-us/servicing/os/windows/docs/2025/08/upcoming-changes-to-ntlmv1-in-windows-11-version-24h2-and-windows-server-2025

October 2026	The default value of the BlockNtlmv1SSO registry key is changed from Audit mode (0) to Enforce mode (1) through a future Windows update, strengthening NTLMv1 restrictions. This change in defaults only takes effect if the BlockNtlmv1SSO registry key has not been deployed.
October 2026	The default value of the BlockNtlmv1SSO registry key is changed from Audit mode (0) to Enforce mode (1) through a future Windows update, strengthening NTLMv1 restrictions. This change in defaults only takes effect if the BlockNtlmv1SSO registry key has not been deployed."

0 comments

Chance Maurice Niyonzima 495 Reputation points Independent Advisor

2026-10-13T23:01:18.6766667+00:00
Hello,

Thank you for posting your question on the Microsoft Windows Forum!

In the detailed testing results. You've already done more troubleshooting than most cases reach, and the findings are quite significant:
- The issue started after installing KB5127648.
- It affects WPA2-Enterprise (802.1X/PEAP) authentication.
- It reproduces across multiple hardware vendors and wireless chipsets.
- WPA2-Personal networks continue to work.
- Removing KB5127648 immediately restores connectivity.
Based on that evidence, I would not focus on wireless drivers at this point.

I reviewed Microsoft's published release notes for KB5127648 and, at the time of writing, Microsoft does not list any known issue related to 802.1X, PEAP, WPA2-Enterprise, WLAN AutoConfig, or OneX authentication in the update's known issues section. [support.mi...rosoft.com]

That makes your findings particularly interesting because they suggest one of two possibilities:
1. An undocumented regression introduced by KB5127648.
2. A change in the authentication stack that is exposing a compatibility issue in specific PEAP environments.
The next piece of information that would be most valuable is not additional client troubleshooting, but determining where the authentication is failing:
- Does the authentication request reach your NPS/RADIUS server?
- Do you see NPS Event ID 6272 (success) or 6273 (failure) for the affected client?
- Are you using PEAP-MSCHAPv2 or PEAP-TLS?
If NPS never receives the authentication request after KB5127648 is installed, that would strengthen the case for a client-side 802.1X regression. If NPS receives and rejects the request, the failure is occurring further along in the authentication flow.

At the moment, I have not found any Microsoft documentation acknowledging this specific behavior in KB5127648, but your rollback testing provides strong evidence that the update is involved. It would also be useful to know whether other administrators running PEAP-based environments are observing the same behavior after deploying this update.

Microsoft Reference:
- October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100.9711): https://support.microsoft.com/help/5127648
I hope this answer has brought you useful information. If so, please click on Accept Answer and consider upvoting it. Doing so helps other community members identify useful solutions to similar issues.

Thanks,

Maurice
Was this answer helpful?

10+ people found this answer helpful.
Supply-PWC 1 Reputation point

2026-10-13T23:22:22.84+00:00

Thank you for the response.

Additional findings from our testing:

The issue reproduces across multiple Windows 11 devices from different hardware vendors.

Multiple Wi‑Fi chipsets are affected (Intel and Qualcomm).

WPA2-Personal networks continue to function normally.

Wired networking is unaffected.

Wireless Group Policy continues to apply successfully.

The wireless profile remains present after installing KB5127648.

PEAP authentication starts successfully (Event 12011).

Affected clients consistently generate:

Event 12014: OneX Held State timeout

Event 8002: Security check did not complete after several attempts

No current Schannel certificate validation errors are generated during the failure.

EapHost logs contain only Event 2088 ("User Uses Saved Credentials").

Most importantly, the issue is reproducible:

Install KB5127648 → WPA2-Enterprise authentication fails.

Uninstall KB5127648 and reboot → WPA2-Enterprise authentication works again.

Reinstall KB5127648 → issue returns.

We have reproduced this behavior on multiple systems.

To answer your questions:

Authentication method: PEAP (EAP Type 25) using machine authentication.

The NPS events reviewed so far were not associated with affected endpoints. We are continuing to look for corresponding RADIUS events from impacted clients.

Affected systems are running Windows 11 26H2.

At this point we're trying to determine whether this is a Windows 802.1X/PEAP regression introduced by KB5127648 or a specific interoperability issue with our WPA2-Enterprise infrastructure.

Max Robertson 10 Reputation points

2026-10-14T03:15:03.7+00:00

Same as above -
Uninstall KB5127648 and reboot → WPA2-Enterprise authentication works again.

LAU WEE JIAN 0 Reputation points

2026-10-14T03:49:51.82+00:00

for our company, we try manually type the credential able to connect. only using "use my windows account" not working.

Kaito Hanai 20 Reputation points

2026-10-14T08:08:26.5266667+00:00

Same here, and I can add some details that point to the BlockNtlmv1SSO default change.

Windows 11 26H2 (build 26300.9711, after KB5127648), WPA2-Enterprise (802.1X / PEAP) Wi-Fi with domain accounts:

With "Use my Windows user account" checked: authentication fails. WLAN-AutoConfig Event 12013, Error 0x80070285 (internal authentication error).

With the checkbox unchecked and credentials entered manually (DOMAIN\username + password): authentication succeeds (Event 12012).

The BlockNtlmv1SSO registry value was not set, both before (build 26300.9550) and after (build 26300.9711) the update.

Adam French 1 Reputation point

2026-10-14T14:09:45.3666667+00:00

For us both Wired and Wireless was affected.

Setting the registry value to 0 as documented above fixed both Wireless and Wired connections for us.

The requests were hitting our NPS server but were being discarded due to the request apprently being malformed.

We tried setting a Framed-MTU to a value of 1344, which was suggested on some forums from a while back. This had no affect. A reboot of the NPS server as well as switches and AP's had no affect either.

We are using Ubquiti Switches and Access points, all of which tie back to a Microsoft NPS server running on Windows Server 2022. Clients without KB5127648 installed, continued to authenticate and conenct without issue. Both Wirelss and Wired.

Once the update is isntalled, they all fail, and all get reported on the NPS server as follows:

Network Policy Server discarded the request for a user. Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: host/***REDACTED*** Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - Called Station Identifier: ***REDACTED*** Calling Station Identifier: ***REDACTED*** NAS: NAS IPv4 Address: ***REDACTED*** - IP address of our Network Switch NAS IPv6 Address: - NAS Identifier: - NAS Port-Type: Ethernet NAS Port: 11 RADIUS Client: Client Friendly Name: ***REDACTED*** - Hostname of our Network switch Client IP Address: ***REDACTED*** - IP address of our Network Switch Authentication Details: Connection Request Policy Name: Use Windows authentication for all users Network Policy Name: - Authentication Provider: Windows Authentication Server: ***REDACTED*** - Name of our NPS server Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code: 3 Reason: The RADIUS Request message that Network Policy Server received from the network access server was malformed.

This affects all our policies where we use a condition of the machine being part of a "Machine Group".

Hopefully this helps someone.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Dan 0 Reputation points

2026-10-14T07:54:52.63+00:00

BlockNtlmv1SSO=0 worked for me as well. Added it to a GPO for the time being.

This is a complete disaster though. I usually do testing and gradual updates when there's a new feature update, not on every single Patch Tuesday. Since when does Microsoft introduce breaking changes in routine monthly updates?
Was this answer helpful?

10 people found this answer helpful.
SD Daniel 0 Reputation points

2026-10-14T08:38:21.9933333+00:00

Same thing here, we changed the registry and it fix the issue

Bryan Dam 30 Reputation points

2026-10-14T14:59:05.75+00:00

They've been doing this for years. It's literally standard operating procedure for dealing with certain kinds of security flaws. They add a reg key to enable (or sometimes disable) the protection, then they change that key's default value to be secure, then they remove the key entirely and enforce the protection globally.

In this case, they told us over a year ago that this was coming: https://support.microsoft.com/en-us/servicing/os/windows-11/2026/10/kb5127648-windows-11-24h2-25h2-26h2-security-update
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Aleksi Vartiainen 0 Reputation points

2026-10-14T06:27:53.4333333+00:00

We're also affected by this. Both 802.1X PEAP Wi-Fi & Ethernet authentication stopped working after the update. Uninstalling KB5127648 fixes the issue.
Was this answer helpful?

8 people found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

KB5127648 breaks WPA2-Enterprise (802.1X PEAP) Wi‑Fi authentication on Windows 11

14 answers

Your answer