Microsoft is pushing forward with replacing NTLM and intends to consistently prioritize Kerberos. A three-phase plan is designed to first create transparency, then ease migration, and ultimately block NTLM by default in a future Windows generation.

Microsoft is pushing forward with replacing NTLM and prioritizes Kerberos with a three-phase plan

Microsoft is now turning the long-anticipated replacement of NTLM into a concrete roadmap. According to recent reports, the transition is meant to be managed in a controlled way so that organizations can identify dependencies and move workloads to Kerberos without disruption. The framework is outlined as a three-phase plan, as The Hacker News summarizes, citing Microsoft’s Tech Community communications.

What stands out most is the strategic approach. Microsoft ties its security objective to a migration logic that acknowledges operational reality. In many environments, NTLM was not an “active choice” but has historically persisted as a fallback. That implicit availability makes it difficult to contain risk cleanly, because NTLM usage often hides in edge cases, such as older applications, devices, or integrations that do not negotiate Kerberos reliably. The three-phase plan addresses this by prioritizing visibility and replacement paths first and only then tightening the default configuration.

What the three-phase plan entails

The target state is a Kerberos-first world in which NTLM is no longer used automatically as a fallback. In the first phase, the focus is primarily on visibility so that security and infrastructure teams can reliably determine where NTLM is still in use and which systems depend on it. In addition, Kerberos is intended to be prioritized more consistently so that unnecessary NTLM usage disappears from the default path. In practice, this means organizations need to make their authentication flows measurable rather than relying on assumptions. Only once it is clear which clients, services, accounts, and endpoints trigger NTLM can the replacement be planned in a risk-driven way.

The second phase is positioned for the second half of 2026 and names mechanisms such as IAKerb and Local KDC as building blocks to mitigate typical fallback scenarios. The focus is on making Kerberos more robust in situations where NTLM is often used today for compatibility reasons. This matters operationally because many incidents are not caused by “Kerberos itself,” but by environmental conditions such as name resolution, time skew, missing or incorrect Service Principal Names, and identity-related edge cases. Further context on how Microsoft is balancing migration and compatibility is discussed, among others, by Petri.

In the third phase, NTLM is expected to be blocked by default in a future major Windows Server release and the corresponding Windows client versions. The key distinction is between being blocked by default and being fully removed. Microsoft reportedly clarifies that re-enabling via policy should remain possible, even if intended only as an exception path. heise security points this out and also notes that no definitive date for the final transition has been announced. For organizations, governance therefore becomes central, because any exceptions will need to be more deliberately justified and controlled.

Why Microsoft continues to push NTLM back

NTLM has long been under scrutiny because it is repeatedly abused in modern attack chains as a lever for credential abuse and lateral movement. Current secondary reporting cites relay, replay, and pass-the-hash scenarios in particular. Kerberos is regarded as the more robust standard in domain environments, yet NTLM remains active in many places as a fallback. Microsoft aims to systematically reduce precisely this residual usage before a default block becomes realistic and operationally viable. The security benefit stems less from “using Kerberos” in isolation and more from cutting off the automatic fallback path that can give attackers additional options in heterogeneous networks.

Where things can get tight in practice

Environments most affected are those in which NTLM persists not out of convenience but for technical reasons. This includes legacy applications with hard-coded protocol choices, integrations with incomplete Kerberos support, or scenarios where local accounts and special-case workflows bypass domain authentication. Added to that are technical prerequisites that can make Kerberos more sensitive than NTLM, such as inconsistent DNS configurations, SPN issues, or time synchronization problems. The roadmap explicitly addresses these edge cases through a transition phase intended to ease migration before the default block takes effect.

Assessment and next steps for security and operations

From a security perspective, the move is consistent because it removes a historically vulnerable surface from the default path. Operationally, however, preparation determines success. Organizations that inventory NTLM usage cleanly now, enforce Kerberos-first technically, and document exceptions deliberately will significantly reduce later migration pressure. That Microsoft views the change as a long-term hygiene effort is also reflected in coverage by current tech media, for example Windows Central, which frames the initiative as moving away from a security relic.

For practical execution, the path can be translated into a small set of resilient work packages that security and operations need to carry jointly.

• Make NTLM usage measurable and clearly attribute root causes so dependencies do not only surface during incidents.
• Increase Kerberos stability, especially around DNS, SPNs, and time synchronization, so “fallback for convenience” does not become “fallback out of necessity.”
• Prioritize legacy cases and define replacement paths with application owners instead of accepting permanent exceptions.
• Control exceptions strictly via policies and time-limit them so a re-enable does not become the new standard practice.