The October 2026 Windows update blocks saved-logon single sign-on for MS-CHAPv2 networks.
Key Takeaways
- KB5127648 is the October 13, 2026, Windows 11 update that moves NTLMv1-derived single sign-on (SSO) to Enforce mode by default.
- Only SSO with saved Windows logon credentials is blocked; event ID 4025 on the client is the fastest way to confirm it.
- EAP-TLS, a certificate-based Extensible Authentication Protocol (EAP) method, uses no saved logon secret, so the change does not apply to it.
If Windows 11 users suddenly have to enter their credentials to connect to corporate Wi-Fi, the October 2026 Windows update may be the reason. The update changes how Windows handles saved credentials for certain network connections, potentially affecting Wi-Fi, Ethernet and VPN connections that use MS-CHAPv2 authentication.
With the update, under certain conditions, Windows blocks single sign-on (SSO) requests that rely on NTLMv1-derived credentials. Users may still be able to connect by entering their credentials manually.
Read on to learn which devices are affected, how to confirm the cause and why moving from PEAP-MSCHAPv2 and EAP-MSCHAPv2 to certificate-based authentication with EAP-TLS is worth considering.
What Is KB5127648?
KB5127648 is the Windows 11 security update released October 13, 2026, covering Windows 11 26H2, 25H2 and 24H2, with operating system (OS) builds 26300.9711, 26200.9711, and 26100.9711.
The authentication note added to that KB page on October 15, 2026, explains the practical effect. When the BlockNtlmv1SSO registry value is not set, Windows now uses Enforce mode (1) instead of Audit mode (0). The change applies only where Credential Guard is disabled, and it might affect Wi-Fi, Ethernet and VPN connections that use MS-CHAPv2-based authentication.
Windows Server 2025 received the same change in KB5126646, build 26100.33650, on the same date.
This Is Planned Hardening, Not a Bug
Microsoft announced the change in August 2025 in KB5066470, a guidance article about managing NTLMv1 changes and preventing network issues.
The article notes that NTLMv1 was removed from Windows 11 24H2 and Windows Server 2025, but NTLMv1 cryptography remnants remain in MS-CHAPv2-based connections, including Protected Extensible Authentication Protocol (PEAP) with MS-CHAPv2 and EAP-MSCHAPv2, in a domain-joined environment.
The rollout moved in stages. Audit logging began in late summer 2025 on Windows 11 24H2 and newer, the rollout started on Windows Server 2025 in November 2025, and the default changed to Enforce mode in October 2026. Microsoft’s release health page listed no known issue for this as of October 16, 2026.
Who Is Affected by KB5127648 PEAP Changes
Microsoft documents four conditions that must all apply before the change takes effect on a connection.
- The device runs Windows 11 24H2, 25H2, or 26H2 or Windows Server 2025 with the October 2026 update.
- Windows Credential Guard is not running on that device.
- The BlockNtlmv1SSO registry value is not set.
- The connection uses MS-CHAPv2 single sign-on, which covers PEAP-MSCHAPv2 and EAP-MSCHAPv2.
Microsoft describes the affected connections as being in domain-joined environments. If Credential Guard is enabled, the change does not take effect at all and Microsoft recommends running it wherever the hardware and licensing requirements are met.
Why Credential Guard Devices Are Outside This Change
Credential Guard already blocks NTLM classic authentication for SSO, so users on those devices must manually type credentials; they cannot save them.
Only SSO is blocked for MS-CHAP, WDigest and NTLMv1. Setting the registry value back to Audit mode does nothing useful on a Credential Guard machine because a different control supplies the block. Our guide on Credential Guard and PEAP-MSCHAPv2 covers how that control works.
Credential Guard has been on by default since Windows 11 22H2 and Windows Server 2025 on domain-joined, non-domain-controller systems that meet hardware requirements, with license entitlement through Enterprise E3/E5 or Education A3/A5.
See your security gap before attackers do.
See continuous trust in action on a platform that includes RADIUS, PKI and AI security.
Symptoms and How to Find Event ID 4025
The user-visible symptom is a Wi-Fi, Ethernet or VPN connection that fails without an obvious cause. The connection does not complete, and the user is prompted to enter credentials.
Manual credential entry still works because only SSO flows that depend on NTLMv1-derived credentials are blocked. The checkbox that supplies the saved Windows logon is labeled “Automatically use my Windows logon name and password (and domain if any)” in the EAP MSCHAPv2 properties.
Reading the NTLM Operational Log
Windows logs event ID 4025 on the client in the Microsoft-Windows-NTLM/Operational log with type Error, source NTLM and the text “An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy.”
Checking for Event 4024 Before the Change Reaches a Device
Event ID 4024 is the audit-mode counterpart. Windows logs it in the same log with type Warning and the text “Auditing an attempt to use NTLMv1-derived credentials for Single Sign-On”. It appears on Windows 11 24H2 or later and on Windows Server 2025.
On devices that have not yet received the October 2026 update, 4024 entries are a forward-looking inventory of machines still relying on MS-CHAPv2 single sign-on.
The Temporary BlockNtlmv1SSO Setting
Microsoft documented a registry value that restores the previous behavior while a dependency is remediated. It is a scoped, temporary security exception, and Microsoft states plainly that Audit mode reduces protection.
The value lives under HKEY_LOCAL_MACHINE\SYSTEM\currentcontrolset\control\lsa\msv1_0 and is named BlockNtlmv1SSO with type REG_DWORD.
|
Data value |
Mode |
Behavior |
|
0 |
Audit |
Request is audited but allowed to succeed; warning events |
|
1 |
Enforce |
Request is blocked; error events |
No device restart is required after changing the value.
The October 2026 update does not create or modify the registry value. Administrators can set the value before or after installing the update, and because the update does not modify it, a value already set stays as configured.
Microsoft published no end date for this exception as of October 16, 2026. Treat it as a stopgap with an open-ended expiry.
Why Uninstalling or Pausing the Update Is Not a Fix
Uninstalling may restore the old default, but later cumulative updates carry the same change, and Microsoft documents the registry value, not rollback, as the exception path. Pausing updates across a fleet also holds back the rest of the security content in the release.
PEAP-MSCHAPv2 carries NTLMv1 cryptography remnants that Microsoft is hardening against, and the company notes that Wi-Fi and VPN endpoints based on MS-CHAPv2 are subject to similar attacks as NTLMv1. Its stated recommendation is to move from PEAP-MSCHAPv2 and EAP-MSCHAPv2 to certificate-based PEAP-TLS or Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).
Why Certificate-Based EAP-TLS Does Not Use This Path
EAP-TLS is defined in RFC 5216 as certificate-based mutual authentication with key derivation. Neither that document nor the protocol involves a password, a logon session or an NTLM-derived credential.
Microsoft’s notes scope this change to MS-CHAPv2-based connections, and its Credential Guard guidance states that Credential Guard does not block certificate-based authentication. The same principle applies here. EAP-TLS uses neither MS-CHAPv2 nor a saved logon secret, so the change does not apply to it. A certificate is presented to the network, validated, and the session proceeds.
PEAP Is the Tunnel, MS-CHAPv2 Is the Problem
PEAP didn’t change. PEAP uses EAP as a transport, and the Transport Layer Security (TLS) tunnel built in Phase 1 protects Phase 2 messages, such as authentication credentials, against eavesdropping and Man-in-the-Middle attacks (MITM). The inner method negotiated over that tunnel is what varies, and EAP-MSCHAPv2 and EAP-TLS are both valid inner methods.
It is the inner method carrying the NTLMv1 remnant. Microsoft names PEAP-TLS as its certificate-based alternative, and the migration steps below configure standalone EAP-TLS.
If you want the deeper comparison, our breakdown of EAP-TLS vs. PEAP-MSCHAPv2 covers where each method fits.
How to Move PEAP-MSCHAPv2 Windows 11 Devices to EAP-TLS
The sequence below works with either Microsoft Intune or Group Policy. The RADIUS server must support EAP-TLS and hold a server certificate, with a policy that accepts EAP-TLS.
- Issue a certificate to each device: The device needs a client certificate before the wireless profile can use EAP-TLS. Intune Simple Certificate Enrollment Protocol (SCEP) profiles and Group Policy auto-enrollment are the two common delivery paths, and both can run silently on managed hardware.
- Publish the server certificate chain: Clients validate the RADIUS server’s certificate during the TLS handshake, so the issuing chain must be trusted on the device.
- Configure the RADIUS server: Accept EAP-TLS alongside PEAP-MSCHAPv2 during the transition, or stand up a separate pilot SSID so the two methods do not collide.
- Build the new wireless profile: Set the EAP method to EAP-TLS and select the client certificate. Leave the old PEAP-MSCHAPv2 profile in place for now.
- Pilot on a small ring: Move a handful of devices and confirm they authenticate against the same SSID before widening the scope.
- Expand in rings: Roll out by department, building or device group. Devices that already hold a certificate can switch as soon as the profile reaches them.
- Retire the old profile: Remove the PEAP-MSCHAPv2 wireless profile once the new one is everywhere, which also closes the SSO path that KB5127648 blocks.
Group Policy auto-enrollment depends on Active Directory Certificate Services (AD CS) or a gateway that supports it. For the Windows-specific profile details, our Intune 802.1X guide and the walkthrough on certificate auto-enrollment with GPO cover the settings that matter.
The security plan that scales with you.
Our solutions can scale from mid-market to global enterprises. Compare options and see how our solutions protect you from costly breaches and ensure peace of mind.
SecureW2 Simplifies the Move to Certificates
With SecureW2, you can leave vulnerable passwords behind and smoothly transition to digital certificates, the more secure and efficient authentication method.
JoinNow Dynamic PKI handles certificates with Enrollment over Secure Transport (EST), Automated Certificate Management Environment (ACME) and SCEP support, including automated issuance, renewal and revocation. Dynamic PKI also integrates natively with Jamf, Intune and other mobile device management (MDM) platforms, so certificates reach devices silently through your existing tools.
On the network side, JoinNow Cloud RADIUS enforces EAP-TLS certificate validation across wired, wireless and VPN connections. It connects to Microsoft Entra ID, Okta, Google Workspace, Intune and Jamf, and real-time directory lookups cut access for departed or non-compliant users.
For Intune shops, SecureW2 acts as the certificate authority (CA) for Intune SCEP profiles and validates each request through Microsoft’s Third-Party CA API, with no on-premises PKI or Network Policy Server (NPS) required.
For self-service BYOD, JoinNow MultiOS onboards Windows, macOS, iOS, Android and ChromeOS devices and supports PEAP, EAP-TTLS/PAP or EAP-TLS.
Schedule a demo to see how the JoinNow Platform can help you make the move to certificates.
Frequently Asked Questions
Why don’t NPS logs show errors?
The block happens on the Windows client, so RADIUS or Network Policy Server (NPS) logs may not show anything useful. Check the Microsoft-Windows-NTLM/Operational log on the affected device for event ID 4025 instead of assuming the server is at fault.
Are macOS, iOS, Android and Linux clients affected?
No. Microsoft’s notes cover Windows only. macOS, iOS, Android and Linux clients do not use this Windows code path, so their Wi-Fi authentication is unaffected by KB5127648 and KB5126646.
Do I need AD CS to deploy EAP-TLS?
No. Active Directory Certificate Services is one way to issue client certificates, but it is not the only one. Managed certificate services and MDM-driven SCEP profiles can deliver the same certificates without running a certificate authority on premises.
Would moving to WPA3-Enterprise avoid this?
No. Standard WPA3-Enterprise still allows PEAP-MSCHAPv2 and is affected the same way. Only WPA3-Enterprise 192-bit mode restricts the EAP method, and the only method it allows is EAP-TLS.
