Windows 11 24H2 NTLMv1 SSO Block Enforces in 2026—Audit Now

Microsoft will flip a default switch in October 2026 that blocks single sign-on requests relying on NTLMv1-derived cryptography in Windows 11 24H2 and Windows Server 2025. The change is gated by a new registry key—BlockNtlmv1SSO—and introduces two dedicated event IDs so administrators can audit every attempted use before the block becomes permanent. The company published the roadmap on August 29, 2025, giving enterprises a 14-month runway to find and remediate any application or appliance that still leans on the obsolete authentication mechanism.

The clock started in late August 2025, when Windows 11 24H2 clients began logging audit events for NTLMv1-derived credential generation. Those events—ID 4024 warnings—are written to the Microsoft-Windows-NTLM/Operational log but do not interrupt user authentication. The companion Enforce mode, triggered by setting BlockNtlmv1SSO=1 or by the platform default after October 2026, elevates the event to an error (ID 4025) and blocks the request outright. The mechanism specifically targets NTLMv1-derived credentials, not the broader NTLM protocol, and applies only to devices where Windows Credential Guard is disabled. Machines with Credential Guard enabled are considered protected and are exempt from the new behavior.

The last gasp of NTLMv1—why a surgical block now

Microsoft removed the NTLMv1 protocol from Windows 11 24H2 and Windows Server 2025, meaning the OS no longer ships the legacy authentication provider. What many administrators may not realize is that NTLMv1-derived cryptography can still be requested indirectly, usually when a service or appliance invokes mechanisms like MS-CHAPv2 in a domain-joined context. These derived credentials use the same weak DES-based constructions that made NTLMv1 a favorite target for relay and downgrade attacks for two decades. Recent CVE entries, including CVE-2025-21311, underscore the urgency: leaving even a vestigial NTLMv1 path open creates a privilege-escalation and credential-theft vector that attackers can exploit once they have a foothold inside the network.

Community reports aggregated on Windows news forums and advisory channels consistently point to three categories of offenders: legacy VPN concentrators that negotiate MS-CHAP, older network-attached storage devices, and line-of-business applications that were built before Kerberos became the default Windows authentication method. These systems are often managed by separate teams or vendors, making them invisible to routine Active Directory audits. Microsoft’s staged approach—audit first, enforce later—is designed to smoke out exactly those hidden dependencies before they cause an outage.

The new registry key and event log schema

The single point of control is a REG_DWORD value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 named BlockNtlmv1SSO:

Both events land in the Microsoft-Windows-NTLM/Operational channel, which is not enabled by default. The event payloads include the target server, supplied user, client process ID and name, LUID, and the mechanism OID—fields that allow administrators to map a 4024 back to a specific application executable or service account. Community guides emphasize that the OID is especially valuable because it identifies the underlying protocol (e.g., MS-CHAPv2) that triggered the NTLMv1 fallback, giving remediation teams a direct clue about which configuration to fix.

Importantly, Group Policy does not have a native administrative template for BlockNtlmv1SSO yet. Organizations must deploy the value himself via Group Policy Preferences (Registry), Intune device configuration profiles, or custom scripts. The Microsoft support article confirms that Credential Guard—when correctly enabled and hardware-backed—provides equivalent protection by isolating the Local Security Authority subsystem in a virtualized container. On those devices, no NTLMv1-derived credential material is ever exposed, so the BlockNtlmv1SSO logic is bypassed entirely. For older hardware or guest VMs where Credential Guard cannot be enabled, the registry key becomes the mandatory safety net.

Rollout timeline: the dates that matter

Microsoft’s published schedule is deliberately gradual, but the hard deadline is unambiguous:

• Late August 2025 – Audit logging (Event ID 4024) begins on Windows 11 24H2 clients. No action required from administrators to receive the audit events, provided the NTLM operational log is enabled.
• November 2025 – The same audit behavior starts to appear on Windows Server 2025, introduced via a cumulative update.
• October 2026 – If the BlockNtlmv1SSO value is absent from a device’s registry, Microsoft will change its implicit default from 0 (Audit) to 1 (Enforce) through a future Windows update. “Unmanaged” in this context means any machine that did not have the key proactively set, whether domain-joined or not.

