For over three decades, NTLM has been the quiet workhorse behind Windows authentication in environments without Active Directory. On February 2, 2026, Microsoft formally announced a three-phase plan to disable NTLM by default across Windows... and for the first time, they have a real answer for workgroups. Here's what's changing, why it matters, and what IT teams need to do about it.

Writing this from the floor at Right of Boom in Las Vegas, where I've been putting these exact questions to the security pros and vendors here. The timing of Microsoft's announcement couldn't be better... NTLM deprecation is one of those topics where the gap between "officially deprecated" and "actually disabled in production" can stretch for years if you don't force the issue.

What Is NTLM?

NT LAN Manager (NTLM) is a challenge-response authentication protocol that Microsoft introduced with Windows NT in 1993. When a user tries to access a network resource, the server sends a random challenge, the client encrypts it using a hash derived from the user's password, and the server validates the response. No passwords ever cross the wire... just hashes and encrypted challenges.

NTLM comes in several versions. The original LAN Manager (LANMAN) authentication was notoriously weak. NTLMv1 improved on it but still used DES-based cryptography. NTLMv2, introduced with Windows NT 4.0 SP4, added HMAC-MD5 and a client challenge to defend against certain replay attacks. Despite these improvements, all versions of NTLM share fundamental architectural limitations that modern attackers routinely exploit.

The protocol's biggest weaknesses: no mutual authentication (the client can't verify the server's identity), susceptibility to relay and replay attacks, weak cryptographic foundations compared to modern standards, and vulnerability to pass-the-hash attacks where stolen password hashes can be used directly without ever knowing the actual password.

What Is Kerberos?

Kerberos is a ticket-based authentication protocol originally developed at MIT in the 1980s and adopted by Microsoft as the default authentication protocol for Active Directory domains starting with Windows 2000. Named after the three-headed dog of Greek mythology, Kerberos involves three parties: the client, the server, and a trusted third party called the Key Distribution Center (KDC).

The flow works like this: when a user logs in, their credentials are sent to the KDC's Authentication Service, which returns a Ticket Granting Ticket (TGT). When the user needs to access a resource, they present the TGT to the KDC's Ticket Granting Service, which issues a service ticket for that specific resource. The user then presents the service ticket to the resource server. The entire exchange uses symmetric and asymmetric encryption, supports mutual authentication (both sides verify each other), and enables single sign-on since the TGT can be reused across multiple resource requests.

Kerberos is superior to NTLM in nearly every way: stronger cryptography (AES-256), mutual authentication, SSO capability, better performance with fewer network round-trips after initial ticket acquisition, and support for delegation. There's one critical catch though... Kerberos requires a KDC, and in Windows environments, the KDC runs on a domain controller. No domain, no KDC, no Kerberos.

Why NTLM Has Persisted

If Kerberos has been the default since Windows 2000, why is NTLM still everywhere 26 years later? The answer comes down to three scenarios where Kerberos simply couldn't work.

Workgroup environments. Small offices, labs, and standalone servers that aren't joined to an Active Directory domain have no domain controller and therefore no KDC. Every authentication between workgroup machines falls back to NTLM. This is extremely common in small business environments... dental offices, law firms, medical practices... where deploying Active Directory is overkill for a handful of machines sharing a printer and some files.

No line-of-sight to a domain controller. Remote workers, VPN users, and machines that can't reach a DC on ports 88 and 464 can't complete Kerberos exchanges. The protocol silently falls back to NTLM, often without anyone noticing.

Legacy applications and devices. Older software that hardcodes NTLM in its authentication calls, network appliances, NAS devices, printers, and IoT equipment that never implemented Kerberos... all of these force NTLM fallback regardless of what the rest of the environment supports.

The result is that NTLM became a universal fallback. Even in well-configured Active Directory environments, a surprising amount of authentication traffic still uses NTLM. And attackers know it.

Microsoft's Three-Phase Deprecation Plan

On February 2, 2026, Microsoft published a formal roadmap for NTLM's retirement. NTLM was officially deprecated in June 2024 and no longer receives feature updates. NTLMv1 has already been removed from Windows 11 24H2 and Windows Server 2025. Now Microsoft is laying out the path to turning off NTLMv2 by default.

Phase 1 (Now): Enhanced auditing tools are available in Windows Server 2025 and Windows 11 24H2. These tools provide detailed telemetry on NTLM usage... which accounts, which processes, which machines, and which IP addresses are involved in NTLM authentication. The goal is to give organizations full visibility into their NTLM dependencies before anything gets disabled.

Phase 2 (H2 2026): Microsoft ships two new features designed to eliminate the most common reasons Kerberos couldn't be used: IAKerb and Local KDC. Core Windows components will also be updated to negotiate Kerberos first, reducing hardcoded NTLM usage within the OS itself. Additionally, in October 2026, Microsoft will change the default value of the BlockNTLMv1SSO registry key from Audit to Enforce.

Phase 3 (Next Major Windows Server LTSC): Network NTLM authentication will be disabled by default. Windows will ship in a secure-by-default state where NTLM is blocked. The protocol will remain in the operating system and can be re-enabled through Group Policy or registry settings, but it will no longer be the automatic fallback.

