Tag Archives: Wi-Fi

KB5127648 breaks 802.1X PEAP Wi-Fi authentication on Windows 11: cause and workarounds

Posted on by
Reply

Update, 14 October 2026: Microsoft has not yet listed the KB5127648 802.1X PEAP authentication failure as a known issue on the Windows release health dashboard or in the KB article. Everything below is based on reproducible reports from administrators, Microsoft’s own NTLMv1 documentation and my own customer cases. I will update this post when Microsoft publishes an official statement.

The October 2026 Patch Tuesday update for Windows 11, KB5127648 (OS builds 26100.9711, 26200.9711 and 26300.9711 for 24H2, 25H2 and 26H2), was released on 13 October 2026. Within hours, administrators started reporting that domain-joined clients could no longer authenticate to WPA2-Enterprise Wi-Fi using 802.1X PEAP. Wired 802.1X PEAP is affected too. WPA2-Personal and WPA3-Personal networks keep working, which is why the problem often looks like “the Wi-Fi is broken at the office but fine at home”.

I got the first call from a customer this morning: “Clients suddenly refuse to connect to our Wi-Fi, and there were no problems yesterday.” That is the fingerprint of this issue. Here is what we know, how to confirm it on an affected device, and what you can do about it today.

Symptoms of the KB5127648 802.1X PEAP issue

  • Clients on Windows 11 24H2, 25H2 or 26H2 with KB5127648 installed fail to connect to WPA2-Enterprise (802.1X) Wi-Fi.
  • Wired 802.1X PEAP on Ethernet shows “Connected, not authenticated” and loops on a 600 second block timer.
  • Authentication starts but never completes. The request never reaches the RADIUS/NPS server, so there is nothing to find in the NPS log.
  • Both machine authentication and user authentication with “Use my Windows user account” fail. Manually typing DOMAIN\username and password in the Wi-Fi prompt has been reported to work.
  • Intel and Qualcomm Wi-Fi chipsets are both affected, so this is not a driver problem.
  • Uninstalling KB5127648 and rebooting restores connectivity. Reinstalling it breaks it again.

How to confirm it in Event Viewer

Open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational (or Wired-AutoConfig > Operational for Ethernet). On an affected device you will see this sequence:

LogEvent IDMessage
WLAN-AutoConfig12011Wireless 802.1X authentication started successfully (PEAP)
WLAN-AutoConfig12014Authentication restarted, reason: OneX Held State timeout
WLAN-AutoConfig12013Authentication failed, error 0x80070285 (internal authentication error)
Wired-AutoConfig15514Authentication FAILED, reason 0x50005, error 0x80070285
Wired-AutoConfig15506Authentication suspended, Explicit EAP failure received, BlockingTime 600
EapHost2088User uses saved credentials (the only EapHost event, no Schannel certificate errors)

If the root cause below is correct, you will also find Event ID 4025 in Microsoft-Windows-NTLM > Operational: “An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy.” Before the update, the same device would have logged the audit-only Event ID 4024 instead.

The likely root cause: NTLMv1 SSO is now blocked by default

Microsoft announced in 2025 that it would tighten NTLMv1 handling in Windows 11 24H2 and Windows Server 2025. The timeline in the support article Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 is explicit:

  • Late August 2025: Audit logging for NTLMv1 usage enabled on Windows 11 24H2 and newer.
  • November 2025: Rollout of the changes to Windows Server 2025.
  • October 2026: The default value of the BlockNtlmv1SSO registry key changes from Audit mode (0) to Enforce mode (1). This only takes effect if the key has not been deployed explicitly.

The same article names the exact scenario that breaks: remnants of NTLMv1 cryptography are still used “when using MS-CHAPv2 in a domain-joined environment”, and the examples given are “Wi-Fi, Ethernet, and VPN deployments using MS-CHAPv2 authentication”. PEAP with the MS-CHAPv2 inner method, which is what most password-based enterprise Wi-Fi still runs on, needs the NTLMv1-derived credential for single sign-on with the logged-on user or the machine account. When Enforce mode blocks that request, EAP fails locally with 0x80070285 before a single packet reaches your RADIUS server.

