Skip to content
TroubleGrid

Enterprise Wi-Fi 802.1X PEAP Authentication Fails After KB5127648

Last verified October 2026Tested against Windows 11 26H2 (OS Build 26300.9711), Windows 11 25H2 (OS Build 26200.9711), Windows 11 24H2 (OS Build 26100.9711), Windows Server 2025 (KB5126646)Well documented

KB5127648 (released October 13, 2026) changes the default for the BlockNtlmv1SSO registry value from Audit to Enforce on devices where Credential Guard is disabled and the value was never set. Enforce mode blocks the NTLMv1-derived credential that PEAP-MSCHAPv2 single sign-on relies on, so 802.1X fails on the client with error 0x80070285 and never reaches your RADIUS server. Confirm it with event 4025 in Microsoft-Windows-NTLM/Operational, then either set BlockNtlmv1SSO to 0 as a temporary exception or move the network to certificate-based EAP-TLS.

Start here

  1. Confirm it is the NTLMv1 change before you touch anything
  2. Get online now by typing your credentials instead of using single sign-on

This is not a Wi-Fi driver fault and not a RADIUS misconfiguration, which is why the usual checks come back clean. Microsoft documents the underlying change in its NTLMv1 servicing guidance, but the KB5127648 article itself does not mention 802.1X, PEAP or NTLM at all — so the update that broke your network and the page that explains it are two different documents. This article connects them and tells you how to confirm the cause before you change anything.

Symptoms

  • Wi-Fi on a WPA2-Enterprise or WPA3-Enterprise network stops connecting after installing KB5127648, while WPA2-Personal and home networks still work
  • Wired 802.1X connections sit at "connected, not authenticated"
  • WLAN-AutoConfig logs event 12013 with error 0x80070285, "There was an internal authentication error"
  • Wired-AutoConfig logs event 15514 with reason 0x50005 and ErrorCode 0x80070285, then event 15506 suspending authentication for 600 seconds
  • Authentication starts and then times out: event 12014 or 15504, "OneX Held State timeout"
  • The RADIUS or NPS server has no record of the failed attempt at all
  • Typing your domain username and password manually connects, but "Use my Windows user account" does not
  • Microsoft-Windows-NTLM/Operational logs event 4025 where the same device previously logged 4024

Why this happens

The October 2026 update flips BlockNtlmv1SSO from Audit to Enforce

Microsoft has been phasing out NTLMv1-derived cryptography since August 2025. The control is a single registry value, BlockNtlmv1SSO, where 0 means Audit mode (the request is allowed and logged) and 1 means Enforce mode (the request is blocked). Microsoft's servicing guidance states that the October 2026 security update released October 13, 2026 changes the default from Audit to Enforce on devices where the value has never been set, and names KB5127648 as the Windows 11 update that carries it. The update does not write the value — it changes what Windows does when the value is absent, which is why nothing in your configuration appears to have changed. Microsoft's own guidance says the change might affect Wi-Fi, Ethernet and VPN connections that use MS-CHAPv2-based authentication, naming PEAP-MSCHAPv2 and EAP-MSCHAPv2 as examples.

Set BlockNtlmv1SSO to 0 as a temporary, scoped exception · Uninstall KB5127648 only if you cannot set the registry value · Migrate the network to certificate-based EAP-TLS

Only single sign-on breaks, which is why manual credentials still work

PEAP-MSCHAPv2 single sign-on asks the local security authority for a stored NTLMv1-derived credential so it can answer the MS-CHAPv2 challenge without prompting you. Enforce mode blocks exactly that request, and Microsoft confirms that manually entered credentials continue to work because only SSO flows are affected. The practical consequence is that the failure is client-side: the supplicant cannot answer the challenge and gives up before the exchange completes. Administrators on both Microsoft Q&A threads, and two independent write-ups, consistently report no matching record on the RADIUS or NPS server for the failed attempt, which is why checking the server, the switch and the access point finds nothing wrong. Microsoft documents the blocked credential request; the empty server-side log is a consistent field observation rather than a vendor statement.

Confirm it is the NTLMv1 change before you touch anything · Get online now by typing your credentials instead of using single sign-on

Credential Guard changes whether you are affected at all

