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

Supply-PWC 71

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 31 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 5 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.
成新斌 5 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 5 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.
Halla, Steve 0 Reputation points

2026-10-15T02:00:02.0733333+00:00

Yes, every laptop that installed the KB has experienced this provlem with PEAP-based 802.1X environments...every laptop.

Only solution has been to uninstall the KB and prevent updates to be reinstalled
Ibnu 0 Reputation points

2026-10-15T07:28:51.4933333+00:00

Is there any other solution for fix this issue ? if PC is connected to the AD server, and the registry settings are locked by Group Policy from the server. and I don't have access to the AD server.
Mohd Imran 0 Reputation points

2026-10-15T08:46:30.79+00:00

I found a small workaround.

Once the patch is installed, select the wireless network and forget it. Then reboot the system and try connecting to the Wi-Fi using your account. It should connect successfully.
Sigrid Torres Escobar 0 Reputation points

2026-10-15T09:17:04.1833333+00:00

Same issue for wired authentication 802.1x solves by uninstalling the update. Dif Microsoft say something about this??
Rui Pinto Ferreira 20 Reputation points

2026-10-15T09:54:26.7166667+00:00

I’ve discovered a workaround that might help until the RegKey solution is implemented or Microsoft releases a fix: if you select "Forget" for the Wi-Fi network you want to use and re-enter your credentials, it starts working (at least until the next restart).

17 answers

AI answer

2026-10-13T22:27:49.45+00:00
KB5127648 is not currently documented by Microsoft as causing a PEAP/802.1X regression, so first verify the exact package and resulting OS build on an affected client before treating KB5127648 as the originating update.

KB5127648 was released on October 13, 2026 for Windows 11 24H2, 25H2, and 26H2, producing builds 26100.9711, 26200.9711, and 26300.9711 respectively. Its published known-issues section does not list PEAP, 802.1X, or Wi-Fi authentication failures.^1^

Confirm the update chronology

On an affected client, capture the edition, build, installed packages, and installation dates:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15 HotFixID, InstalledOn Get-WindowsPackage -Online | Where-Object PackageState -eq Installed | Sort-Object InstallTime -Descending | Select-Object -First 15 PackageName, InstallTime

The expected post-KB5127648 builds are:

Windows 11 24H2: 26100.9711

Windows 11 25H2: 26200.9711

Windows 11 26H2: 26300.9711

If the affected build or installation date differs, identify the cumulative update that actually moved the client to that build. This is particularly important because KB5127648 incorporates earlier updates, so removing it can also remove changes inherited from an earlier cumulative update; rollback correlation alone does not isolate the individual change.

Interpret Event 12014 correctly

OneXHeldStateTimeout means the supplicant’s heldWhile timer expired and 802.1X authentication restarted. It identifies the state-machine outcome, not whether the underlying cause was PEAP negotiation, certificate validation, RADIUS rejection, or missing EAP traffic.^2^

Correlate the same authentication attempt on both sides:

Client: Event Viewer → Applications and Services Logs → Microsoft → Windows → WLAN-AutoConfig → Operational.

NPS server: Event Viewer → Windows Logs → Security.

Find the matching NPS event:

6272: authentication accepted.

6273: authentication rejected; record the Reason Code.

If no corresponding NPS event exists, capture traffic on the client and RADIUS side. Filter client traffic for EAPOL and server-side traffic for EAP.^3^

The result distinguishes three materially different cases:

No request reaches NPS: investigate the Windows supplicant/AP exchange.

NPS records 6273: investigate the recorded policy, credential, or certificate reason.

NPS records 6272 but Windows enters Held state: capture the return EAP/RADIUS exchange between NPS, controller/AP, and client.

Escalation

Because uninstalling the update already restores service across several adapter vendors, preserve one affected machine rather than changing its wireless profile or drivers. Collect:

Before/after OS build and package lists.

Exported WLAN-AutoConfig Operational log.

Matching NPS 6272/6273 events and reason codes.

Wireless/client EAPOL and NPS-side EAP traces.

SSID profile XML with usernames and certificate identifiers redacted.

Exact PEAP inner method and whether server-certificate validation is enabled.

A timestamped comparison from the same device before and after rollback.

Open a Microsoft support case with those artifacts if the affected machine is confirmed at one of the KB5127648 builds. At present, the public KB and release-health material do not establish KB5127648 as a known PEAP regression, so there is no documented Known Issue Rollback or PEAP-specific remediation to deploy.

References

October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100. ...

ONEX_AUTH_RESTART_REASON (dot1x.h) - Win32 apps

802.1X authentication issues troubleshooting - Windows Client
AI-generated content may be incorrect. Read our transparency notes for more information.
Was this answer helpful?

2 people found this answer helpful.
Chance Maurice Niyonzima 500 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?

20+ people found this answer helpful.
Supply-PWC 71 Reputation points

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.

Jim Tolson 20

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."

Ben Green 6 Reputation points

2026-10-14T22:48:11+00:00

That support page says "remnants of NTLMv1 cryptography are still present in some scenarios, such as when using MS-CHAPv2 in a domain-joined environment".

This implies this issue only affects Domain connections that involve MS-CHAPv2.

In my testing today, I can't reproduce the issue for non-domain PEAP w/ MS-CHAPv2 Wi-Fi connections.

The same support page also says "if Windows Credential Guard is enabled on the device, the changes outlined in this article do not take effect".

To get a valid test, my testing was with Credential Guard / Virtualization-based security disabled (prior to install of KB5127648).
Ben Green 6 Reputation points

2026-10-15T07:59:23.8533333+00:00

The Microsoft 365 message center item - MC1508562 "Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard" - helps to explain things.

It says:

In Enforce mode, Windows blocks requests to generate NTLMv1-derived credentials. Wi-Fi, Ethernet, and VPN connections that use MS-CHAPv2 authentication, including PEAP-MSCHAPv2 and EAP-MSCHAPv2, for Single Sign-On might consequently fail to connect automatically. Manually entering credentials can continue to work, but credentials cannot be saved for future use in these scenarios. As a result, workflows that previously established connections without user interaction might no longer function as expected.

That sounds like is specifically impacts the scenario where Windows user credentials were automatically flowing through into the MS-CHAPv2 auth (hence "SSO").
Anil Batukbhai Bhatt 0 Reputation points

2026-10-15T09:09:31.46+00:00

We have also observed the Same issue with Wi-Fi connectivity. After uninstalling the Patch it working fine.

Shaun 31 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?

90+ 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.
Aleksi Vartiainen 5 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?

10+ 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

17 answers

Confirm the update chronology

Interpret Event 12014 correctly

Escalation

Your answer