The KB5127648 article does not mention NTLM, 802.1X or PEAP at all, and Microsoft’s release notes said it was not aware of any new issues apart from a USB audio problem. So the causal link is inferred from the timeline and the fact that setting the key back to 0 fixes the problem. Treat it as very likely, not confirmed.

Workaround 1: Pause the update and uninstall it on affected devices

If you manage updates with Windows Autopatch, Intune update rings or WSUS, pause the October quality update now so it does not reach more devices. If you are mid-way through a 26H2 rollout, see my post on getting ready for Windows 11 26H2 with Autopatch for how the rings and pause controls fit together. On devices that are already broken, uninstall the update and reboot:

wusa /uninstall /kb:5127648

Keep in mind that this removes the October security fixes, and that the device needs a working network to receive anything from Intune. A device without Wi-Fi cannot download a remediation script, so plan for a wired connection, a phone hotspot or hands-on work.

Workaround 2: Set BlockNtlmv1SSO back to Audit mode

Several administrators have confirmed that explicitly deploying the registry value restores PEAP authentication while keeping KB5127648 installed. This is the approach Neowin and Windows Report describe:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Reboot afterwards. The value means:

  • 0 (Audit): The request to generate NTLMv1 credentials for a logged-on user is audited but allowed. Event 4024 is logged.
  • 1 (Enforce): The request is blocked and Event 4025 is logged. This is the new default after KB5127648.

Be honest with yourself about what this does: you are rolling back a security hardening that Microsoft has been announcing for over a year. It buys time, nothing more. One administrator in the Microsoft Q&A thread put it well: setting it to 0 “only bought us time”.

Deploying the value with Intune

There is no Settings Catalog entry or Policy CSP node for this value, so use a Remediation script (Devices > Scripts and remediations) or a PowerShell script. A minimal pair that is safe to run repeatedly:

# Detect-BlockNtlmv1SSO.ps1
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
$value = (Get-ItemProperty -Path $path -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($value -eq 0) { Write-Output 'Compliant'; exit 0 }
Write-Output "Non-compliant (value: $value)"; exit 1

# Remediate-BlockNtlmv1SSO.ps1
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-ItemProperty -Path $path -Name BlockNtlmv1SSO -PropertyType DWord -Value 0 -Force | Out-Null
Write-Output 'BlockNtlmv1SSO set to 0 (Audit). Reboot required.'
exit 0

Run it in the 64-bit PowerShell host, in system context, and target it at the devices that are not yet updated first. Devices that are already off the network will pick it up as soon as they get any connectivity.

The real fix: move from PEAP-MSCHAPv2 to EAP-TLS

Password-based PEAP-MSCHAPv2 has been on borrowed time for years. It depends on NTLM-era cryptography, it is vulnerable to credential relay if clients do not validate the server certificate strictly, and Microsoft is clearly moving toward blocking it. The durable answer is certificate-based EAP-TLS, which does not touch NTLM at all and is unaffected by this change.

  • Cloud-native tenants: Microsoft Cloud PKI in Intune Suite can issue device and user certificates via SCEP, and your NPS or cloud RADIUS validates them. No on-premises CA required.
  • Hybrid tenants with AD CS: Use your existing enterprise CA with an Intune Certificate Connector (SCEP or PKCS) and switch the NPS network policy to Microsoft: Smart Card or other certificate.
  • Either way: Push a new Wi-Fi profile from Intune with EAP-TLS, keep the PEAP SSID running in parallel until every device has a certificate, then retire it.

If you are also deploying Credential Guard (and you should be), note that Microsoft’s NTLMv1 article recommends it strongly. Credential Guard already blocks NTLMv1 and unconstrained delegation on its own, so a device with Credential Guard enabled is likely to have hit this wall earlier in testing.

What to tell your users and your helpdesk

  • Home Wi-Fi, hotspots and guest networks with a simple passphrase still work. Only the corporate 802.1X network is affected.
  • Typing the domain username and password manually in the Wi-Fi prompt is a usable emergency workaround for individual users.
  • Do not let users “reset network settings” or reinstall Wi-Fi drivers. It wastes time and changes nothing.

References