Microsoft states that this change applies only where Credential Guard is disabled, and that if Credential Guard is enabled the change does not take effect. A device with Credential Guard on is not subject to the new default, so if your affected machines all have it enabled, this article is probably not your problem. This also means a mixed estate can fail unevenly, with some machines connecting normally and others not, for a reason that has nothing to do with the network.

Confirm it is the NTLMv1 change before you touch anything

Fixes

Confirm it is the NTLMv1 change before you touch anything

about 5 min

Enforce mode writes a specific error event, so you can prove the cause in under a minute instead of rebuilding network profiles.

Applies to: Windows 11 24H2, 25H2 and 26H2, Windows Server 2025

  1. Open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > NTLM > Operational.
  2. Look for event ID 4025 (Error, source NTLM) around the time the connection failed. That event means an NTLMv1-derived single sign-on request was blocked by Enforce mode. Event 4024 (Warning) is the Audit-mode equivalent and means requests are still being allowed.
  3. Cross-check the client-side failure: for Wi-Fi, look in Microsoft-Windows-WLAN-AutoConfig/Operational for event 12013 with error 0x80070285. For wired, look in Microsoft-Windows-Wired-AutoConfig/Operational for event 15514 with ErrorCode 0x80070285.
  4. Confirm the build matches: run the command below. KB5127648 produces build 26300.9711 (26H2), 26200.9711 (25H2) or 26100.9711 (24H2).
    winver
  5. Check whether Credential Guard is running. If it is enabled, the new default does not apply to that device and the cause is something else.
    Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning

Confirmed by the vendor.

Source: Microsoft, Microsoft Q&A (community), Microsoft Q&A (community), Thomas Marcussen

Get online now by typing your credentials instead of using single sign-on

about 5 min

Enforce mode blocks only the stored credential, so a password you type is still accepted.

Applies to: PEAP-MSCHAPv2 networks using Windows single sign-on

  1. Open the Wi-Fi network's properties, or the wired adapter's Authentication tab, and find the PEAP settings.
  2. In the PEAP properties, open Configure next to "Secured password (EAP-MSCHAP v2)" and clear the "Automatically use my Windows logon name and password" checkbox.
  3. Reconnect. When prompted, enter your credentials as DOMAIN\username and your password.
  4. Expect to do this again after a restart. Several administrators report the typed credentials are not retained, so treat this as a way to get working rather than a fix.

Confirmed by the vendor.

Source: Microsoft, Microsoft Q&A (community), Keytos

Set BlockNtlmv1SSO to 0 as a temporary, scoped exception

Advancedabout 10 min

Pinning the value to 0 returns the device to Audit mode, which restores single sign-on while keeping the October security update installed.

Applies to: Devices with Credential Guard disabled, Windows 11 24H2, 25H2, 26H2 and Windows Server 2025

Before you do this

This re-enables a credential path Microsoft is deliberately retiring. Audit mode allows NTLMv1-derived single sign-on requests and only logs them, so it reduces protection against credential-relay and downgrade attacks on every device you apply it to. Microsoft sanctions it only as a temporary, scoped exception where a critical dependency cannot be migrated immediately — not as a permanent setting. If your organisation has a security baseline or change process, this belongs in it, and if Group Policy locks the value you will need the domain administrator rather than a local edit.

  1. Back up the registry, or at least export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, before you change anything.
  2. Create or set the DWORD value BlockNtlmv1SSO to 0 under that key. From an elevated command prompt:
    reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f
  3. Or from an elevated PowerShell prompt:
    New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -Value 0 -PropertyType DWord -Force
  4. Reconnect and test. Microsoft states a restart is not required, though several administrators rebooted before retesting.
  5. To deploy it across an estate, push the value through Group Policy preferences and run gpupdate /force, or use an Intune remediation script. There is no Settings Catalog or Policy CSP node for this value, so a script is the supported route.
    gpupdate /force
  6. Record this as an exception with a review date. It is the thing you undo once the network moves to certificate-based authentication.

Confirmed by the vendor, though some users report it does not help.

Source: Microsoft, Microsoft Q&A (community), Microsoft Q&A (community), Thomas Marcussen, Keytos

Uninstall KB5127648 only if you cannot set the registry value

Advancedabout 20 min

Removing the update restores the old Audit default, but it also removes October's security fixes and Windows will offer the update again.