Note the qualifier “late August” and the shifting description from “September 2025” in the original article to the slightly earlier timeframe in the forum post; while the Microsoft KB states “September 2025 and later updates,” community sources tracking deployment rings reported seeing 4024 events as early as August 25–28, 2025. The variance stems from the phased rollout across geographic rings. The critical takeaway: audit telemetry may have already started flowing on some endpoints. If you have not yet enabled the NTLM operational log, do it today.

Who is affected—a practical checklist

Domain-joined workstations and servers that rely on any of the following are at risk of disruption after the enforce date:

• VPN or dial-up connections using MS-CHAPv2 as the authentication protocol, particularly with vendor appliances that lack a Kerberos or EAP-TLS alternative.
• Classic RADIUS/NPS deployments that proxy MS-CHAP authentication to Active Directory and inherit the NTLMv1 hash path.
• SMB clients connecting to very old NAS or Unix-based Samba servers that negotiate only LM/NTLM, forcing a downgrade that occasionally triggers NTLMv1-derived SSO.
• Old Oracle, SAP, or middleware connectors that embed Windows Integrated Authentication libraries from the Windows 2000/XP era.
• Print servers and multifunction devices that store credentials and re-authenticate users via NTLM—common in healthcare and manufacturing environments.
• Any service where Credential Guard is incompatible (common on VDI, older Hyper-V guests without nested virtualization, or systems using third-party security agents that hook LSA).

For each item, the forum guidance stresses the importance of involving the application or appliance vendor early. Many vendors already have patches in progress; some released firmware updates within weeks of the August announcement after community reports surfaced. Don’t assume a 2026 deadline means you can wait until 2026 to start.

How to discover NTLMv1-derived usage today

The detection path is straightforward and can be operationalized in a single afternoon:

1. Enable the NTLM operational log via an elevated command: wevtutil set-log Microsoft-Windows-NTLM/Operational /e:true or through Event Viewer. The log will begin filling immediately with existing NTLM authentication events, but the new 4024/4025 IDs specifically require a device that has already received the audit-side code.
2. Leave BlockNtlmv1SSO at default (0). No registry change is needed to receive 4024 warnings; the code built into the September/October cumulative updates writes them automatically.
3. Collect events for at least two to four weeks, spanning both business peaks and overnight maintenance windows where backup agents or scheduled tasks may authenticate.
4. Forward 4024 events to your SIEM and create a dashboard that groups by process name, target server, and mechanism OID. Out-of-the-box, Splunk and Azure Sentinel can parse the XML event data. Example query for Sentinel:
   kusto Event | where EventLog == "Microsoft-Windows-NTLM/Operational" and EventID == 4024 | extend ProcessName = tostring(EventData.Data[5]) | summarize count() by ProcessName
5. Triage each unique ProcessName against your configuration management database. The community recommendations emphasize that a single unexpected executable—say, a legacy Citrix Secure Gateway helper—can generate thousands of 4024 events per day.

Where the forum adds value beyond the Microsoft article is in its emphasis on cross-referencing with Active Directory NTLM audit policies. Enable “Audit Credential Validation” on domain controllers and look for Event ID 4776; if you see NTLM version information indicating v1, prioritize those targets immediately.

A phased remediation plan that avoids outages

The community drill-sheet breaks the work into four phases, mapped directly to Microsoft’s timeline:

Phase 0 – Preparation (now)

• Assemble a cross-functional tiger team: Active Directory admins, application owners, network engineers, and security operations.
• Put the hard dates (September 2025 audit start, October 2026 enforce switch) on the organization’s risk register and change calendar.
• Identify which endpoints cannot run Credential Guard (for example, 32-bit EFI systems or VMs on VMware versions older than 6.7) and flag them for special attention.

Phase 1 – Inventory & baseline

• Export a list of all VPN appliances, firewalls, load balancers, and network-attached storage that perform authentication.
• Cross-reference with the software asset management tool to flag applications older than 2010 that might use legacy Windows authentication libraries.
• Document owners, business criticality, and expected remediation roadmaps. The forum suggests creating a shared SharePoint list or Jira project visible to all stakeholders.

Phase 2 – Audit & triage (during the Microsoft audit rollout, now through early 2026)

• Let the OS audit in its default mode. Forward 4024 events to the SIEM.
• For each finding, attempt to reproduce the connection in a non-production lab with BlockNtlmv1SSO=1 to confirm that it will break.
• If an application cannot be reconfigured, file a support ticket with the vendor and attach the event details—many vendors require the mechanism OID to understand the exact fallback path.
• Create documented exception plans where immediate remediation is impossible, including compensating controls like network segmentation or local firewall rules that block the vulnerable traffic path.

