KB5066470 Blocks MS-CHAPv2 SSO on Windows 11 and Server 2025: Event 4025 and Temporary Fix

For over a year, Windows 11 and Windows Server 2025 machines without Windows Credential Guard have been quietly logging warnings whenever legacy authentication protocols reached into the Local Security Authority (LSA) for NTLMv1-equivalent secrets. As of October 2026, that grace period is officially over. When the BlockNtlmv1SSO registry value is not explicitly configured on a machine where Credential Guard is disabled, Windows now actively blocks the generation of NTLMv1-derived SSO credentials.

Here is a complete breakdown of what changed in KB5066470, why devices without Credential Guard are suddenly hitting authentication walls on MS-CHAPv2 networks, how to hunt down the offending processes in Event Viewer, and how to manage the transition without stranding your users.

The Ghost of NTLMv1: Why Dead Protocols Still Haunt Modern Networks​

At first glance, an advisory about NTLMv1 hardening in late 2026 sounds like anachronistic trivia. Didn't Microsoft already remove the NTLMv1 protocol from Windows 11 version 24H2 and Windows Server 2025? Yes, they did. The wire protocol itself was stripped out as part of Microsoft's broader initiative to deprecate and eventually retire the entire NT LAN Manager (NTLM) family in favor of Kerberos and modern certificate-based authentication.

However, in enterprise networking, there is a critical distinction between the NTLMv1 network protocol and NTLMv1-derived cryptography. Even with the protocol removed, remnants of NTLMv1 cryptographic calculations persisted inside Windows to support older higher-level authentication mechanisms.

The primary culprit in modern Active Directory environments is MS-CHAPv2—specifically when wrapped inside PEAP-MSCHAPv2 or EAP-MSCHAPv2 for Wi-Fi (WPA2/WPA3-Enterprise), 802.1X wired Ethernet port authentication, and legacy VPN tunnels. Under the hood, MS-CHAPv2 relies on the user's NT hash to compute challenge-response material that is cryptographically equivalent to NTLMv1. When an endpoint uses Single Sign-On—meaning Windows automatically passes the currently logged-on user's credentials to the RADIUS server or VPN concentrator without prompting the user to type their password—the operating system must ask the LSA to generate those NTLMv1-derived credentials.

Because NTLMv1 cryptography lacks modern salting and can be cracked with trivial ease if captured or relayed, leaving that SSO credential-generation path open is a glaring security liability.

The Credential Guard Divide​

Why is this issue only surfacing on specific machines right now? Because Windows Credential Guard already solved this problem years ago. When Credential Guard is enabled, it uses virtualization-based security (VBS) to isolate LSA secrets, completely blocking applications and network supplicants from extracting NTLMv1-derived SSO credentials. Organizations that enabled Credential Guard across their fleet already went through the growing pains of migrating away from PEAP-MSCHAPv2 SSO to EAP-TLS (certificate-based authentication).

However, not every machine in an enterprise has Credential Guard running. Virtual desktop infrastructure (VDI) instances without nested virtualization, older hardware lacking specific hypervisor prerequisites, specialized IoT Enterprise endpoints, or machines where administrators intentionally disabled Credential Guard to keep legacy Wi-Fi or VPN profiles alive were left operating under the old rules. KB5066470 closes that loophole.

• Key Takeaway: KB5066470 only affects Windows 11 (versions 24H2, 25H2, and 26H2 across all editions) and Windows Server 2025 devices where Windows Credential Guard is disabled. If Credential Guard is active on a device, this update changes nothing because those protections are already enforced.

What Changed in the October 2026 Security Update?​

Microsoft's rollout of this hardening measure followed a textbook three-stage deprecation timeline documented in KB5066470:

1. Late August / September 2025: Microsoft introduced the BlockNtlmv1SSO registry control and enabled Audit mode (0) by default on Windows 11 version 24H2 and newer client builds. Single Sign-On requests using NTLMv1-derived credentials continued to succeed, but Windows began logging Warning Event ID 4024.
2. November 2025: The same auditing infrastructure and registry support rolled out to Windows Server 2025.
3. October 13, 2026: With the October 2026 security updates (KB5127648 for Windows 11 and KB5126646 for Windows Server 2025), Microsoft flipped the internal OS default when BlockNtlmv1SSO is absent from Audit mode (0) to Enforce mode (1).