Applies to: Windows 11 24H2, 25H2 and 26H2

Before you do this

Uninstalling a security update leaves the device without October 2026's security fixes for as long as it stays off, and Windows will keep offering the update unless you pause or hide it. Setting BlockNtlmv1SSO to 0 achieves the same connectivity result while keeping the machine patched, so prefer that unless Group Policy or a management tool prevents it.

  1. Prefer the registry exception above. Uninstalling costs you the whole October security update, including its Secure Boot certificate deployment and its fixes for Explorer crashes, AC-3 audio playback and Always On VPN.
  2. From an elevated command prompt:
    wusa /uninstall /kb:5127648
  3. Restart the device and retest the connection.
  4. Pause updates, or the update will be re-offered and reinstalled, and the failure will come back. Administrators on the Microsoft Q&A threads confirm reinstalling reproduces it.
  5. On some machines the October package is installed alongside related updates and those may need to come off too for the rollback to take effect.
  6. Plan the real fix now. This leaves the device unpatched, so it is a holding action measured in days, not weeks.

Reported to work by 5 users; not confirmed by the vendor.

Source: Microsoft Q&A (community), Microsoft Q&A (community), Keytos

Migrate the network to certificate-based EAP-TLS

Advancedabout 240 min

EAP-TLS does not use NTLM at all, so it is unaffected by this change and by the rest of the NTLMv1 retirement.

Applies to: Organisations running their own RADIUS or NPS and a certificate authority

Before you do this

Changing 802.1X authentication affects every client on the network, and a misconfigured profile or an expired client certificate can leave devices unable to connect at all. Pilot it, keep PEAP accepted on the RADIUS side until the migration is complete, and make sure certificate renewal is automated before you remove the fallback.

  1. Treat this as the durable fix. Microsoft's own guidance for this change is to migrate MS-CHAPv2-based Wi-Fi, Ethernet and VPN authentication to certificate-based authentication such as PEAP-TLS or EAP-TLS.
  2. Issue client certificates from your existing PKI or a managed CA, and configure your RADIUS or NPS policies to accept EAP-TLS alongside PEAP while you transition.
  3. Pilot on a small group of devices first, confirm enrolment and renewal work unattended, then roll out by group.
  4. Where Credential Guard's requirements are met, deploy it too. Microsoft notes that Credential Guard protects against NTLMv1-derived cryptography and that the October default change does not apply where it is enabled.
  5. Remove the BlockNtlmv1SSO exception once the last PEAP-MSCHAPv2 client is gone.

Confirmed by the vendor.

Source: Microsoft, Thomas Marcussen, Keytos

Known issues

  • Microsoft's KB5127648 article does not list 802.1X or PEAP authentication failures among its known issues. The behaviour is documented separately, as an intentional hardening change, in Microsoft's NTLMv1 servicing guidance — so there is no acknowledged regression to wait for a hotfix on.

    Affects Windows 11 26H2 (OS Build 26300.9711), Windows 11 25H2 (OS Build 26200.9711), Windows 11 24H2 (OS Build 26100.9711) · Status: workaround only

  • The two issues Microsoft does list for KB5127648 are unrelated to this one: Remote Desktop connections failing for non-admin users with error 0xC000000D on hosts with Administrator protection enabled, and USB Audio Class 1.0 devices failing to start or producing no sound.

    Affects Windows 11 24H2, 25H2 and 26H2 · Status: open

  • User reports so far are on Windows 11 26H2 (build 26300.9711) and 24H2 (build 26100.9711). A question asking whether 25H2 is affected went unanswered, but 25H2 receives the same update and the same default change applies to it, so treat it as affected until shown otherwise.

    Affects Windows 11 25H2 (OS Build 26200.9711) · Status: unknown

If none of this worked

This article is not your problem if any of the following is true. Credential Guard is enabled on the affected devices — Microsoft states the change does not take effect there. Your network uses EAP-TLS or another certificate-based method rather than PEAP-MSCHAPv2, which does not involve NTLM. WPA2-Personal and home networks also fail, which points at the wireless driver or radio instead. Your RADIUS or NPS server logs an actual rejection for the attempt, which means the request did reach the server and the failure is a policy, certificate or account problem there rather than a client-side block. Or there is no event 4025 in Microsoft-Windows-NTLM/Operational, in which case Enforce mode is not what is stopping you. Note also that one administrator could not reproduce the failure on a non-domain PEAP-MSCHAPv2 setup with Credential Guard disabled, so the problem appears to require the Windows single sign-on path with a domain account; a standalone machine using a typed password was never relying on the blocked credential in the first place.

