Microsoft announced that it will disable the NTLM authentication protocol by default in future Windows releases due to security vulnerabilities. The transition plan includes three phases: first, enhanced auditing tools for identifying NTLM usage; second, the introduction of features like IAKerb and a Local Key Distribution Center; and third, the default disabling of NTLM in future releases while allowing manual re-enablement through policy controls. NTLM, introduced in 1993, will be replaced by more secure Kerberos-based authentication methods, aligning with Microsoft’s shift towards passwordless and phishing-resistant authentication approaches.
Why do we care?
Microsoft’s been saying they’re killing NTLM since 2023. What’s different now is they’ve published a timeline—three phases, ending with NTLM disabled by default in future Windows releases. But here’s the part they’re glossing over: the replacement technologies, IAKerb and Local KDC, aren’t actually shipping yet. They’re pre-release. Windows Server 2025 users are already reporting that Local KDC fails to start after cumulative updates. So Microsoft is deprecating a 30-year-old protocol before the thing that’s supposed to replace it actually works reliably.
Now, the security case is legitimate. NTLM vulnerabilities aren’t theoretical—there was a bypass discovered in January where attackers can crack NTLMv1 credentials offline. Russian threat actors have been exploiting NTLM flaws in active campaigns.
But here’s where MSPs get hurt: Microsoft’s own hardening documentation says—and I’m quoting—”total NTLM disablement in a domain is extremely challenging.” Legacy apps, printers, NAS devices, non-Windows systems—they all potentially depend on NTLM. And when Phase 3 hits and NTLM is off by default, your clients are going to do one of two things: either they’ll have authentication failures they don’t understand, or they’ll use the policy escape hatch to re-enable NTLM and stay vulnerable.
Either way, you’re taking the call. That call shouldn’t be free. NTLM auditing isn’t a patching task — it’s a paid discovery project with security and legal consequences. If you haven’t audited their NTLM dependencies, you’re doing emergency triage. If you have audited and they re-enable anyway, you need a risk acceptance document or you’re holding liability for a breach you warned them about. Without that paper trail, you’re not a trusted advisor — you’re the default defendant.
Start NTLM auditing now. Event IDs 4624, 8001 through 8004. Get that data into a SIEM or Azure Log Analytics. Build the inventory of what actually depends on NTLM before Microsoft forces the issue. The window between “auditing tools available” and “default disabled” is your project runway.