Microsoft will audit and then begin enforcing a block on NTLMv1–derived credentials in Windows 11, version 24H2 and Windows Server 2025: the change is gated by a new registry key (BlockNtlmv1SSO), exposes two new NTLM event IDs for Audit vs Enforce behavior, and will be rolled out in phases starting with auditing in late August/September 2025 and moving to a default Enforce posture for unmanaged devices by October 2026. e what Microsoft changed, why it matters, who is affected, how to detect NTLMv1–derived usage in your environment, and a practical step‑by‑step plan (inventory → audit → remediate → enforce) you can follow to prepare and avoid outages.
What Microsoft changed (short summary)
- The NTLMv1 protocol has been removed in Windows 11 24H2 and Windows Server 2025, but some NTLMv1–derived cryptographic operations can still be requested in specific scenarios; Microsoft is introducing a controlled mechanism to audit and then block those NTLMv1‑derived credentials (for example, when certain authentication mechanisms derive NTLMv1 data).
- A new REG_DWORD registry value was adnder HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Setting 0 = Audit (default), 1 = Enforce/block. When Audit is active the OS will write Event ID 4024 (warning) but allow authentication; when Enforce is active the OS will write Event ID 4025 (error) and block the request.
- Microsoft publishes new operational logging under Microsofional to make detection actionable.
- Devices that have Windows Credential Guard enabled are already protected from Naphy; the new behavior applies only where Credential Guard is not enabled. Microsoft recommends Credential Guard where feasible.
- NTLMv1 uses weak, outdated cryptography (DES-based constructions and other lehas well-known relay and replay weaknesses; Microsoft’s move eliminates remaining NTLMv1 usage paths that would otherwise remain as downgrade/relay vectors. The change reduces the attack surface and closes classes of privilege‑escalation and credential‑theft risk that have been exploited in the wild (including issues tracked in recent advisories).
- Even though the NTLMv1 protocol was removed, some Windows operations could still produce or rely on NTLMv1–derived credes MS‑CHAPv2 interactions or legacy SSO fallbacks); the BlockNtlmv1SSO mechanism is specifically aimed at these derived‑credential scenarios.
- Registry (new key):
- Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Ntlmv1SSO - Type: REG_DWORD
- Value data:
- 0 (default) — Audit mode: requests to generate NTLMv1‑derived credentials are logged (Event ID 4024) but allowed to succeed.
- 1 — Enforce mode: requests are blocked and generate Event ID 4025.
- Event logs:
- Log channel: Microsoft-Windows-NTLM/Operational (Applications and Services Logs).
- Event ID 4024 — Warning: “Auditing an attempt to use NTLMv1‑derived credentials for Sies fields: target server, supplied user, PID, process name, LUID, mechanism OID, etc.). Use this while in Audit mode to discover impacted clients/apps.
- Event ID 4025 — Error: “An attempt to use NTLMv1‑derived credentials for Single Sign‑On was blocked due to policy” (same payload fields; indicates blockage when Enforce mode is active).
- Credential Guard: s enabled, the device is considered protected and the new BlockNtlmv1SSO changes do not apply to that device. Microsoft strongly recommends enabling Credential Guard where possible as an immeeployment timeline (absolute dates)
Microsoft’s published rollout timeline (absolute dates) is important for planning: - Late August 2025: Auditing logs (Event ID 4024) enabled for Windows 11 24H2 clients. This lets administrators detect NTLMv1‑derivet breaking functionality.
- November 2025: Begin rollout to Windows Server 2025 (server-side rollout begins later in 2025).
- October 2026: If BlockNtlmv1SSO is not set on a device, Microsoft will change the default behavior to 1 (Enforce) for unmanaged devices — meaning NTLMv1‑derived SSO requby default on devices that did not have the registry key proactively deployed. (This is the critical uld have audited and remediated any usage.)
- Domain‑joined and non‑domain devices that rely on legacy mechanisms which implicitly generate NTLMv1‑derived credentials (examples include certain legacy VPNs, RAS/PPP or MS‑CHAP‑related flows, or very old appliances and appliances bridging authentication).
- Any environment where ard cannot be enabled: these devices will experience the Audit→Enforce change unless you explicitly deploy BlockNtlmv1SSO=0 (audit) or set it to 1 earlier under your baseline.
- Applications and services that perform SSO via mechanisms that can fall back to NTLMv1‑derived credentials — Audit period.
1) Turn on and configure the NTLM operational log:
- In Event Viewer: Applications and Services Logs → Microsoft → Windnal → Right‑click → Enable Log.
- Or from an elevated command prompt (example):
wevtutil set-log Microsoft-Windows-NTLM/Operational /e:truent ID 4024 (Audit) while in Audit mode.
3) Inventory likely sources of NTLM / legacy authentication:
- Old VPN endpoints (especially appliance or - Line‑of‑business apps that were never modernized and rely on NTLM fallbacks.
- Printers, NAS devices, or appliances that authenticate using legacy mechanisms.
- Third‑party services (legacy NFS/SMB gateways, older AD‑integrated appliances).
Many community reports and aggress that vulnerable appliances and older apps are the usual culprits — inventory these first.
- Audit domain controllers for NTLM authentication records (if you log Netlogon/LSA or use advanced auditing).
- Check for NTLM usage in network logs / WAF logs / reverse proxies. These are complementary to the NTLM operational log.
Follow a staged approach: Inventory → Audit → Remediate → Enforce. The Audit window (late 2025 through October 2026) is your chance to find and fix problems without causing outages.
Phase 0 — Preparation (now)
- Identify a small cross‑functional team (AD/domain admins, security/IR, application owners, network/VPN owners).
- Communicate the timeline and impact to stakeholders with exact dates (Audit begins Aug/Sep 2025; defaultgured begins Oct 2026). Use absolute dates when you notify teams.
- Run an inventory for endpoints, appliances, VPNs, and apps that perform legacy authentication. Prioritize on‑path network appliances and apps that predate 2010.
- Export a list of servers and appliances that might perform SSO or use MS‑CHAP/NTLM fallbacks.
- For each item, document owner, business criticality, and remediation options.
- Leave BlockNtlmv1SSO at default (0) so OS will audile Microsoft-Windows-NTLM/Operational and collect Event ID 4024 occurrences.
- Triage: map each Event ID 4024 to a device/application owner, reproduce the flow in test environments, and determine whether a change is possible (upgrade, reconfigure to use NTLMv2 or Kerberos, enable modern authentication, or replace).
- If you can’t immediately fix a dependency, create a documented exception plan (timeline to remediate, compensating controls such as network restrictions).
- For supported apps, reconfigure to use Negotiate/Kerberos or NT legacy but cryptographically stronger than v1; aim for Kerberos where possible).
- Update or replace appliances that cannot be reconfigured. Work with vendors to obtain updates that remove dependence on NTLMv1‑derived cryptography. Many vendors are already working on updates given public advisories.
- For short‑term mitigation where fixes are not possible, consider network segmentation, firewall rules, or host‑based controls to prevent risky NTLM flows to untrusted networks.
- After you’ve remediated the majority of findings, plan a staged enablement of BlockNtlmv1SSO=1 in test rings,en production. Use the operational log to ensure no unexpected 4025 events occur.
- Make sure domain controllers, AD‑integrated services, and other core infra are patched and validated before Enforce. Community reports eest widely to avoid breaking authentication for print servers, legacy SharePoint, or older RDP/RemoteApp setups.
- Set the recit):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f - Set the registry to Enforce (blocks NTLMv1‑derived):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d M operational log (example):
wevtutil set-log Microsoft-Windows-NTLM/Operational /e:true - Group Policy: centrally deploy the registry change via Computer Configuration → Preferences → Windows Settings → Registry (or use an AD administrative template that sets the same ker cloud‑managed devices.
- While BlockNtlmv1SSO is the new knob for NTLMv1‑derived SSO, organizations should also look at Group Policy settings that affect general NTLM/LM behavior (e.g., LmCompatibilityLevel and “Network security: Restrict NTLM”) to further harden environments. Those settings are longstanding and still relevant as additional hardening layers.
- If your hardware, OS SKUs, and management posture allow, enable Windows Credential Guard (Virtualization‑based Security that isolates LSA/credential material). Devices with Credential Guard are not affected by the new BlockNtlmv1SSO changes (they’re considered protected). Microsoft’s KB and guidance strongly recommend Credential Guard where feasible; evaluate compatibility before enabling (some legacy drivers / software may be incompatible).
- Public advisories and CVEs (e.g., CVE‑2025‑21311 in the recent disclosures) highlight why Microsoft is accelerating NTLMv1 eradication: Mv1 can enable privilege escalation and practical credential‑theft/relay vectors. The changes described here are part of a multi‑year program to reduce legacy protocol risk and eliminate downgrade paths. If you have any systems that still rely on NTLMv1, treat them as high‑priority remediation targets.
- Enable BlockNtlmv1SSO=0 (audit) and enable NTLM operational logging. Collect 1–4 weeks of telemetry depending on environment.
-t ID 4024 source, confirm whether a reconfiguration, update, or replacement is possible. Document the remediation path. - Validate Kerberos functionality for services that should use it (SPNs, constrained delegation, clock sync).
- Plan remediation windows with application owners; avoid flipping Enforce during peak business hours.
- After remediation, test a pilot set of machines with Enforce=1; monitor for Event ID 4025 and business impact.
- Short term: maintain Audit mode for those machines and implement compensating controls (isolate the service, firewall rules limiting token forwarding, ensure MFA where possible).
- Long term: prioritize repladiation; legacy protocols like NTLMv1 will become blocked by platform defaults and represent an increasing operational risk. Community reports stress vendor coordination — contact vendor support early.
- Create SIEM alerts for:
- Repeated Event ID 4024 from many sources (indicates many apps/devices are still requesting NTLMv1-derived credentials).
- Any Event ID 4025 (blocked attempts once you test Enforce) — escalate promptly to application owners.
- High‑volume NTLM requests from devices that should be Kerberos-only (indicates misconfiguration).
- The new key and event IDs address NTLMv1‑derived SSO generation specifically; other NTLM‑related hardening (NTLMv2 restrictions, channel binding, EPA) remain separate but complementary efforts — you should treat them all as part of a single migration plan.
- Vendor appliances and somtware may require vendor patches that aren’t on the same schedule as Microsoft’s rollout. Expect to coordinate remediation timelines with vendors.
- Immedtion working group (AD + apps + security + network).
- Put the rollout dates in your change calendar (Audier rollout begins Nov 2025; default Enforce for unmanaged devices: Oct 2026). Use absolute dates in stakeurn on Microsoft‑Windows‑NTLM/Operational logging and collect for at least 2–4 weeks; triage Event ID 4024.
- Prioritize remediation of any system that still produces 4024 events (upgrade, reconfigure to Kerberos, or replace).
- Where possible, enable Credential Guard to get immediate protection for affected devices.
- Deploy BlockNtlmv1SSO=1 only after thorough testing and a staged rollout; do not flip to Enforce without verification.
- This briefing summarizes Microsoft’s support guidance (KB/technical artickNtlmv1SSO key, logging, and rollout dates) and corroborates those details with community/industry commentary and advisories about NTLM deprecation and recent NTLM‑related CVEs. For the Microsoft baseline and timeline, see the Windows support notice published Aug 29, 2025 (KB 5066470) and the associated NTLM auditing guidavisory reports that tracked the same rollout and CVE context are summarized in the materials we used to prepare thiwant, I can:
- Produce a short remediation runbook for your team with exact detection queries for Splunk/Elastic/ArcSight aO/Intune registry policy JSON for BlockNtlmv1SSO (Audit and Enforce), or
- Run through a samplk you step‑by‑step through triaging a real Event ID 4024 from collection to remediation (including what to ask vendors and what temporary mitigations to apply).
Source: Microsoft Support Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 - Microsoft Support