Common questions

Will a future Windows update fix this?
Do not plan on it. Microsoft has not listed this as a known issue in KB5127648, and the underlying change is deliberate hardening that was announced in August 2025 with a scheduled default flip. That means there is nothing for Microsoft to roll back here — the behaviour is working as designed. The BlockNtlmv1SSO exception buys you time, and migrating to certificate-based authentication is the fix Microsoft is pointing everyone towards.
Why does my RADIUS server show nothing for the failed attempts?
Because the failure happens on the client before anything is sent. Enforce mode blocks the local request for the NTLMv1-derived credential, so the supplicant fails with 0x80070285 and never completes the exchange. This is the single most useful diagnostic in this whole issue: an empty RADIUS log alongside a client-side 0x80070285 is the signature of this cause rather than a network or server fault.
Does setting BlockNtlmv1SSO to 0 turn off security?
It returns the device to Audit mode, which allows NTLMv1-derived single sign-on requests and logs them as event 4024 instead of blocking them as 4025. So yes, it gives up a protection you currently have, which is why Microsoft frames it as a temporary, scoped exception rather than a setting to leave in place. Apply it where you need it, record it, and remove it when the network no longer depends on PEAP-MSCHAPv2.
Is this the same as the Remote Desktop or USB audio problem in the same update?
No. Those are the two issues Microsoft does document for KB5127648 — Remote Desktop failing for non-admin users with error 0xC000000D where Administrator protection is enabled, and USB Audio Class 1.0 devices showing Code 10. They are unrelated to 802.1X and to NTLM, and fixing one does nothing for the other.
Can I deploy the registry value through Intune or Group Policy?
There is no Settings Catalog entry or Policy CSP node for BlockNtlmv1SSO, so you cannot set it as a first-class policy. Administrators are deploying it with a Group Policy preference plus gpupdate /force, or with an Intune remediation or PowerShell script. If an existing Group Policy already locks the value, a local edit will be overwritten and you will need the change made at the domain level.

Did this fix work?

If a step is wrong, outdated, or did not help, telling us is the fastest way to get it corrected. Reports are reviewed before new articles.

Report a problem with this page

Related problems

