If laptops on your 802.1X network started failing to join WiFi or wired Ethernet after mid-October patching, you are not alone. Windows security updates released on October 13, 2026 changed how Windows treats a piece of legacy cryptography that PEAP-MSCHAPv2 has quietly depended on for years. On many domain-joined Windows 11 devices, the "sign in automatically with my Windows logon" behavior that admins rely on for PEAP now fails by default.
This guide explains exactly what Microsoft changed, how to confirm it is your problem, the temporary exception Microsoft documents, and why the lasting fix is moving managed Windows devices to certificate-based WPA-Enterprise with EAP-TLS. Everything here is sourced to Microsoft's own documentation, chiefly KB5066470.
What Changed in the October 2026 Windows Update?
Windows 11 version 24H2 and Windows Server 2025 removed the NTLMv1 protocol, but remnants of NTLMv1-derived cryptography survived inside MS-CHAPv2. That includes PEAP-MSCHAPv2 and EAP-MSCHAPv2 when a domain-joined device uses the signed-in user's Windows credentials for single sign-on (SSO).
Microsoft has been phasing this out in two steps:
- Audit mode (from late August 2025): Windows logged a warning each time NTLMv1-derived credentials were used for SSO, but the connection still worked
- Enforce mode (from October 13, 2026): the October security updates, including KB5127648 for Windows 11 versions 24H2, 25H2 and 26H2 and KB5126646 for Windows Server 2025, changed the default. When the
BlockNtlmv1SSOregistry value is not set, Windows now blocks those SSO requests instead of only auditing them
Microsoft says the change "might affect Wi-Fi, Ethernet, and VPN connections that use MS-CHAPv2-based authentication." The update does not create the registry value. It changes what Windows does when the value is absent, which is why so many fleets were caught out: nothing in Group Policy or Intune changed, yet behavior did.
Which Devices Are Affected?
The October change applies only to devices where Credential Guard is disabled. That sounds like an escape hatch, but it isn't. Microsoft's Credential Guard guidance already states that when Credential Guard is enabled, SSO for MS-CHAP and NTLMv1 is blocked. Credential Guard has been on by default for eligible Enterprise and Education devices since Windows 11 version 22H2. Either way, password-based PEAP single sign-on is finished on modern managed Windows.
| Windows 11 24H2+ device | PEAP-MSCHAPv2 with Windows logon (SSO) | PEAP with typed credentials | EAP-TLS (certificate) |
|---|---|---|---|
| Credential Guard enabled | Blocked (Credential Guard) | Works | Works |
| Credential Guard disabled, BlockNtlmv1SSO not set, October update installed | Blocked (new default) | Works | Works |
| Credential Guard disabled, BlockNtlmv1SSO = 0 | Allowed (audited, temporary exception) | Works | Works |
Two details matter for triage. First, Microsoft confirms that manually entering credentials continues to work, so users who type a username and password at the prompt can still connect. Second, the block happens on the Windows device, before a usable MS-CHAPv2 response is produced. No change on the RADIUS server can bring SSO back, whichever RADIUS server you run.
How Do You Confirm This Is Your Problem?
Before changing anything, prove the cause. Microsoft added dedicated events to the Microsoft-Windows-NTLM/Operational log:
- Event ID 4025 (Error): "An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy." This is the Enforce-mode block
- Event ID 4024 (Warning): the Audit-mode event. If you see these on devices that have not yet taken the October update, those devices will break when they do
On an affected laptop, open Event Viewer, go to Applications and Services Logs, Microsoft, Windows, NTLM, Operational, and look for 4025 at the time of a failed connection. Then check whether the WiFi or wired profile uses PEAP with "Automatically use my Windows logon name and password." If both are true, you have found it.
The 4024 warnings are also your best inventory tool. Collecting them across the fleet tells you which devices and profiles still depend on PEAP SSO, so you can size the migration instead of guessing.
Is There a Quick Fix?
Microsoft documents one temporary security exception. Setting BlockNtlmv1SSO to 0 (REG_DWORD) under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 returns the device to Audit mode, and Microsoft notes no restart is required. It only helps devices where Credential Guard is disabled.
Treat the Registry Value as a Loan, Not a Fix
Microsoft is explicit that Audit mode "reduces the protection provided by Enforce mode and should only be considered as a scoped, temporary security exception." If you use it, scope it to the devices that cannot connect any other way, record an expiry date, and track it like any other open risk. Every device you exempt is a device you still have to migrate.
The other short-term option is operational rather than technical: have affected users type their credentials at the prompt. It is clumsy, it does not help devices that need network access before anyone signs in, and it keeps passwords in the WiFi path. But it keeps people working while you fix the real problem.
Why Is EAP-TLS the Fix That Lasts?
Microsoft's resolution in the Credential Guard documentation is direct: move from MS-CHAPv2-based connections to certificate-based authentication such as PEAP-TLS or EAP-TLS, which Credential Guard does not block. EAP-TLS also fixes the weaknesses that made Microsoft retire the old path in the first place:
- No password on the wire. The device proves its identity with a private key that never leaves it, so there is no reusable credential to phish through an evil-twin access point or crack offline
- Connects before sign-in. A device certificate lets a laptop join the network at the login screen, before any user signs in
- Survives password changes. Users resetting passwords no longer knock their own devices off WiFi
- Works the same on WiFi and wired. The same certificate and the same 802.1X policy cover both, which matters because the October change hit Ethernet too
For a deeper comparison of methods, see our guide to EAP-TLS vs PEAP vs EAP-TTLS.
How Do You Move a Windows Fleet from PEAP to EAP-TLS?
The migration is mostly certificate logistics. Because the EAP method is negotiated per connection, you can usually run PEAP and EAP-TLS side by side on the same SSID while devices move over one group at a time.
- Inventory. Use the 4024 and 4025 events to list affected devices and the profiles they use. Separate company-managed Windows devices from personal and unmanaged ones, because they get certificates differently
- Stand up certificate issuance. You need a CA that issues client certificates and a RADIUS server that trusts it. IronWiFi's Cloud PKI provides both without an on-premises CA, and issues certificates to managed devices through SCEP from Microsoft Intune, Jamf or Workspace ONE. For Intune-managed Windows, follow the help center guide to SCEP with Intune for device authentication
- Cover unmanaged devices. Devices without an MDM can enroll themselves through the IronWiFi Enrollment Portal, which provisions a certificate and WiFi profile from a single link
- Build the EAP-TLS profile. Push a WiFi (and, if needed, wired) profile that selects the certificate and validates the RADIUS server certificate by trusted root and server name. Never ship a profile that skips server validation. The Windows EAP-TLS configuration guide walks through the settings
- Pilot. Move one team or site, confirm connections at the login screen and after password changes, and check that VLAN or policy assignment still works with certificate identities
- Roll out in waves. Expand group by group, watching RADIUS logs for failures
- Retire the old path. Remove the PEAP profile from managed devices, delete any
BlockNtlmv1SSOexceptions, and decide whether PEAP should stay enabled at all on the SSID
If your devices are Entra ID joined with no on-premises Active Directory, our guide to Entra ID and RADIUS without on-prem AD covers the identity side of the same move.
Replace PEAP Before the Next Patch Cycle
IronWiFi gives you cloud RADIUS, a cloud certificate authority, and SCEP delivery through Intune, Jamf or Workspace ONE, so Windows devices can move to EAP-TLS without building an on-premises PKI. It works with the access points and switches you already have.
Start Free Trial Explore Cloud PKIFrequently Asked Questions
Windows security updates released on October 13, 2026, including KB5127648, changed the default for the BlockNtlmv1SSO setting from Audit mode to Enforce mode on devices where Credential Guard is disabled and the registry value is not set. Windows now blocks NTLMv1-derived credentials for single sign-on, so domain-joined devices using PEAP-MSCHAPv2 with their Windows logon credentials can fail to connect. Microsoft documents the change in KB5066470.
Yes. Microsoft states the change might affect Wi-Fi, Ethernet, and VPN connections that use MS-CHAPv2-based authentication, including PEAP-MSCHAPv2 and EAP-MSCHAPv2, when they rely on single sign-on.
No. The block happens on the Windows device before a usable MS-CHAPv2 response is produced, so no RADIUS server setting restores single sign-on. The fixes are on the client: a temporary registry exception, typed credentials, or moving to certificate-based EAP-TLS.
It works, but Microsoft describes it as a scoped, temporary security exception that reduces protection. Setting BlockNtlmv1SSO to 0 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 restores Audit mode only on devices where Credential Guard is disabled. Use it for a short, tracked period while you migrate to EAP-TLS.
Yes. Microsoft confirms that manually entering credentials continues to work in Enforce mode. Only the single sign-on flow that reuses the Windows logon is blocked.
No. A cloud certificate authority such as IronWiFi Cloud PKI can issue client certificates to managed devices over SCEP through Microsoft Intune, Jamf, or Workspace ONE, and unmanaged devices can enroll through a self-service enrollment portal. The RADIUS server then authenticates devices by certificate instead of password.
Conclusion
The October 2026 update did not invent a new problem. It finished a retirement Microsoft started in 2025 and signposted through Credential Guard years earlier. PEAP-MSCHAPv2 single sign-on depends on cryptography Windows no longer wants to produce. The registry exception buys time, and typed credentials keep people working, but neither is a destination.
Use the audit events to find every device still on the old path, put certificates on them, and switch the profiles to EAP-TLS. Do that once and the next round of Windows hardening becomes a non-event for your WiFi.
Daniel Konecny
Blog Writer, IronWiFi
Daniel writes about enterprise WiFi authentication and identity security at IronWiFi. With deep expertise in RADIUS, 802.1X, and cloud infrastructure, he covers practical network security for IT teams managing thousands of devices.
About the author