Windows blocks NTLMv1-derived SSO credentials: enterprise Wi-Fi and VPN may fail

Windows security updates released on 13 October 2026 changed the default BlockNtlmv1SSO behaviour from audit to enforcement. On eligible devices, Windows now blocks the generation of NTLMv1-derived credentials for single sign-on. Organisations that still use PEAP-MSCHAPv2 or EAP-MSCHAPv2 may lose automatic connectivity to enterprise Wi-Fi, wired 802.1X or VPN services.

Microsoft stresses that this is planned hardening, not a known update defect. The change applies to devices where Credential Guard is disabled and the BlockNtlmv1SSO registry value was not explicitly configured. It covers Windows 11 versions 24H2, 25H2, 26H1 and 26H2, and Windows Server 2025.

Breachroad’s conclusion: a connectivity failure may be the first visible evidence of a long-hidden dependency on legacy authentication. Returning temporarily to Audit can create migration time, but the objective should be certificate-based authentication—not permanently reversing the control.

What the update changed

Since August 2025, Windows has been able to audit attempts to use NTLMv1-derived credentials. When BlockNtlmv1SSO was absent, Audit was the internal default: the request succeeded and Windows recorded a warning.

After the October security update, an absent value now means Enforce. Windows blocks the request and records an error. The update does not create or alter the registry value itself, so an administrator inspecting the registry may mistakenly assume that behaviour could not have changed.

Microsoft removed the NTLMv1 protocol from newer Windows releases, yet remnants of its cryptography remain in MS-CHAPv2 scenarios. In a domain environment, they can support automatic use of the signed-in user’s identity for network authentication.

When users experience the problem

A typical case involves a laptop that stops joining corporate Wi-Fi automatically after the update while home Wi-Fi continues to work. Wired 802.1X and VPN connectivity can be affected as well. Manually entering credentials may work, but storing them for repeated use does not address the underlying dependency.

Exposure is most likely where organisations:

• use PEAP-MSCHAPv2 or EAP-MSCHAPv2 in network profiles;
• have domain-joined devices using network SSO;
• have not enabled Credential Guard;
• did not previously configure BlockNtlmv1SSO through Group Policy, Intune or another platform;
• did not analyse warning events collected since August 2025.

The change is not a Wi-Fi driver failure. When users report connectivity loss after the update, teams should inspect authentication and the NTLM log before reinstalling drivers or removing the entire security update.

Confirming the cause

Microsoft identifies the Microsoft-Windows-NTLM/Operational log. In Audit mode, event 4024 means an attempt to use NTLMv1-derived SSO credentials was allowed and recorded. In Enforce mode, event 4025 means policy blocked the attempt.

The event includes the target server, user, domain, client process and process identifier. That context helps distinguish an authentication dependency from a general network-adapter failure.

Do not analyse one laptop alone. Collect events centrally and correlate them with OS version, Credential Guard state, Wi-Fi or VPN profile, and user location. The absence of 4025 on one device may indicate a different local cause, not proof that the organisation has no legacy dependency.

When temporary Audit mode is reasonable

Explicitly setting BlockNtlmv1SSO to 0 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 restores Audit: requests are allowed and generate 4024. A value of 1 enforces blocking and generates 4025. Microsoft says a restart is not required after changing the value.

Audit can be a controlled exception for a device group when lack of connectivity prevents business operations and certificate deployment needs preparation. It should not become a global, indefinite answer. The exception needs:

• a documented device and service scope;
• a risk owner and expiry date;
• monitoring for event 4024;
• a migration plan and a test for returning to Enforce;
• controls preventing the setting from spreading to devices that do not need it.

Removing the whole update also removes other security fixes and is usually less appropriate than a precise, time-limited exception.

Moving to certificate-based authentication

Microsoft recommends replacing MS-CHAPv2 dependencies with certificate-based methods such as EAP-TLS or PEAP-TLS. This is an identity, networking and device-management project—not a simple profile-field change.

Plan for:

1. an inventory of controllers, RADIUS/NPS, Wi-Fi, LAN and VPN profiles;
2. trust anchors and the issue, renewal and revocation lifecycle for certificates;
3. certificate delivery to managed devices and a BYOD scenario;
4. mapping certificates to identities and revoking them during offboarding;
5. a pilot covering representative devices and locations;
6. a parallel transition period with a measurable decline in 4024 events;
7. restored Enforce mode and a negative test of the old profile.

Shared devices, terminals, scanners, printers and systems that cannot readily join a modern MDM need particular attention.

Communication with users matters

When the update prevents network access, the user sees only that “Wi-Fi is broken”. The helpdesk needs a short flow: device and Windows version, affected network, whether manual authentication works, whether event 4025 is present and which team owns escalation.

Do not instruct employees to bypass the problem with a personal hotspot without assessing the risk. Some organisations may approve that as an emergency route, but it needs rules for the device, VPN, data and duration.

Source facts and Breachroad’s analysis

Microsoft confirms the default change after updates released from 13 October 2026, affected Windows versions, the Credential Guard and registry-value conditions, MS-CHAPv2 impact and event IDs 4024 and 4025. The vendor recommends migration to certificate-based authentication.

Exception scope, central metrics, project planning and the helpdesk procedure are Breachroad recommendations. Connect them to the broader Active Directory security programme and NTLM relay risk review. IT, helpdesk and service owners can rehearse the change through cybersecurity training for organisations, while an IT security audit can identify remaining legacy authentication.

Primary sources: Microsoft Support — Manage NTLMv1 changes and prevent network authentication issues, Microsoft — Bracing for BlockNtlmv1SSO.