Microsoft has deprecated every version of NTLM and plans to turn it off by default in the next Windows Server release, yet most estates still cannot say which applications, devices and service accounts depend on it. This guide is the programme view: the official roadmap and dates, the enhanced NTLM auditing added in 2025 and 2026, how to read it to map dependencies, the Kerberos features meant to replace the remaining NTLM cases (IAKerb, LocalKDC and Negotiate), and how to move from audit to block with an exception register. It is for Windows and identity architects, AD owners and application teams who will have to sign off the change. Relay controls such as SMB signing, LDAP channel binding and EPA are covered in the NTLM Relay Guide and are not repeated here.
Key takeaways
- Deprecated is not the same as disabled, yet. All NTLM versions have been deprecated since June 2024; NTLMv1 is removed from Windows 11 24H2 and Windows Server 2025, and NTLM is planned to be off by default in the next Windows Server and matching client release.
- The new audit events tell you why NTLM was used. NTLM Operational events 4020 to 4033 record the process, target and a reason code (IP address target, no DC line of sight, local account), which turns an inventory into a fix list.
- Most NTLM is accidental. IP address targets, missing or duplicate SPNs, local accounts and applications that call NTLM directly cause most of it; each has a known fix.
- Kerberos is getting new reach. IAKerb lets Kerberos work through the target service when a client cannot reach a DC, and LocalKDC gives local accounts Kerberos, both in preview during 2026.
- Block by layer, with owned exceptions. Restrict NTLM policies let you deny outgoing, incoming and domain NTLM separately, each with an exception list; every exception needs an owner and an expiry date.
The roadmap and what it means for you
Microsoft's deprecated features list states that all versions of NTLM, "including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated", that NTLM continues to work in the next Windows Server and next annual Windows release, and that calls to NTLM should be replaced by calls to Negotiate, which tries Kerberos first. A November 2024 update to that entry records NTLMv1 as removed from Windows 11 24H2 and Windows Server 2025. Microsoft's February 2026 message centre post MC1227478 and the Windows IT Pro blog post "Advancing Windows security: Disabling NTLM by default" set out three phases.
| Phase | When | What changes | Your action |
|---|---|---|---|
| 1. Visibility | Now (deprecation since June 2024; enhanced auditing from 2025) | Enhanced NTLM audit events on Windows 11 24H2 and later and Windows Server 2025; Server 2019 and 2022 gain them with updates from 13 October 2026 | Turn on enhanced logging everywhere and centralise it |
| 2. Kerberos reach | Second half of 2026 for Windows Server 2025 and Windows 11 24H2 and later | IAKerb, LocalKDC and upgrade of NTLM to Negotiate Kerberos | Pilot in non-production; re-test cases that previously had to use NTLM |
| 3. Off by default | Next Windows Server release and matching client | NTLM disabled by default, with support for remaining NTLM-only cases | Have dependencies fixed or exceptions documented before you deploy it |
Dates for phases 2 and 3 are Microsoft's plans as published in 2026 and may move; check the deprecated features page before committing a programme date. Separately, NTLMv1-derived credentials used for single sign-on in MS-CHAPv2 connections (PEAP-MSCHAPv2 and EAP-MSCHAPv2 for Wi-Fi, wired 802.1X and VPN) are blocked by default by the October 2026 security update on Windows 11 24H2 and later and Windows Server 2025 when the BlockNtlmv1SSO value is absent. Audit events 4024 (audited and allowed) and 4025 (blocked) record it, and the change does not apply where Credential Guard is enabled.
Enhanced NTLM auditing
The older Restrict NTLM audit policies show that NTLM happened. The enhanced events, documented in Microsoft support article KB5064479, show who, from which process, to which target, and why Kerberos was not used. They are written to Applications and Services Logs, Microsoft, Windows, NTLM, Operational, and are enabled by two Group Policy settings: NTLM Enhanced Logging (Administrative Templates, System, NTLM) for clients and servers, and Log Enhanced Domain-wide NTLM Logs (Administrative Templates, System, Netlogon) for domain controllers.
| Role | Information | Warning | Key fields |
|---|---|---|---|
| Client, outgoing NTLM | 4020 | 4021 | Process name and PID, user, target SPN, IP and name, Reason ID, NTLM version, channel binding, MIC status |
| Server, incoming NTLM | 4022 | 4023 | Process, remote client user, machine and IP, NTLM version, session key, channel binding, service binding |
| Domain controller, same domain | 4032 | 4033 | Client and server names, server OS, NTLM version, status code |
| Domain controller, cross-domain | 4030 | 4031 | As above plus forwarding DC secure channel type and far-side domain |
| NTLMv1 SSO (MS-CHAPv2) | 4024 (audit) | 4025 (error, blocked) | Flows using NTLMv1-derived credentials for SSO |
Warning events flag downgrades: NTLMv1, missing Extended Protection for Authentication, or no message integrity check. Treat warning events from privileged or computer accounts as security findings, not just migration data. Restrict read access to these logs: Microsoft notes that they map where legacy weaknesses are.
Reading the client Reason ID
| Reason ID | Meaning (KB5064479) | Typical fix |
|---|---|---|
| 1 | Called directly by the application | Developer change: call Negotiate (SPNEGO), not the NTLM package |
| 2 | Local account | Use a domain or managed account; evaluate LocalKDC when available |
| 4 | Cloud account | Review the sign-in path for that scenario with the platform owner |
| 5 | Missing or empty target name | Application or configuration fix to pass a proper service name |
| 6 | Target name not resolvable by Kerberos | Register the correct SPN on the service account; fix DNS aliases |
| 7 | Target name is an IP address | Use host names in shares, scripts, mappings and connection strings |
| 8 | Duplicate target name in Active Directory | Remove the duplicate SPN |
| 9 | No line of sight to a domain controller | Network path to a DC or KDC proxy; evaluate IAKerb |
| 10 | Loopback | Usually benign; confirm the process |
| 11 | Null session | Remove anonymous access requirements |
Mapping dependencies
- Collect: enable both enhanced logging policies by GPO or Intune, forward the NTLM Operational log to the SIEM, and keep at least one full business cycle (month-end, quarter-end, patch cycle) before drawing conclusions.
- Aggregate: group events by source process, account, target and Reason ID. Thousands of events usually collapse into a few dozen patterns.
- Attribute: give every pattern an application owner from the CMDB or service account register. NTLM from an unowned service account is itself a governance finding. See the Service Account Inventory Template.
- Classify: configuration fix (IP to name, SPN), application change (Negotiate), platform limitation (appliance, workgroup device, non-Windows client) or retire.
- Prioritise: privileged accounts, computer accounts, anything reaching tier 0, and any NTLMv1 or warning event first; long-tail workstation noise last.
- Track: report NTLM volume, distinct sources and open patterns monthly, by owner.
Microsoft's NTLM overview still notes that NTLM "must be used" for workgroup members and is used for local logon on non-domain controllers, so local and workgroup cases need their own plan rather than a domain GPO.
Moving workloads to Kerberos
| Dependency | Why NTLM is used | Route to Kerberos |
|---|---|---|
| Shares, scripts and apps addressed by IP or by an unregistered alias | Kerberos needs a resolvable service name with an SPN | Use the host name, register SPNs for aliases on the right account |
| Applications calling the NTLM package directly | Hard-coded protocol choice | Change to Negotiate, as Microsoft advises; vendor patch or replacement |
| Clients without a path to a DC (segmented networks, remote access) | No line of sight to a KDC | Open the required DC ports, a KDC proxy where supported, or IAKerb once released |
| Local accounts on servers and workgroup devices | No domain KDC for local identities | Domain-join or replace with managed identities; LocalKDC once released |
| Appliances, NAS, printers, older Linux or Java integrations | No Kerberos support, or keytabs not configured | Vendor firmware, Kerberos with AES keytabs, or isolate behind an exception. See the Linux Service Accounts and Keytab Management Guide |
| Cross-forest access over external trusts | Trust type or name suffix routing prevents Kerberos referrals | Forest trusts with correct suffix routing. See the Active Directory Trusts and SID Filtering Guide |
| Wi-Fi and VPN using PEAP-MSCHAPv2 SSO | NTLMv1-derived credentials | Certificate-based EAP-TLS, or Credential Guard where requirements are met |
IAKerb and LocalKDC
Microsoft opened an Insider preview of both in 2026. As described in the Windows IT Pro blog post "Reducing NTLM dependency: IAKerb and LocalKDC in Windows Insider Preview": IAKerb lets a client that can reach the target service but not a DC complete Kerberos with the service acting as the intermediary, so segmentation no longer forces NTLM; LocalKDC provides a Key Distribution Center for local accounts on Windows, covering workgroup, standalone and local-admin access that has always relied on NTLM. Both are preview features as of October 2026: test them, do not plan production on preview defaults, and expect Group Policy and MDM settings to arrive later. Kerberos brings its own controls to get right, from encryption types to delegation. See the Kerberos Security Guide and the Kerberoasting and AS-REP Roasting Defence Guide.
From audit to block
All Restrict NTLM settings live under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. Each has an audit counterpart and an exception list, and Microsoft's own best practice for each is audit first, add exceptions, then deny. None needs a restart, so rollback is a GPO change.
| Setting | Audit value | Enforce value | Exception policy |
|---|---|---|---|
| Outgoing NTLM traffic to remote servers (clients and servers) | Audit all | Deny all | Add remote server exceptions for NTLM authentication |
| Incoming NTLM traffic (servers) | Audit Incoming NTLM traffic set to the same option | Deny all domain accounts, or Deny all accounts (includes local accounts) | Add server exceptions in this domain |
| NTLM authentication in this domain (domain controllers) | Audit NTLM authentication in this domain: Enable all, or a narrower option | Deny for domain accounts to domain servers, Deny for domain accounts, Deny for domain servers, or Deny all | Add server exceptions in this domain |
| LAN Manager authentication level | Not applicable | Send NTLMv2 response only. Refuse LM and NTLM | None: remove NTLMv1 everywhere |
Phased rollout
- Prepare (month 0 to 2): enhanced logging on all DCs, servers and clients; inventory and owners; NTLMv1 removed by LAN Manager level; Credential Guard where hardware allows.
- Protect tier 0 first (month 2 to 4): deny incoming NTLM on tier 0 servers other than DCs (management servers, PKI, PAM), and outgoing NTLM from privileged access workstations, where audit is clean. These are the hosts whose NTLM use is most valuable to an adversary. See the Tiered Administration and Enterprise Access Model Guide.
- Ring the servers (month 4 to 9): deny incoming NTLM server group by server group, with a pilot ring of a few servers, then 10 per cent, then the rest. Watch 4023 and application errors for a week per ring.
- Clients (month 6 to 12): deny outgoing NTLM on a pilot user group, with the remote server exception list for named legacy targets.
- Domain-wide (when the exception list is short and owned): deny NTLM authentication in this domain, starting with Deny for domain accounts to domain servers.
- Roll back by GPO: keep the previous GPO version, revert one ring at a time, and record the cause as a new pattern to fix.
Decision guidance
- Small organisations: fewer apps and devices usually means you can audit for one cycle, fix IP addressing and a handful of appliances, and deny at the domain level within months. Do not wait for phase 3 to do it.
- Large estates: expect a long tail of appliances, mergers and acquisitions, and line-of-business apps. Block by tier and by direction instead of waiting for zero, and budget for vendor changes.
- Exception versus isolation: an exception lets NTLM continue to a named server. If the device cannot be fixed within a year, isolate it on a segment with only the flows it needs, so the exception does not widen the relay or pass-the-hash surface.
- Disable or wait for default: waiting for Microsoft's default means doing the same discovery under time pressure on upgrade. Doing it now lets you choose the order.
Where identity fits
NTLM accepts an account's NT hash as proof of identity, so every NTLM-capable account turns a stolen hash into a working credential. The accounts that linger longest on NTLM are non-human: service accounts in old applications, computer accounts reached by IP, scanner and backup accounts, and local administrator accounts. Fixing NTLM dependencies is therefore a service account programme as much as a protocol one: move services to managed accounts, randomise local administrator passwords with Windows LAPS, and record NTLM use as an attribute in the service account register. See the Service Account Security Guide and the Pass-the-Hash and Pass-the-Ticket Guide.
Detection and measurement
- NTLM share: NTLM authentications as a percentage of all domain authentications, from DC events 4030 to 4033 against Kerberos 4768 and 4769 volume, trending to zero.
- Distinct sources: count of distinct source processes and hosts per month; this falls faster and more honestly than raw volume.
- Warning events: 4021, 4023, 4031 and 4033 warnings (NTLMv1, missing EPA or MIC), target zero.
- Privileged NTLM: NTLM logons by tier 0 accounts or to tier 0 hosts, alerted in real time.
- Exception health: open exceptions, those past expiry, and those without an owner.
- Enforcement coverage: percentage of servers with incoming NTLM denied and clients with outgoing NTLM denied.
Common failure patterns
- Auditing only the DCs: DC events miss local account NTLM and workgroup traffic. Client and server enhanced logging is what finds the processes.
- Treating NTLMv2 as safe: NTLMv2 is deprecated too and still accepts a stolen hash. When hashes for admin, service and machine accounts leak, as in the Cisco Active Directory credentials leak, any server still accepting NTLM accepts them until the passwords change.
- Ignoring hash disclosure bugs: NTLM hash disclosure flaws such as CVE-2024-43451 and CVE-2025-24054 are in the CISA Known Exploited Vulnerabilities catalog. Patching them is necessary, but each new one is another reason to stop accepting NTLM at all.
- Exceptions with no owner or end date: the exception list becomes permanent and grows with every incident.
- Blocking before the business cycle: month-end batch jobs and annual processes surface after enforcement; audit for at least a full cycle.
- Forgetting the network team: PEAP-MSCHAPv2 Wi-Fi and VPN SSO fails from the October 2026 default if nobody checked events 4024.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK v20 | T1550.002 Pass the Hash; T1557.001 Name Resolution Poisoning and SMB Relay; T1187 Forced Authentication; mitigation M1042 Disable or Remove Feature or Program | Techniques that depend on NTLM being accepted |
| NIST SP 800-53 Rev. 5 | CM-7 Least Functionality; IA-2 Identification and Authentication; SC-23 Session Authenticity; AU-2 Event Logging | Removing a legacy protocol, stronger authentication, logging |
| NIST CSF 2.0 | PR.AA-03; PR.PS-01; ID.AM-08 | Authentication, configuration management, lifecycle of legacy systems |
| CIS Controls v8.1 | Control 4 Secure Configuration; Control 8 Audit Log Management | Disabling legacy protocols and collecting the evidence |
Practitioner checklist
- Enable NTLM Enhanced Logging and Log Enhanced Domain-wide NTLM Logs on every supported system, and patch Server 2019 and 2022 to get them.
- Forward the NTLM Operational log centrally and restrict who can read it.
- Group events by process, account, target and Reason ID, and assign every pattern an owner.
- Fix IP-address targets and SPN gaps first; they are the cheapest and most common causes.
- Set LAN Manager authentication level to refuse LM and NTLM (NTLMv1) and check events 4024 before the October 2026 enforcement.
- Ask every application vendor and internal developer for Negotiate support and a date.
- Pilot IAKerb and LocalKDC in non-production when available to you.
- Deny incoming and outgoing NTLM on tier 0 hosts first, then ring the rest.
- Keep an exception register with owner, reason, compensating control and expiry.
- Report NTLM share, distinct sources and exception health monthly.
Standards and references
- Microsoft Learn: Deprecated features in the Windows client
- Microsoft Windows IT Pro Blog: Advancing Windows security: Disabling NTLM by default
- Microsoft Support: Overview of NTLM auditing enhancements (KB5064479)
- Microsoft Support: Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025
- Microsoft Windows IT Pro Blog: Reducing NTLM dependency: IAKerb and LocalKDC in Windows Insider Preview
- Microsoft Learn: Network security: Restrict NTLM: Incoming NTLM traffic
- Microsoft Learn: Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
- Microsoft Learn: NTLM overview in Windows Server
Related NHI Mgmt Group resources: NTLM Relay Guide · SMB Signing Guide · Kerberos Security Guide · Active Directory Security Monitoring and Event IDs Guide