Solving Workgroups: The Local KDC

The most interesting piece of this plan for small business IT is the Local KDC... a machine-local Key Distribution Center that enables Kerberos authentication for local accounts without requiring Active Directory.

Today, when Machine A in a workgroup tries to access a file share on Machine B using a local account, the authentication must use NTLM because there's no KDC to issue Kerberos tickets. The Local KDC changes this by running a lightweight KDC service directly on each machine. Machine B's Local KDC can issue Kerberos tickets for its own local accounts, allowing Machine A to authenticate using proper Kerberos semantics without any domain infrastructure.

This is a fundamental shift. For the first time, workgroup environments can use modern, secure authentication without deploying Active Directory. The Local KDC handles the ticket-granting process locally, providing mutual authentication, modern cryptography, and resistance to relay attacks... all the benefits of Kerberos, without the overhead of domain infrastructure.

IAKerb: Kerberos Without Line-of-Sight

The second key technology is IAKerb (Initial and Pass-Through Authentication Using Kerberos). IAKerb addresses the scenario where a client can't directly reach a domain controller but can reach another server that can. That intermediary server proxies the Kerberos requests on the client's behalf.

This eliminates the other major NTLM fallback scenario: remote or disconnected clients that lose access to the DC. Instead of silently degrading to NTLM, the authentication can be proxied through any reachable server that has DC connectivity, keeping the entire chain on Kerberos.

What IT Teams Should Do Now

The timeline is generous, but the audit work should start immediately.

Enable NTLM auditing. If you're running Windows Server 2025 or Windows 11 24H2, turn on the enhanced NTLM auditing. The logs will show you exactly where NTLM is being used, by which accounts, and for what purposes. This is your dependency map. Inventory legacy devices. Printers, NAS appliances, scanners, specialty equipment... anything that authenticates to the network needs to be evaluated for Kerberos support. Devices that can't do Kerberos will need to be replaced, isolated, or covered by NTLM exception policies. Check your applications. Line-of-business applications that explicitly request NTLM (calling AcquireCredentialsHandle with "NTLM" instead of "Negotiate") will break when NTLM is disabled. The fix is usually straightforward... switching the call to Negotiate... but it requires the vendor to ship an update. Test in non-production. Before NTLM gets disabled by default, set up test environments with NTLM blocked and see what breaks. Better to find out in a lab than in production. Plan your exception policy. Even after Phase 3, NTLM can be re-enabled via Group Policy. Identify which systems will genuinely need exceptions and document why. The goal is to minimize the exception list, not eliminate it overnight.

What We're Doing at DTC

At DTC Inc., we're a managed service provider supporting around 500 clients and 8,500 endpoints across a range of industries... government contractors, accountants, transportation, manufacturing, dental and medical practices, with dental being the majority. Our client environments span the full spectrum of Windows identity: most run traditional Active Directory domains, a growing chunk has moved to Entra ID, and a smaller number still operate in workgroup configurations.

That mix is exactly why NTLM deprecation matters to us across the board... not just for the workgroup clients. Even in our AD environments, NTLM fallback is happening silently. Legacy line-of-business applications, older network devices, and misconfigured SPNs all create pockets of NTLM traffic that attackers can exploit for relay attacks and lateral movement. For our Entra ID clients, the shift away from NTLM aligns with the broader move toward modern authentication. And for the workgroup environments, Local KDC is the missing piece that finally makes NTLM elimination possible.

I'm going to propose that we don't wait for Microsoft to flip the switch for us. Once Local KDC ships in H2 2026, I want to disable NTLM across the board... proactively, on our terms, across all managed clients. The plan is straightforward: enable enhanced NTLM auditing everywhere now to map our dependencies, validate that Local KDC is enabled and functional on workgroup endpoints once it ships, ensure our AD and Entra ID environments are negotiating Kerberos cleanly, remediate or exception-list the stragglers, and then enforce the block via policy.

Why not wait? Because NTLM is actively exploited. Relay attacks, pass-the-hash, credential theft... these aren't theoretical risks. Every day NTLM stays enabled is another day the attack surface remains open. As an MSP responsible for the security posture of hundreds of organizations, including government contractors who need to meet CMMC compliance, we owe it to our clients to close this gap as soon as the tooling makes it viable. Not whenever Microsoft gets around to making it the default.

These are the kinds of questions I've been putting to the security professionals and vendors here at Right of Boom in Vegas this week. The consensus tracks with what Microsoft is signaling: the tools are almost here, the timeline is clear, and the organizations that move early will be in the strongest position. Waiting for Phase 3 to force your hand is a choice... and it's the wrong one.

The Bottom Line

NTLM has had a remarkable 33-year run, but its architectural limitations make it incompatible with modern security requirements. Microsoft's phased approach... audit first, provide alternatives, then disable by default... gives organizations a clear path forward. The Local KDC is the piece that finally closes the workgroup gap, making Kerberos viable everywhere Windows runs, with or without Active Directory.

The clock is ticking, but the tools are there. Start auditing now, and you'll be ready when the default flips.