KB5127648 and NTLMv1: Why PEAP-MSCHAPv2 Wi-Fi, LAN and VPN Stopped Connecting and How to Fix It for Good

The short answer

Since KB5127648, the October 2026 cumulative update for Windows 11 24H2, 25H2 and 26H2, Windows blocks NTLMv1-derived credentials for single sign-on by default. Windows Server 2025 gets the same change with its October 2026 update. On devices without Credential Guard, Wi-Fi, Ethernet (wired 802.1X) and VPN connections that use PEAP-MSCHAPv2 or EAP-MSCHAPv2 with Windows credentials no longer connect automatically.

Setting the registry value BlockNtlmv1SSO to 0 restores the old behavior for now. The permanent fix Microsoft recommends is certificate-based authentication with EAP-TLS.

TL;DR

• What changed: Windows now enforces BlockNtlmv1SSO on every device where an admin hasn't configured it. Microsoft announced this in Message Center post MC1508562 and documents it in KB5066470.
• Who is hit: Devices without Credential Guard that use MS-CHAPv2-based single sign-on, typically domain-joined Windows clients.
• Quick workaround: Set BlockNtlmv1SSO to 0. Microsoft itself says the setting should not be used long-term.
• Permanent fix: Move to EAP-TLS. With SCEPman you can do that without building an on-premises PKI.

What changed with KB5127648

Microsoft has been phasing out NTLM step by step. The latest step hits a protocol many networks still rely on every day: MS-CHAPv2. It is built on NTLMv1-derived credentials, and Windows no longer hands those out for single sign-on.

Microsoft announced the enforcement in Message Center post MC1508562, "Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard". The technical background is in KB5066470.

Microsoft calls this a planned security hardening change, not a known issue with the update. In other words, it is here to stay.

Are you affected?

You are likely affected if all of the following apply:

• Your devices run Windows 11 24H2 or later, or Windows Server 2025, with the October 2026 update (KB5127648 on Windows 11) installed.
• Credential Guard is disabled on those devices.
• Your Wi-Fi, Ethernet (wired 802.1X) or VPN uses PEAP-MSCHAPv2 or EAP-MSCHAPv2 with single sign-on. This is typically a domain-joined device with "Automatically use my Windows logon name and password" enabled.
• The BlockNtlmv1SSO registry value has never been set.

You are not affected by this change if your devices already use certificate-based authentication (EAP-TLS). Devices with Credential Guard enabled were already blocking this behavior, so password-based SSO was already broken there. The change is in Windows, so macOS, iOS, Android and Linux clients are not affected.

What it looks like

• Devices no longer connect automatically, and users get a credential prompt.
• Typing the password manually still works, but Windows can't save it for next time.
• Workflows that used to connect without user interaction stop working, for example shared or kiosk devices and VPN profiles that connect automatically.
• The client logs Event ID 4025 ("blocked") in Microsoft-Windows-NTLM/Operational. In Audit mode it logs Event ID 4024 instead.

The failure happens on the client, so your RADIUS or NPS logs may show little or nothing. Start troubleshooting on the endpoint.

How to check a device

# Is BlockNtlmv1SSO configured? (no value = Windows uses the new Enforce default)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# Has Windows audited (4024) or blocked (4025) NTLMv1-derived credentials?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

The quick workaround: set BlockNtlmv1SSO to 0

You can put affected devices back into Audit mode. Windows then allows NTLMv1-derived credentials again and logs each use with Event ID 4024.

Command line

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

Intune remediation (run in system context)

# Detection script: compliant only if BlockNtlmv1SSO is explicitly set to 0
$v = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($v -eq 0) { exit 0 } else { exit 1 }

# Remediation script
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null

For domain-joined devices, use a Group Policy Preferences registry item with the same key, value name, type and data.

Why it's only a workaround

• It reopens a weak path. Microsoft says MS-CHAPv2-based endpoints "are subject to risks similar to those affecting NTLMv1" and advises that this setting "should be evaluated carefully and not used long-term."
• It doesn't help devices with Credential Guard. They block MS-CHAPv2 SSO regardless of this setting.
• Offline devices can't receive policy. Devices that have already lost network access may need a wired or guest network to get the setting.
• Uninstalling the update is not an alternative. It leaves your devices without the month's security fixes.

Use the workaround to buy time, give it a documented end date, and use that time to migrate.

The permanent fix: EAP-TLS instead of passwords

Microsoft recommends removing the dependency on MS-CHAPv2 and moving Wi-Fi and VPN connections to certificate-based authentication with EAP-TLS. The device or user then proves its identity with a certificate and a private key instead of a password, and the private key can be protected by the TPM.

On top of fixing the outage, you get a better user experience and a stronger security posture.

Why so many networks still run on passwords

The protocol isn't the hard part. The PKI is. The classic setup includes AD CS, NDES, the Intune Certificate Connector, an application proxy, CRL publishing, high availability and patching. That's a lot of moving parts just to put a certificate on a laptop, and it's why many teams have postponed the move for years. More on this in Microsoft ADCS Alternatives in 2026.

How SCEPman takes the PKI out of the equation

SCEPman is an Azure-native certificate authority that runs entirely in your own Azure tenant, with keys in Azure Key Vault.

• Fast start: Deploy via Azure Marketplace, ARM template or Terraform. Most teams issue their first certificate in under an hour.
• Managed devices: Microsoft Intune, Jamf Pro and other MDMs issue and renew device and user certificates automatically via SCEP.
• Real-time validation: Certificates are bound to the user or device object and checked via OCSP. When an identity changes, access is revoked automatically.
• Works with your network: SCEPman supports Cisco and Meraki, HPE Aruba, Fortinet, Juniper and others, and works with your existing RADIUS server.
• No RADIUS servers needed: Combined with RADIUSaaS, you get a complete cloud-native solution for certificate-based Wi-Fi, LAN and VPN access.

Your migration path in six steps

1. Take inventory. Find out which SSIDs, wired 802.1X policies and VPN profiles still use MS-CHAPv2. Event IDs 4024 and 4025 show you which devices depend on it.
2. Buy time where needed. Set BlockNtlmv1SSO to 0 on critical devices, but document it and give it an end date.
3. Deploy SCEPman and distribute its root CA certificate, either through an Intune trusted certificate profile or through Group Policy.
4. Roll out certificates. Issue device certificates (and user certificates where needed) via Intune, Jamf Pro or other MDM SCEP profiles.
5. Switch over gradually. Enable EAP-TLS on your RADIUS server (NPS, your existing RADIUS or RADIUSaaS) alongside PEAP. Then move your Wi-Fi, 802.1X and VPN profiles to EAP-TLS one group at a time.
6. Clean up. Remove the MS-CHAPv2 policies, then set BlockNtlmv1SSO back to 1 or delete the value so Windows uses the secure default again:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f

Bottom line

Microsoft has made the decision: password-based network SSO via MS-CHAPv2 has no future on Windows. You can patch around KB5127648 for a few weeks, or you can use this moment to move to certificate-based access for good.

Boring PKI. Reliable certificates.

Try SCEPman for free

FAQ