Wi-Fi or VPN not connecting after the October 2026 Windows update: NTLMv1 fix
If office Wi-Fi, wired 802.1X or a VPN stopped connecting automatically after the October 13, 2026 Windows update, Windows is now blocking NTLMv1-derived single sign-on by default. It affects PCs that sign in to the network with PEAP-MSCHAPv2 or EAP-MSCHAPv2 using Windows credentials and don’t run Credential Guard. Typing the username and password by hand still works, and Microsoft’s temporary workaround is one registry value: BlockNtlmv1SSO set to 0.
Below: how to confirm this is your problem, how to apply the workaround on one PC or many, and the longer-term fix Microsoft wants you to move to.
Before you start
- You’ll need: an administrator account on the PC (or Group Policy/Intune access for many PCs).
- Time: about 10 minutes per PC to check and apply.
- Applies to: Windows 11 24H2, 25H2, 26H1 and 26H2 with the October 2026 update (KB5127648 on 24H2/25H2/26H2), and Windows Server 2025.
- Home Wi-Fi: networks that use a single Wi-Fi password (WPA2/WPA3-Personal) aren’t the target of this change.
What changed in the October 2026 update
Microsoft has been retiring NTLMv1 for years. Since late August 2025, Windows 11 24H2 and later have logged NTLMv1-derived single sign-on (SSO) attempts in Audit mode. The October 13, 2026 update flips the default: if the BlockNtlmv1SSO registry value doesn’t exist, Windows now behaves as if it were set to 1 (Enforce) and blocks those requests. The update doesn’t create or change the value itself, according to Microsoft KB5066470, which was last revised on October 19, 2026.
MS-CHAPv2, used by PEAP-MSCHAPv2 and EAP-MSCHAPv2, depends on NTLMv1-style cryptography. So networks that silently log users in with their Windows password are the ones that break. Microsoft describes this as planned hardening, not a bug, and The Register reported the fallout on October 16.
Signs this is your problem
- The PC no longer joins company Wi-Fi or wired 802.1X on its own and asks for credentials instead.
- Entering your username and password manually connects, but Windows won’t remember them.
- An always-on or auto-connect VPN profile that used your Windows sign-in now fails.
- Shared PCs, kiosks and devices that sign in before a user logs on lose the network.
- Phones, Macs and PCs without the October update still connect to the same network.
Confirm it in Event Viewer
- Press Win + R, type
eventvwr.mscand press Enter. - Go to Applications and Services Logs > Microsoft > Windows > NTLM > Operational.
- Look for Event ID 4025 (Error). It means an NTLMv1-derived request was blocked by policy. Event ID 4024 (Warning) means one was audited but allowed.
To check from PowerShell, run these as administrator. The first shows whether the value exists; the second lists recent NTLM events.
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 50 | Where-Object { $_.Id -in 4024,4025 }
Also check Credential Guard: run msinfo32 and look at Virtualization-based security Services Running in System Summary. If Credential Guard is listed, this change doesn’t apply to that PC, and Credential Guard already blocks MS-CHAPv2 SSO, so the registry workaround below won’t help it.
Temporary fix: set BlockNtlmv1SSO to Audit mode
Microsoft calls this “a scoped, temporary security exception.” Use it to restore connections while you plan a move away from MS-CHAPv2, and write down which PCs you changed.
| Value | Mode | Result |
|---|---|---|
| Not set | Enforce (new default) | NTLMv1-derived SSO blocked, Event 4025 |
| 1 | Enforce | Blocked, Event 4025 |
| 0 | Audit | Allowed, logged as Event 4024 |
Option 1: Registry Editor
- Back up the registry or create a restore point.
- Open regedit as administrator.
- Go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. - Right-click MSV1_0 > New > DWORD (32-bit) Value and name it
BlockNtlmv1SSO. If it already exists, open it. - Set Value data to
0and click OK. - Reconnect to the network. Microsoft says no restart is required.
Option 2: one command
From Command Prompt or PowerShell opened as administrator:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f
Option 3: many PCs
On domain-joined PCs, create a Group Policy Preferences registry item (Computer Configuration > Preferences > Windows Settings > Registry) with the same key, value name, REG_DWORD type and data 0, and filter it to the machines that need it. With Intune, deploy the same value through a remediation script. Uninstalling the October update also restores connections but removes that month’s security fixes, so it is a poor trade.
The real fix: move off MS-CHAPv2
Microsoft’s guidance is to stop relying on password-based MS-CHAPv2 for network sign-in. The usual replacement is certificate-based EAP-TLS, where each device or user proves itself with a certificate instead of a password. It also removes the dropped-connection problem after password resets.
- List every Wi-Fi SSID, 802.1X policy and VPN profile that uses PEAP-MSCHAPv2 or EAP-MSCHAPv2. Event 4024 entries help find them.
- Apply the Audit workaround only where needed, with an end date.
- Set up a certificate authority (Active Directory Certificate Services or a cloud PKI) and push device certificates through Group Policy or Intune.
- Enable EAP-TLS on your RADIUS server (NPS or your firewall vendor’s equivalent) alongside PEAP, then move groups over.
- When nothing uses MS-CHAPv2, delete the
BlockNtlmv1SSOvalue or set it to 1.
Small offices without a RADIUS server usually run WPA2/WPA3-Personal and won’t see this at all. If your VPN uses a vendor client with its own login, check that vendor’s notes before changing anything on Windows.
If you’re still on 24H2 Home or Pro, note that October 2026 was its last regular update; see how to check your version and move to 25H2 or 26H2. The same update also broke Exchange Outlook on the web for some servers and some USB headsets with Code 10.
FAQ
Will Microsoft roll this back?
There’s no sign of that. Microsoft frames it as planned hardening and lists no end date for the Audit workaround, so treat the registry value as a stopgap.
Is setting BlockNtlmv1SSO to 0 safe?
It restores the pre-October behavior on that PC, which Microsoft says reduces the protection Enforce mode provides. Limit it to the PCs that need it and remove it once you’ve moved to EAP-TLS.
Do I need to restart after changing the value?
Microsoft says no. If the connection still fails, disconnect and reconnect, then restart as a second step.
Does this affect Macs, iPhones or Android phones?
No. The change is in Windows. Those devices still connect with PEAP-MSCHAPv2, which has its own known weaknesses.
We checked Microsoft KB5066470 (revised October 19, 2026), the KB5127648 release notes and reporting from The Register on October 20, 2026. Microsoft hadn’t listed this as a known issue on the KB5127648 page at that time. We did not reproduce the failure on our own network.
Related guides
Sources
- Microsoft KB5066470: Manage changes to NTLMv1 and prevent network issues
- Microsoft: October 13, 2026 update KB5127648
- The Register: Networking problems after the October 2026 Windows update (Oct 16, 2026)
- SCEPman: PEAP-MSCHAPv2 Wi-Fi fails after KB5127648 (vendor post)
Next step: check one affected PC for Event ID 4025 today, apply the Audit value only where it’s confirmed, and put an EAP-TLS migration date on the calendar.
