Alvise C.Updated 15 October 2026.
The KB5066470, updated on 14 October 2026, describes a change that may interrupt automatic access for corporate connections based on MS-CHAPv2.
To understand the impact, three elements must be distinguished: the NTLMv1 protocol, which has already been removed; encryption still used by some authentication mechanisms; and Single Sign-On, meaning access that reuses the Windows session credentials.
NTLMv1 had already been removed: why is it still being discussed?
Microsoft documents the removal of NTLMv1 starting with Windows 11 24H2 and Windows Server 2025. This does not mean that every technology linked to its encryption disappeared at the same time.
The technical documentation explains that MS-CHAPv2 uses the same response function as NTLMv1, inheriting its cryptographic weaknesses. This is why mechanisms that depend on these legacy components also need to be addressed.
It is important not to confuse NTLMv1 with NTLM as a whole: removing the first version does not mean immediately eliminating all NTLM authentication.
Which versions and updates to check
The updates mentioned are those from 13 October 2026 for Windows 11 24H2, 25H2 and 26H2 and Windows Server 2025.
| System | October update referenced by Microsoft | Build |
|---|---|---|
| Windows 11 24H2 | KB5127648 | 26100.9711 |
| Windows 11 25H2 | KB5127648 | 26200.9711 |
| Windows 11 26H2 | KB5127648 | 26300.9711 |
| Windows Server 2025 | KB5126646 | 26100.33650 |
The versions and builds are listed on their respective update pages.
The KB5066470 is the explanatory document, while KB5127648 and KB5126646 identify the updates cited for clients and servers: do not mix up the numbers.
From Audit to Enforce: what changes in practice
On devices with Credential Guard disabled, when the BlockNtlmv1SSO value is absent, Windows switches from Audit to Enforce after the update.
The update does not create the value in the Registry: it changes the internal behavior applied when the value is absent.
| Configuration | Effect |
|---|---|
| Value 0 | Audit: request allowed and logged |
| Value 1 | Enforce: request blocked |
| Value absent, before the update | Audit |
| Value absent, after the update | Enforce |
The path is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0BlockNtlmv1SSO is a REG_DWORD. The specific events in the Microsoft-Windows-NTLM/Operational log are 4024 for auditing and 4025 for blocking.
Why Wi-Fi and VPN may be affected
Microsoft describes similar issues in its Credential Guard considerations: connections based on PEAP-MSCHAPv2 or EAP-MSCHAPv2 may rely on session credentials for automatic access.
The issue is therefore authentication, not necessarily the network adapter, wireless signal, or VPN tunnel. As a practical example, a PC might reach the infrastructure but fail to complete sign-in using the SSO mechanism configured in the profile.
However, a problem appearing after the update does not, by itself, confirm this cause. Before reinstalling drivers or recreating the connection, check the authentication method and corresponding events.
Manually entering credentials is different from SSO
Microsoft distinguishes automatic credential reuse from explicit entry: in the affected flows, blocking SSO does not necessarily mean blocking authentication using credentials supplied by the user.
A manual test may therefore help with diagnosis, if the profile allows it. It does not guarantee that every VPN will work, nor does it constitute a migration to a more secure method.
Credential Guard: check its status without disabling it as a trial
Credential Guard uses security , or VBS, to isolate secrets such as NTLM hashes and Kerberos tickets. It provides broader protection than simply blocking NTLMv1-derived credentials.
This does not mean that Credential Guard makes every legacy configuration compatible: Microsoft already documents SSO limitations with password-based protocols and recommends testing before deployment.
Do not disable it as a first attempt to restore a connection. First identify which protection is taking effect and on which flow.
How to check whether the problem is caused by the change
A useful sequence for the IT department is as follows:
- Identify the device: Windows version, build, updates, and when the problem began.
- Check the profile: EAP method, use of user or machine credentials, and SSO mode.
- Check Credential Guard and the effective configuration of the BlockNtlmv1SSO value.
- Reproduce an attempt, noting the time.
- Correlate the events with the process, destination, and account, then compare them with the authentication infrastructure logs.
To read the value without changing it, use Command Prompt:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSOIf the value does not exist, interpret the result in conjunction with the PC’s update level. A sign-in error, on the other hand, does not prove that the value is absent.
In Event Viewer, open:
Registri applicazioni e servizi > Microsoft > Windows > NTLM > OperationalThe NTLM auditing documentation explains that the logs help identify who is using NTLM, to which destination, and for what reason. They contain useful information about accounts, processes, and authentication context.
Save the events before changing configurations: a test without a time or destination makes it harder to distinguish the cause from other attempts.
The solution to plan for: certificate-based authentication
For Wi-Fi and VPN, Microsoft recommends migrating from MS-CHAPv2 connections to certificate-based methods, such as EAP-TLS or PEAP-TLS. [6]
Migration requires checking the entire path: clients, profiles, RADIUS or VPN infrastructure, certificate deployment, and renewals. Changing an option on a single computer is not enough.
As an operational plan, start with a pilot group and test at least the initial connection, reconnection, network switching, access after reboot, and certificate expiration or renewal. Also determine who will handle deployment errors and how access to remote devices will be restored.
Temporary exception: what Microsoft provides
For a critical dependency, Microsoft allows BlockNtlmv1SSO=0 as a temporary, limited exception while the fix is completed. This reduces protection and does not reintroduce the removed NTLMv1 protocol.
Before applying it, the IT department should record the devices involved, the reason, the person responsible, and the expiration date. Keep the previous configuration and limit the test to the necessary systems.
After migration, check that no forgotten exceptions remain and recheck the actual behavior on updated systems.
What to do if you are a corporate user
If the connection has stopped working, tell IT which network or VPN you are using, the time of the attempt, and the message you received. Also mention whether a credential prompt appears that you did not see before.
These details make it possible to compare the attempt with the events. Changing the Registry or removing updates without a diagnosis may conceal the problem and leave the device with weaker protection.
For administrators, the priority is to distinguish a legacy SSO configuration from other connectivity failures: first gather evidence, then fix the authentication or define an exception with a precise expiration date.