The "Phantom Default" Nuance​

One technical detail in KB5066470 is guaranteed to trip up junior sysadmins inspecting registries during troubleshooting: the October 2026 update does not actually create or modify the BlockNtlmv1SSO registry value.

If you open Registry Editor on a freshly patched Windows 11 25H2 or 26H2 laptop, navigate to the MSV1_0 key, and look for BlockNtlmv1SSO, you won't find it unless your organization pushed it via Group Policy or Intune. Instead, Microsoft changed the compiled internal fallback behavior of the operating system when that value is missing. Before October 13, 2026, an absent value meant 0 (Audit). After installing the October 2026 update, an absent value means 1 (Enforce).

SSO vs. Manual Credential Entry​

Another vital operational distinction is that Enforce mode specifically blocks Single Sign-On credential generation for logged-on users. According to Microsoft's documentation in KB5066470, manually typing credentials continues to work in Enforce mode.

In practice, this means a domain-joined laptop configured to automatically authenticate to a WPA2-Enterprise (802.1X PEAP-MSCHAPv2) Wi-Fi network using the Windows logon session will fail to connect automatically via SSO, or may unexpectedly prompt the user to type their username and password manually. For headless systems, kiosk devices, or Seamless VPN setups where users aren't accustomed—or able—to manually enter domain credentials for network access, that distinction still translates to a broken connection.

• Key Takeaway: Installing the October 13, 2026 security update switches unconfigured, non-Credential Guard machines into Enforce mode without writing a visible registry key, breaking automatic SSO for MS-CHAPv2 Wi-Fi, Ethernet, and VPN profiles while leaving manual password entry intact.

Hunting the Culprits: Event IDs 4024 and 4025​

Before blindly pushing registry overrides across your domain, you should verify whether KB5066470 is actually responsible for a connectivity failure. Microsoft built dedicated telemetry for this exact mechanism inside the NTLM Operational log.

To inspect these events locally on an affected machine, open Event Viewer and navigate to:

Applications and Services Logs > Microsoft > Windows > NTLM > Operational

You are looking for two specific Event IDs from the NTLM event source:

Both Event ID 4024 and Event ID 4025 capture rich diagnostic metadata right in the event payload, removing the guesswork from troubleshooting:

• Target server: <domain_name>
• Supplied user / Supplied domain: The account details involved in the SSO attempt.
• PID and Name of client process: Identifies the exact executable (such as a native Windows LAN/WLAN supplicant process or a third-party VPN client service) requesting the legacy credential.
• LUID of client process: The Locally Unique Identifier of the logon session.
• User identity and Domain name of client process: Confirms which local security context invoked the call.
• Mechanism OID: The Object Identifier indicating the authentication mechanism negotiated.

Don't Confuse SSO Events with General NTLM Auditing​

While browsing the Microsoft-Windows-NTLM/Operational log, administrators will likely notice several other events in the 4020–4033 range. As detailed in Microsoft's companion auditing advisory KB5064479 (which also expanded to Windows Server 2022 via KB5126655 and Windows Server 2019 via KB5126651 on October 13, 2026), Event IDs 4020/4021 (client outgoing NTLM), 4022/4023 (server incoming NTLM), and 4030–4033 (domain controller NTLM forwarding) are part of Microsoft's general NTLM Enhanced Logging suite. Those events track broader NTLMv1 and NTLMv2 wire traffic across the enterprise.

When troubleshooting the October 2026 SSO enforcement change specifically, keep your filter locked onto Event IDs 4024 and 4025.

• Key Takeaway: If a machine is failing Wi-Fi, wired 802.1X, or VPN SSO after the October 2026 update, check Microsoft-Windows-NTLM/Operational for Error Event ID 4025. It will name the exact process ID and executable whose NTLMv1-derived SSO request was blocked.

Step-by-Step: How to Configure BlockNtlmv1SSO (and Buy Time if Needed)​