Phase 3 – Remediation

• Reconfigure applications to use Kerberos wherever possible. For services that run under a user account, validate that service principal names (SPNs) are correctly registered and that constrained delegation is configured.
• If an appliance cannot speak Kerberos, check for a firmware update that transitions to NTLMv2 or EAP-TLS. Several major VPN vendors released NTLMv1-free firmware in Q3 2025, partly in response to community pressure on their support forums.
• For short-term workarounds on systems that will be decommissioned or replaced, set BlockNtlmv1SSO=0 explicitly and isolate them behind strict firewall policies until the replacement is live.

Phase 4 – Controlled enforcement

• Begin with a ring of IT-owned workstations in a separate OU. Deploy BlockNtlmv1SSO=1 via GPP registry preference and monitor Event ID 4025.
• Expand to non-critical user populations, then production servers, always allowing a 48-hour burn-in per ring.
• Once you have no unexpected 4025 events across a full business cycle, you can confidently let the October 2026 default enforce take effect for any remaining machines, or proactively roll out the key organization-wide.

Registry commands and GPO snippets you can copy

All commands assume an elevated Command Prompt or PowerShell session:

• Set Audit mode (leave allowed):
  cmd reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f
• Set Enforce mode (block NTLMv1-derived SSO):
  cmd reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 1 /f
• Enable NTLM operational log:
  cmd wevtutil set-log Microsoft-Windows-NTLM/Operational /e:true
  For group policy, create a Registry preference under Computer Configuration → Preferences → Windows Settings → Registry. Action: Update, Hive: HKEY_LOCAL_MACHINE, Key Path: SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, Value name: BlockNtlmv1SSO, Value type: REG_DWORD, Value data: 0 or 1. Item-level targeting can restrict the setting to devices where Credential Guard is absent—use a WMI filter that queries Win32_DeviceGuard and checks for SecurityServicesRunning containing 2.

Credential Guard: the better long-term play

Microsoft’s official guidance—echoed by every forum contributor—is to enable Windows Credential Guard if the hardware supports virtualization-based security and Second Level Address Translation (SLAT). Devices with Credential Guard active simply ignore the BlockNtlmv1SSO value; NTLMv1-derived credentials never touch the isolated LSA space. For organizations that can enforce Credential Guard across all managed endpoints, the 2026 deadline carries zero operational risk. The practical barrier remains compatibility: some VPN clients, legacy BIOS systems, and older drivers for smart card readers still conflict. Test Credential Guard enablement in a pilot ring before committing to a broad deployment.

Context: the CVEs that made this urgent

While NTLMv1 deprecation has been telegraphed for years, the August 2025 KB article was published within a month of Microsoft patching CVE-2025-21311 and related NTLM relay vulnerabilities. Those advisories demonstrated that even NTLMv1-derived material, when fed into an unconstrained delegation environment or a misconfigured certificate service, could escalate to domain controller compromise. The BlockNtlmv1SSO change closes that path at its source—the moment Windows considers generating a v1 hash. A community resource that many professionals reference is the “NTLM audit enhancements” documentation also published by Microsoft, which provides a broader view of how NTLM telemetry is evolving.

The operational reality: what the forums are already seeing

Within 48 hours of the late-August audit activation, posts on Windows management forums began surfacing 4024 events traced to surprising sources: a popular backup agent that authenticated using a legacy plugin, a hotel guest network’s captive portal that redirected Windows’ NCSI probes, and a medical imaging system that stored its own service credentials. In each case, the system continued to function normally (Audit mode permits the request), but administrators now have a documented, timestamped list of legacy dependencies they would not have otherwise uncovered until the 2026 cutoff broke production workflows. Several community members have already started sharing their remediation runbooks and SIEM queries, which will likely accelerate as the server-side audit rollout reaches Windows Server 2025 in November 2025.

Your next move

If you manage a Windows enterprise, open a command prompt now and type: wevtutil set-log Microsoft-Windows-NTLM/Operational /e:true. That single step starts the clock on your own visibility. Forward the stream to your central logging platform, and within a month you will have a data-driven inventory of exactly which systems still generate NTLMv1-derived credentials. With the enforce date set for October 2026, you have more than a year to remediate—but only if you start collecting evidence today. The alternative—waiting until the switch flips and reacting to help desk tickets—is a gamble that this generation of IT administrators no longer needs to take.