🚀 New: chi (χ) — an open-source autoresearch harness for fleets of LLM coding agents. Read the announcement.
Kuldeep Pisda
Windows 11 Now Blocks NTLMv1 Single Sign-On by Default, and an Unset Registry Value Is the Switch

Windows 11 Now Blocks NTLMv1 Single Sign-On by Default, and an Unset Registry Value Is the Switch

Since the October 13, 2026 update, Windows 11 blocks NTLMv1-derived single sign-on unless BlockNtlmv1SSO says otherwise. Microsoft's docs say Wi-Fi, Ethernet and VPN profiles using MS-CHAPv2 may break. What the default change does, how to find affected devices, and what the documentation leaves unsaid.

4 min read

Contents

If your Windows 11 fleet signs in to Wi-Fi, wired 802.1X or VPN with an MS-CHAPv2 profile and “use my Windows credentials”, the October 13, 2026 cumulative update may have changed that behavior. KB5127648 changed the default of a registry value called BlockNtlmv1SSO from Audit to Enforce. Microsoft added the note to the KB page on October 15, two days after the release.

I have not tested this on a device. Everything below comes from Microsoft’s two pages, and I mark where I am inferring.

What the setting does

BlockNtlmv1SSO is a REG_DWORD under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0, documented in KB5066470. Microsoft says 0 is Audit mode and 1 is Enforce mode, and that no restart is needed after changing it.

  • Audit (0): a single sign-on request that uses NTLMv1-derived credentials is allowed. A warning, event 4024, is logged to Microsoft-Windows-NTLM/Operational.
  • Enforce (1): the request is blocked. Event 4025 is logged as an error: “An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy.”

This is narrower than turning off NTLMv1. It governs whether Windows will hand the user’s stored credentials to higher-level protocols for SSO when those credentials are NTLMv1-derived. Microsoft’s example is MS-CHAPv2, including PEAP-MSCHAPv2 and EAP-MSCHAPv2, where “remnants of NTLMv1 cryptography are still present.” Manually typed credentials keep working in Enforce mode, per the KB.

The default is the part to read twice

The October 13 update does not write the value. The KB says Enforce becomes the internal default when the value is not set, and only on devices where Credential Guard is disabled. With Credential Guard on, “these changes do not take effect.”

That has a consequence for how you check a fleet. Looking for BlockNtlmv1SSO = 1 in the registry finds only machines someone configured on purpose. The machines affected by the new default are the ones where the value does not exist. A compliance query that treats a missing value as “not enforcing” will report the opposite of what the OS is doing. I read the KB as implying this but it does not spell it out, so confirm it on a pilot device by reading the 4025 events rather than trusting a registry scan.

Setting the value to 0 explicitly restores Audit behavior. Microsoft calls that a “scoped, temporary security exception” because it reduces protection, and recommends deploying Credential Guard where the hardware and OS requirements are met.

Finding the dependency before users do

The audit side has been running for a while. Per KB5066470, NTLMv1 usage auditing was enabled in late August 2025 on Windows 11 24H2 and newer clients, and rolled out to Windows Server 2025 starting November 2025. If you collect Microsoft-Windows-NTLM/Operational, event 4024 history tells you which devices were already relying on NTLMv1-derived SSO and, by timestamp, which network or VPN profile triggered it. After the update, the same devices will log 4025 instead.

The user-visible symptom in Enforce mode is not a hard failure. The KB says SSO flows for these protocols stop working while manual entry still works. I would expect that to show up as credential prompts on connections that used to be silent, rather than as dead links, but the documentation does not describe the prompt behavior, so treat that as my inference.

Triage order that follows from the documentation:

  1. Search collected logs for 4024 and 4025 on Windows 11 24H2, 25H2 and 26H2 devices, the versions listed on KB5127648.
  2. List Wi-Fi, Ethernet and VPN profiles that use PEAP-MSCHAPv2 or EAP-MSCHAPv2 with Windows-credential SSO.
  3. For each, decide between moving the profile to a method that does not derive from NTLMv1, enabling Credential Guard on the device, or setting BlockNtlmv1SSO to 0 for a named, time-limited group.

What the documentation does not say

Several things I could not find in either page:

  • Whether the change applies identically to every listed Windows 11 version. KB5127648 lists 24H2, 25H2 and 26H2 but does not say the NTLMv1 note applies to each.
  • What the default is when the value is absent on earlier builds. The KB says only that the October update makes Enforce the internal default for eligible devices.
  • Which specific non-MS-CHAPv2 flows, if any, are affected. The KB gives MS-CHAPv2 as the example, not as an exhaustive list.
  • Why MS-CHAPv2 still depends on NTLMv1 derivation. The KB asserts it without a technical explanation.

If you run an 802.1X or VPN estate, the cheapest check is the one Microsoft built in: look for 4025 on a pilot group this week, and look for 4024 history before that.

Sources