If you discover critical production workflows—such as an aging RADIUS infrastructure or a VPN appliance that cannot immediately be switched away from MS-CHAPv2 SSO—Microsoft provides an escape hatch via the BlockNtlmv1SSO registry value. Conversely, if you haven't installed the October 2026 patch yet and want to test Enforce mode on a pilot ring first, you can use the exact same value to force enforcement early.

Registry Configuration Details​

• Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
• Value Name: BlockNtlmv1SSO
• Value Type: REG_DWORD
• Value Data:
  • 0 = Audit Mode: Allows NTLMv1-derived SSO credential generation to succeed and logs Warning Event ID 4024.
  • 1 = Enforce Mode: Blocks NTLMv1-derived SSO credential generation and logs Error Event ID 4025 (Default behavior after installing the October 2026 security update if the value is absent).
• Reboot Requirement: None. According to KB5066470, a device restart is not required after creating or changing BlockNtlmv1SSO.

Deploying a Temporary Audit Exception via Command Prompt or PowerShell​

If you have endpoints that lost network SSO after installing KB5127648 or KB5126646 and need an immediate, temporary relief valve while your network team configures certificate authentication, run the following command from an elevated PowerShell or Command Prompt window:

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

Because LSA picks up this change dynamically without requiring a reboot, affected Wi-Fi, Ethernet, or VPN profiles can immediately retry their SSO handshake.

To return the device to Enforce mode once your network authentication has been modernized (or by deleting the custom override on a post-October 2026 system), either set the value to 1 or remove the value entirely:

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

• Key Takeaway: Setting BlockNtlmv1SSO to 0 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 restores the pre-October 2026 Audit behavior immediately without a reboot.

The Architect's View: Temporary Relief vs. Permanent Remediation​

Let's be candid: when a cumulative security update breaks corporate Wi-Fi on a Wednesday morning, the temptation to blast BlockNtlmv1SSO = 0 to every workstation in Active Directory via Group Policy Preferences and call it a day is immense.

Resist the urge to make that exception permanent. Microsoft explicitly warns in KB5066470 that setting BlockNtlmv1SSO to 0 reduces the security posture of the device and should only be treated as a scoped, temporary security exception while remediation is completed.

Why? Because any environment still relying on PEAP-MSCHAPv2 or EAP-MSCHAPv2 with domain credentials is fundamentally vulnerable to evil-twin RADIUS attacks and credential capture. Even without NTLMv1 on the wire, MS-CHAPv2 handshakes can be intercepted by a rogue access point and cracked offline to recover the underlying NT hash of the user's Active Directory password.

Your Long-Term Remediation Checklist​

1. Scope the Exception Narrowly: If you must deploy BlockNtlmv1SSO = 0, apply it only to the specific organizational units (OUs) or security groups experiencing the MS-CHAPv2 SSO failure, and attach an expiration date to the change ticket.
2. Audit Event ID 4024 Continuously: On machines running with the temporary 0 exception, forward Event ID 4024 to your SIEM so you can watch the count drop as you migrate workloads.
3. Migrate 802.1X and VPN to EAP-TLS: Transition Wi-Fi, wired 802.1X, and VPN profiles from password-based MS-CHAPv2 to certificate-based authentication (EAP-TLS) using Active Directory Certificate Services (AD CS), Cloud PKI, or Windows Hello for Business certificates.
4. Enable Windows Credential Guard: Once your MS-CHAPv2 dependencies are eliminated, enable Credential Guard across all supported Windows 11 and Windows Server 2025 systems. Not only does Credential Guard enforce this exact NTLMv1-derived credential block natively, it also protects Kerberos ticket-granting tickets (TGTs) and NTLMv2 hashes in memory against credential-dumping tools.

Microsoft gave administrators thirteen months of audit logs between August 2025 and October 2026 to spot these legacy MS-CHAPv2 SSO stragglers. If a few slipped through the cracks in your environment this week, Event ID 4025 and BlockNtlmv1SSO give you everything you need to put out the immediate fire—and finally bury the last remnants of NTLMv1 cryptography for good.