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

[ITGuyNW]

Happy patch tuesday everyone

 

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

 

October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100.9711) | Microsoft Support

 

Just disabled our rollouts so I can test it.

 

 

[andy_b]

argh just spent the morning looking at this...

[CrootUK]

Registry change does work, short term fix. Push for EAP-TLS here we come! 

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

BlockNtlmv1SSO

Reg_DWORD

0

Pushing it in GPO does seem to retain after the update is applied too..

 

Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 | Microsoft Support Note the timeline on this page

Date	Change
Late August 2025	Auditing logs for NTLMv1 usage enabled on Windows 11, version 24H2 and newer clients.
November 2025	Begin rollout of changes to 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.

Edited Wednesday at 10:21 by CrootUK

[BKGarry]

Ah this may be why I have a smartcard failback one in my Group Policies, I know I put that in because something weird with the PEAP one wouldn't work on HPs we got where the smartcard did, but I also have a delay on Quality Updates by 5 days, which I think has saved me a bit this morning

 

I may put our PSK one in as a fallback just in case though

[synaesthesia]

And another shining example as to why all windows updates with exception to zero day security patches should have a decent cooling off period (2 weeks imo) before being installed, automatically or otherwise. Instant installation in the name of any supposed requirements is absolutely insane, unfortunately. We should be able to rely on them being fully tested before hitting shelves, but at the same time we know testing often never begins until hitting the general populace

 

[sigma]

23 minutes ago, synaesthesia said:

And another shining example as to why all windows updates with exception to zero day security patches should have a decent cooling off period (2 weeks imo) before being installed, automatically or otherwise. Instant installation in the name of any supposed requirements is absolutely insane, unfortunately. We should be able to rely on them being fully tested before hitting shelves, but at the same time we know testing often never begins until hitting the general populace

 

100% agree.
In education, availability of services is paramount, and so even when you do roll out Microsoft (or anybody else’s) updates, they should be tested on devices that “get worked”, but will cause minimal disruption if they break things, which they will from time to time. When they are proved solid in your establishment, only then should they be rolled out site wide.

It’s nothing new, having been the approved method for at least the last 40 years when it was IBM rather than Microsoft.

[ITGuyNW]

I use GPO to put in a 7 day delay, with another 5 day grace period. It's usually enough time to see who braved them first.

[psydii]

Didn't this break in 24h2 by default?

[BKGarry]

10 minutes ago, psydii said:

Didn't this break in 24h2 by default?

Wasn't this you had to explicitly allow your certificate server in the settings in group policy?

 

[psydii]

Machine account based PEAP definitely broke for us at one point a while ago.  Maybe there was another way to fix it, but we rolled out eapTLS because we happened to have all the pieces lined up and ready to go?

[DrCheese]

1 hour ago, psydii said:

Machine account based PEAP definitely broke for us at one point a while ago.  Maybe there was another way to fix it, but we rolled out eapTLS because we happened to have all the pieces lined up and ready to go?

 

If you ever turned on credential guard it broke this, even if you reimaged a machine (It held on) so that might have been it - Was why I switched over to EAP-TLS in the past (I found out on a laptop the hardway :P)

[pete]

When you're rolling out EAP-TLS to fix this (unticking MS-Chapv2 in the radius server conf may also give you a stopgap fix) make sure the device cert renewal window is longer than your summer hols.

[psydii]

The blast radius (::groan::) of this is big enough that HPE/Aruba have issued a support advisory.

 

”This issue is triggered by the Microsoft KB5127648 update on Windows clients using PEAP-MSCHAPv2 and is not an HPE Networking infrastructure issue. Changes to Aruba or Juniper Mist wired or wireless 802.1x configuration will therefore not resolve the underlying authentication failure. ”

 

“

Reference Reading:

Microsoft KB article 5066470 indicates that it has long announced the deprecation of NTLMv1 protocol due to inherently weak cryptographic algorithms it uses in verifying (client) credentials exchanged between the client and the RADIUS server. While the NTLMv1 protocol was removed from Windows 11 24H2 and Windows Server 2025 and later versions, remnants of NTLMv1 cryptography are still present in some scenarios such as when using MS-CHAPv2.

 

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

 

The October 13^th Microsoft Windows KB5174628 update enforced the change in NTLMv1-derived credential usage from “Audit” mode to “Enforce” mode which disrupted automated single sign-on configurations using MS-CHAPv2.”

[browolf]

Advisory published in 365 message centre

https://admin.cloud.microsoft/?ref=MessageCenter/:/messages/MC1508562

[andy_b]

Quote

It is not a known issue with the October 2026 security update.

Given the amount of online discussion it has generated, I feel like the communicated change could have been better articulated prior to the update.  An article from over a year ago isn't the best method.

[3s-gtech]

Current suggested fix (source withheld)

"Uninstall the update"

Considering that this is part of retiring NTLMv1, that feels akin to holding back the tide using one foot and a worn beach towel.

[smarties11]

Not an issue for domain devices as we have been using certificate authentication (currently PEAP-EAP-TLS) for many years.

 

It will be an issue though for Windows devices joining our staff and student Wi-Fi where we use 802.1x with PEAP-MSCHAPv2 for password authentication. Is there an alternative in this scenario to maintain password based authentication rather than certificate? Infact it might be an issue for all devices including non-windows if NPS itself won't accept MSCHAPv2 anymore?

[3s-gtech]

'PSK waves smugly*

More helpfully - possibly captive portal?

Edited Thursday at 13:21 by 3s-gtech

[smarties11]

15 minutes ago, 3s-gtech said:

'PSK waves smugly*

More helpfully - possibly captive portal?

🤣 don't want to go down the PSK route as need to be able to track and log activity against individual users as per DfE guidance

We were using captive portal before on Ruckus but sadly this doesn't work properly on our new Cambium (ahem) Wi-Fi system - we made the choice to go full 802.1X on the basis of it being more secure 🤣

[psydii]

I wonder if the MVPs banging the drum about the boot certs updates got somewhat burned when it turned out that things continued to work just fine, and remain upgradable well after the deadline they had been pushing.

 

However.... given that credential guard should have forced people over to EAP TLS two years ago,  perhaps this is a deliberate strategy to get Admins to subscribe to/check regularly the news feeds where this sort of thing is published.

 

It used to be so easy to keep on top of this sort of change - there were actual consistent rss feeds. 5-10 minutes a day skim reading those and then nothing was a surprise.

[KK20]

This is a windows update isnt it?  At least for us, our NPS PEAP policy is still happily serving 802.11x to our Chromebooks.

 

 

22 hours ago, smarties11 said:

Not an issue for domain devices as we have been using certificate authentication (currently PEAP-EAP-TLS) for many years.

 

It will be an issue though for Windows devices joining our staff and student Wi-Fi where we use 802.1x with PEAP-MSCHAPv2 for password authentication. Is there an alternative in this scenario to maintain password based authentication rather than certificate? Infact it might be an issue for all devices including non-windows if NPS itself won't accept MSCHAPv2 anymore?

 

[CrootUK]

3 minutes ago, KK20 said:

This is a windows update isnt it?  At least for us, our NPS PEAP policy is still happily serving 802.11x to our Chromebooks.

 

 

 

It is windows client side yes.

[psydii]

Adjacent, but unrelated:

 

Andriod and ChromeOS are getting increasingly cranky about enterprise CA  server certs.

[smarties11]

10 minutes ago, KK20 said:

This is a windows update isnt it?  At least for us, our NPS PEAP policy is still happily serving 802.11x to our Chromebooks.

 

 

 

Thank you, this looks encouraging! Has your NPS server been updated to October CU? Wasn't sure if the changes were client side only or both client and server side.

[KK20]

It has yes.  My NPS has the mindset of "any update is a security update, sort issues later, better than a zero day exploit" (or veeam rollback if I really need help!)