Sources

  • Manage changes to NTLMv1 and prevent network issues in Windows 11 and Windows Server 2025Official

    Microsoft · Documentation · checked Oct 15, 2026

    • The October 2026 Windows security update released October 13, 2026 changes the default for BlockNtlmv1SSO from Audit mode (0) to Enforce mode (1) on devices where the value is not set, and names KB5127648 as the related Windows 11 update article.
    • The registry value is BlockNtlmv1SSO, type REG_DWORD, at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0; 0 means Audit mode (requests allowed and logged) and 1 means Enforce mode (requests blocked).
    • The change might affect Wi-Fi, Ethernet and VPN connections that use MS-CHAPv2-based authentication such as PEAP-MSCHAPv2 and EAP-MSCHAPv2.
    • The change applies only where Credential Guard is disabled; if Credential Guard is enabled these changes do not take effect.
    • Audit mode logs event ID 4024 (Warning) and Enforce mode logs event ID 4025 (Error), both in the Microsoft-Windows-NTLM/Operational log with source NTLM.
    • Manually entering credentials continues to work in Enforce mode; only single sign-on flows that depend on NTLMv1-derived credentials are blocked.
    • Microsoft states that setting BlockNtlmv1SSO to 0 is a temporary, scoped exception where a critical dependency cannot be migrated immediately, and warns that Audit mode reduces protection.
    • Microsoft recommends migrating MS-CHAPv2-based Wi-Fi, Ethernet and VPN authentication to certificate-based authentication such as PEAP-TLS or EAP-TLS, and deploying Credential Guard where supported.
    • Changing the BlockNtlmv1SSO value does not require a restart.
  • October 13, 2026—KB5127648 (OS Builds 26300.9711, 26200.9711 and 26100.9711)Official

    Microsoft · Support page · checked Oct 15, 2026

    • KB5127648 was released October 13, 2026 for Windows 11 versions 26H2, 25H2 and 24H2, carrying OS builds 26300.9711, 26200.9711 and 26100.9711.
    • The known-issues section of KB5127648 lists only two issues: Remote Desktop failures for non-admin users with error 0xC000000D on hosts with Administrator protection enabled, and USB Audio Class 1.0 devices failing or producing no sound.
    • The KB5127648 article does not mention 802.1X, PEAP, WPA2-Enterprise, NTLM, NTLMv1 or Wi-Fi authentication anywhere.
    • Windows 11 24H2 Home and Pro editions reach end of updates with this release.
  • KB5127648 breaks WPA2-Enterprise (802.1X PEAP) Wi-Fi authentication on Windows 11Community report

    Microsoft Q&A (community) · Forum · checked Oct 15, 2026

    • Roughly 15 to 20 distinct administrators report that WPA2-Enterprise 802.1X PEAP authentication stops completing after KB5127648 while WPA2-Personal networks keep working.
    • Reporters log WLAN-AutoConfig event 12011 followed by 12014 (OneX Held State timeout) and 8002, and event 12013 with error 0x80070285 when 'Use my Windows user account' is selected.
    • Uninstalling KB5127648 and rebooting restores connectivity, and reinstalling the update reproduces the failure.
    • Setting BlockNtlmv1SSO to 0 at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 restored authentication for at least seven administrators, while one reported it only bought them time.
    • Entering DOMAIN\username and password manually instead of using the Windows account succeeds where single sign-on fails.
    • Reports on this thread are on Windows 11 26H2 build 26300.9711; a question asking whether 25H2 is affected went unanswered.
    • One administrator could not reproduce the failure on a non-domain PEAP-MSCHAPv2 configuration with Credential Guard disabled, which suggests the Windows single sign-on path with a domain account is needed to trigger it.
  • KB5127648 breaks wired 802.1X (PEAP) authentication on Windows 11 24H2Community report

    Microsoft Q&A (community) · Forum · checked Oct 15, 2026

    • About five distinct users report wired 802.1X PEAP authentication failing on Windows 11 24H2 build 26100.9711 after KB5127648, with the client showing 'connected, not authenticated'.
    • Wired-AutoConfig logs event 15503, then 15504 ('Onex Held State timeout'), then 15514 with reason 0x50005 'There was an internal authentication error' and ErrorCode 0x80070285, then 15506 suspending authentication for 600 seconds.
    • The reporting administrator found no matching record on the RADIUS server for the failed attempts.
    • Uninstalling the update with wusa /uninstall /kb:5127648 and rebooting restored authentication, and Windows then re-offers the update.
    • One user reports both wired and wireless 802.1X affected on the same estate.
  • KB5127648 802.1X PEAP Wi-Fi broken on Windows 11: cause and fixCommunity report

    Thomas Marcussen · Reference · checked Oct 15, 2026

    • An independent write-up dated October 14, 2026 attributes the 802.1X PEAP failures to the October 2026 change of the BlockNtlmv1SSO default from Audit to Enforce, and reports NTLM/Operational event 4025 as the confirming signal.
    • The request never reaches the RADIUS or NPS server, so the RADIUS log shows nothing for the failed attempt.
    • Certificate-based EAP-TLS does not involve NTLM and is unaffected by this change.
    • No Settings Catalog entry or Policy CSP node exists for BlockNtlmv1SSO, so deployment at scale needs a script or Intune remediation.
  • KB5127648 Breaks PEAP Wi-Fi and 802.1X Authentication: What Happened and How to Fix ItCommunity report

    Keytos · Reference · checked Oct 15, 2026

    • A vendor write-up dated October 14, 2026 reports the same symptom set and event IDs 12013, 15514 and 4025, and states the failure occurs on the client before a request is sent to RADIUS.
    • Manual credential entry works because the supplicant computes the MS-CHAPv2 response from the typed password rather than requesting the stored NTLM-derived credential from LSA.
    • The write-up treats pausing or uninstalling the update and setting BlockNtlmv1SSO to 0 as temporary measures and recommends EAP-TLS as the permanent fix.