From October 2026, Windows 11 24H2 and Windows Server 2025 will start blocking NTLMv1-derived credentials with no administrator lifting a finger, according to KB5066470. It is the first dated deadline in the retirement of NTLM. Microsoft announced the full plan on 29 January 2026, and it ends with network NTLM authentication blocked in the next major release of Windows Server and its client unless someone deliberately turns it back on. In between, during the second half of 2026, come IAKerb and the local KDC, built so that Kerberos can work where Windows still falls back to NTLM.
NTLM has shipped with Windows since 1993, and Kerberos took over as the default domain protocol more than twenty years ago. NTLM still turns up in almost every directory we audit at Hard2bit: on the file server someone reaches by IP address, on the printer that signs in to the domain, in the accounting package whose vendor folded years ago. Retiring it without cutting anyone off takes months, and the tooling to begin is already in Windows.
Why is NTLM still on a network that already runs Kerberos?
Kerberos demands what NTLM never asks for: a service name registered in the directory (the SPN), a domain controller reachable at that moment, and a client able to request a ticket. Whenever one of those is missing, Windows downgrades the negotiation and uses NTLM without the user noticing. Deploying Kerberos does not remove NTLM; it leaves NTLM in the cracks.
Microsoft has catalogued those cracks in the enhanced NTLM auditing shipped with current Windows versions, which records for every attempt the reason NTLM was chosen. That list of reasons is the inventory of causes an organisation has to fix:
- The target was given as an IP address instead of a name, so there is no SPN to look up (reason 7). In what we see, scripts, shortcuts to shares and backup jobs account for most of it.
- The target name is empty, cannot be resolved, or is duplicated in the directory (reasons 5, 6 and 8). Two services registered with the same SPN make Kerberos fail and the client drop to NTLM.
- A local account is authenticating instead of a domain account (reason 2). Local admin accounts and workgroup servers have no KDC to ask for tickets.
- The machine cannot reach any domain controller (reason 9): users on a VPN before sign-in, servers in a DMZ, machines reaching an internal resource from outside, or a branch office whose link is down.
- The application calls NTLM directly (reason 1). The culprits are old software, and some not so old, with the NTLM security provider hard-coded instead of Negotiate.
- Loopback authentication is in use (reason 10), which is common in services that call themselves, or a null session (reason 11).
A second group is missing from that list because Windows does not generate it: devices that speak nothing but NTLM, such as NAS units, multifunction printers, scanners that drop documents into shares, building management systems and industrial equipment with SMB integration. We have already looked at why EDR cannot see what happens on those devices; the same applies to NTLM, and they are the hardest to replace.
What Microsoft has announced and which dates matter
Microsoft formally deprecated NTLM in June 2024, as BleepingComputer reported at the time. Since then the plan has come out in pieces, and they are worth separating because they do not all affect the same systems.
NTLMv1 is gone from current Windows, but its credentials are not
Windows 11 24H2 and Windows Server 2025 removed the NTLMv1 protocol. What survives is a set of credentials derived from its cryptography, used by higher-level protocols such as MS-CHAPv2 on wireless and wired networks and in VPN deployments with single sign-on. KB5066470 introduces the BlockNtlmv1SSO registry value, with an audit mode and an enforce mode: audit, which logs event 4024 whenever those credentials are used, and enforce, which blocks them and logs 4025.
From October 2026 the default flips to enforce on devices where nobody has deployed the value. Where Credential Guard is enabled the change is moot, because Credential Guard already prevents that use, and Microsoft recommends it as the more complete protection.
Enhanced auditing answers who, why and where
KB5064479 describes the new events in the Microsoft-Windows-NTLM/Operational log. Clients record every outgoing NTLM authentication with the requesting process, the target and the reason (events 4020 and 4021); servers record every incoming one and whether it succeeded (4022 and 4023); domain controllers record all NTLM traffic in the domain, cross-domain traffic included (4030 to 4033).
Each pair has an informational and a warning variant, and warning means downgrade: NTLMv1, Extended Protection for Authentication not supported, or a missing message integrity check. The policies are on out of the box: 'NTLM Enhanced Logging' on clients and servers, and 'Log Enhanced Domain-wide NTLM Logs' on domain controllers.
Second half of 2026: IAKerb and the local KDC
IAKerb and the local KDC are the two capabilities Microsoft set out in its authentication roadmap and now places in phase two of the retirement. IAKerb lets a client with no direct path to a domain controller authenticate with Kerberos through a server that does have one, relying on Kerberos's own cryptographic guarantees to protect the messages in transit. The local KDC brings Kerberos to local accounts, with AES from the start. Between them they cover reasons 2 and 9 from the list above, which for now can only be worked around, not fixed.
Phase three: blocked by default
In the next major release of Windows Server and its client, NTLM will remain in the operating system, but network NTLM authentication will be blocked and will have to be re-enabled explicitly through new policies. Microsoft has not dated that release. What it has said is that phase one, the auditing phase, starts now, with tooling Windows already ships.
The objection: 'take NTLM away and half the network breaks'
We hear it on almost every project, and it is partly right. Blocking NTLM blindly locks out precisely the systems on the list of reasons above. A second, more considered objection follows: 'we already use NTLMv2, SMB signing is on and passwords are long; the residual risk does not justify the project'.
The first objection is not about whether but about how, and the how is the rest of this article. The second deserves a technical answer, because it rests on a mistaken idea of where the risk actually is.
What NTLM allows an attacker to do while it stays on
NTLMv2 improved on NTLMv1's cryptography but kept the design: a challenge from the server, a response from the client computed from the password hash, and no strong binding between that response and the server it was meant for. The families of abuse that keep turning up in incidents all follow from that.
Relay: the victim authenticates to the attacker, who forwards it on
The MSRC describes it like this: coerce a victim into authenticating to an arbitrary endpoint, then relay that authentication to a vulnerable target. Coercion arrives as a UNC path in an email or a document, as an RPC call to a server that answers with its machine account, or as a poisoned name on the local network. The preferred target is any service that accepts NTLM without requiring signing or channel binding: LDAP, the AD CS certificate authority, an Exchange server. Microsoft cites CVE-2023-23397 (Outlook against Exchange), CVE-2021-36942 (LSARPC against AD CS) and ADV190023 (WPAD against LDAP) as precedents.
In its December 2025 guidance on critical threats to Active Directory, Microsoft ranks authentication relay second among six threats, right after unpatched vulnerabilities, and describes it as the step that turns initial access into lateral movement and, at worst, full domain compromise.
Capture and offline cracking
Any NTLMv2 response an attacker manages to capture can be brute-forced without touching the domain again. With NTLMv1 the computation is trivial; with NTLMv2 it depends on the password, and the passwords on service and device accounts tend to be the oldest in the organisation. It is the same problem as the Kerberoasting we analysed in our piece on hybrid Active Directory attacks: the password leaves the network in a form that can be attacked at leisure.
Pass-the-hash
Under NTLM the password hash is the credential. Whoever extracts it from a compromised machine can authenticate as that user to any system that accepts NTLM, without ever learning the password. Credential Guard makes the hash hard to extract from memory and Kerberos with AES stops it being reused as a key; NTLM keeps the route open for as long as a single service still accepts it. How such compromised credentials are stolen and reused is covered in the glossary; what matters here is that the protocol is what makes it possible.
So the answer to the second objection is that SMB signing reduces relay on the service where it is applied and NTLMv2 makes cracking more expensive, but neither touches the rest. The risk lives in the service that was left unsigned, the device that only speaks NTLMv1 and the hash that leaves a compromised laptop, and none of the three is fixed by a longer password.
Auditing NTLM: which events to read and which questions to answer
The audit has to end with three answers: which accounts use NTLM, against which servers, and for what reason. Counting events without reaching those answers produces charts and little else.
The classic policies and event 8004
Since Windows Server 2008 R2 there have been three policies under Security Options that log without blocking: 'Audit Incoming NTLM Traffic', 'Audit NTLM authentication in this domain' and 'Outgoing NTLM traffic to remote servers' in audit mode. They write to the same NTLM operational log and, on domain controllers, produce event 8004, the one Microsoft Defender for Identity consumes to enrich its alerts. The documentation for the domain policy warns that the log can grow quickly; size it before choosing 'Enable all'.
Enhanced auditing: filter by reason
On current Windows versions the useful detail lives in events 4020 to 4023 and 4030 to 4033. A query that groups 4020 and 4021 by the reason field and by process answers with reasonable precision how much of the network's NTLM comes from IP addresses, how much from local accounts and how much from specific applications.
Events 4022 and 4023 on each server show who still arrives over NTLM at that system, and 4032 and 4033 on the domain controller cover the whole domain. The warning events, the odd numbers, go to the front of the queue.
Centralise, or lose the signal
These logs do not reach the SIEM on their own: the Microsoft-Windows-NTLM/Operational channel is not part of the Security log and has to be collected explicitly. The criteria for which sources to send to the SIEM and for how long are set out in another article; this channel belongs in the high-priority tier for the duration of the project and can be demoted once it ends. Without centralisation the audit degenerates into Event Viewers opened one machine at a time.
Retiring NTLM in phases without cutting anyone off
Order matters more than speed. Before the protocol is blocked, take relay away from the attacker, because relay is what does damage right now and it does not depend on NTLM disappearing.
First, close relay while NTLM is still on
- SMB signing required on servers and clients. Windows 11 24H2 and Windows Server 2025 already require it by default; earlier versions need the policy.
- LDAP signing and channel binding on domain controllers. Windows Server 2025 enables channel binding by default in 'when supported' mode, according to the MSRC; the goal is 'always' as soon as no legacy clients remain.
- Extended Protection for Authentication on AD CS, Exchange and IIS. Exchange 2019 CU14 and the AD CS role on Windows Server 2025 ship with it enabled; earlier versions, and IIS in every case, need it switched on manually.
- Disable LLMNR, NBT-NS and WPAD proxy auto-discovery, and block outbound SMB to the internet at the perimeter. With no names to poison and no UNC paths leading outside, coercion loses its easiest routes.
Second, fix the causes by reason
Each reason in the enhanced audit maps to an action. Connections by IP are fixed by replacing the address with a DNS name that has a registered SPN, and duplicate SPNs by cleaning the directory. Local admin accounts are brought under LAPS and used only at the console, pending the local KDC.
Users who cannot reach a controller need a VPN that comes up before sign-in, or IAKerb once it ships. Applications that call NTLM directly need a conversation with the vendor and, failing a fix, isolation. Devices that only speak NTLM are replaced, or confined to their own segment with a dedicated account that cannot be used anywhere else.
Third, block by scope, with exceptions
The same policies that audit have a blocking counterpart, and two of them accept lists of exceptions by name: the one for outgoing traffic to remote servers and the one for authentication in the domain. The incoming-traffic policy on a server has no exceptions; that server denies NTLM to everyone or to no one. The lowest-risk order starts with privileged accounts: adding them to Protected Users stops them authenticating with NTLM (and imposes other restrictions besides), and it is the change with the best ratio of risk removed to disruption caused.
Next, deny incoming NTLM on domain controllers, then on application servers one at a time, with the exceptions the audit justifies loaded into the domain policy or the clients' outgoing policy, and finally deny it domain-wide for domain accounts. Every step goes out with its rollback policy ready and with the SOC warned that the authentication failures of that week may be the project and not an attack.
For what cannot be fixed, a documented exception with an expiry date and an isolated system is acceptable; an exception with no owner becomes the network's permanent NTLM. And the hardening of a server is not the hardening of the domain: authentications coerced from that server or from its users can still be relayed to any other service in the domain that accepts NTLM.
What must be done by October, and what can wait for the next Windows release
Before October 2026 the 4024 events on every machine running a current Windows version need reviewing, because they are the closest thing to a list of what will stop working when BlockNtlmv1SSO flips to enforce. Usually that means Wi-Fi and VPN with MS-CHAPv2 and single sign-on. The fix is EAP-TLS with certificates; failing that, at least warn users that, from that update onwards, they will have to type their password.
There is no date for the Windows release that will block NTLM by default, and that is an advantage: the auditing and the fixing of causes can be done without a deadline forcing the pace. What makes no sense is waiting for the date to start, because the three audit answers take weeks to settle and the fixes that depend on vendors take months.
Technical leadership has to name a project owner, set an exception criterion and accept that for a few weeks the NTLM log will be one of the most consulted sources in the organisation. At Hard2bit this work sits within our infrastructure and network security audits, because the inventory of NTLM and the inventory of services without signing or Extended Protection are the same document.
Retiring network NTLM does not make a domain immune. It does deny the attacker one of the techniques we have most often watched turn one compromised laptop into a compromised domain, and the ownerless exception left at the end of the project will, given time, be the only NTLM the attacker needs.
This article is for general information. The policies, registry values and events described come from Microsoft's public documentation as at 4 September 2026; the dates in the NTLM retirement timeline are those Microsoft has published, and Microsoft itself describes them as tentative. Any change to authentication policy should be tested in a limited scope, with a rollback path and with the operations team informed, before it is applied to the domain.
