Microsoft Is Disabling NTLM by Default: What It Means, Why Kerberos Replaced It, and How to Prepare

NTLM (New Technology LAN Manager) has been a foundational Windows authentication protocol for more than three decades, dating back to 1993. It helped organizations transition away from older LAN Manager methods and supported early Windows networking where many environments were small, on-premises, and often operated without a centralized identity service.

That era is over. Microsoft has announced plans to disable NTLM by default in new Windows releases. While NTLM is not instantly removed from every environment, the message is clear: modern Windows security is moving toward stronger, ticket-based authentication such as Kerberos, aligned with today’s zero-trust expectations and cloud-connected networks.

Quick Recap: What NTLM Is and Where It Still Shows Up

NTLM is a challenge-response authentication protocol. Instead of sending a plaintext password across the network, it uses password-derived hashes to prove identity. This design was a major step forward in the 1990s, especially in workgroup-style networks and scenarios without a domain controller.

Even in modern Windows, NTLM has often remained as a compatibility fallback when Kerberos cannot be used. Common places where NTLM may still appear include legacy applications, older SMB file sharing configurations, cross-forest or misconfigured DNS scenarios, local account authentication to remote services, and systems that were never fully modernized to domain-based identity.

Why Microsoft Is Retiring NTLM (Core Security Reasons)

Microsoft’s decision is primarily about security. NTLM is widely viewed as incompatible with current threat models because its design enables attacks that are difficult to fully mitigate without replacing the protocol.

• Weaker cryptography and hash exposure risk: NTLM relies on hashing approaches that are far easier to brute-force and crack using modern GPU tooling and password-recovery techniques.
• Relay attacks: NTLM is notably vulnerable to authentication relay, where an attacker captures an authentication attempt and forwards it to another service to gain unauthorized access.
• Misfit for Zero Trust: NTLM was built for perimeter-based networks, not for continuous verification, conditional access, modern identity signals, and cloud-integrated policy controls.
• Operational drag and incident response complexity: NTLM usage can be scattered across endpoints and servers, making it harder to inventory, constrain, and audit in large environments.

Why Kerberos Replaced NTLM in Windows Domains

Kerberos became the preferred authentication protocol with Active Directory and remains the default in domain environments because it offers stronger security properties and better enterprise scalability.

• Ticket-based authentication: Kerberos uses time-limited tickets issued by a trusted Key Distribution Center (typically a domain controller), reducing repeated credential exposure.
• Mutual authentication support: Kerberos is designed to help prevent clients from authenticating to impostor services, which is a key weakness exploited in NTLM relay scenarios.
• Better enterprise interoperability: Kerberos fits centralized identity, delegation scenarios, and domain policy enforcement more cleanly than NTLM.

In practical terms, Microsoft’s direction is to keep Windows authentication aligned with modern platform improvements, including long-running efforts to eliminate older crypto dependencies. Security engineering teams have publicly emphasized “killing” legacy components over time because they increase risk and frustrate defenders.

What “Disabled by Default” Means for Organizations

Disabling NTLM by default does not mean every environment will immediately break, but it does mean organizations should expect:

• Legacy apps and devices that still require NTLM to fail authentication unless updated or reconfigured.
• File sharing and SMB access patterns using local accounts on non-domain machines to be more likely to hit friction.
• Increased urgency to identify NTLM usage and plan migration paths rather than relying on “it still works” compatibility.

How to Prepare: Practical Steps to Reduce NTLM Dependence

If you manage Windows endpoints, servers, or Active Directory, preparation should focus on visibility first, then controlled changes.

• Inventory NTLM usage: Identify which apps, servers, and devices still negotiate NTLM and why Kerberos is not being used.
• Fix Kerberos blockers: Common issues include DNS misconfiguration, missing or incorrect SPNs, time synchronization problems, and legacy service configurations.
• Modernize authentication paths: Where possible, move applications to Kerberos, modern AD-integrated auth, or supported modern identity options.
• Disable in phases: Many administrators recommend targeting individual servers or workloads first rather than attempting a domain-wide switch overnight.
• Maintain a fallback plan: For critical legacy dependencies, define an exception process with compensating controls, strict scoping, and monitoring.

Key Takeaway

Microsoft’s plan to disable NTLM by default marks the end of NTLM as a normal, expected authentication method in new Windows releases. NTLM was built for a different era. Today’s environments are hybrid, cloud-connected, and actively targeted by credential theft and relay techniques. Kerberos is the modern standard in Windows domains, and organizations that proactively migrate away from NTLM will reduce risk, simplify auditing, and align with Microsoft’s security roadmap.