Microsoft's NTLM Retirement Roadmap: Build Your AD Migration Plan

What the 2026 roadmap says

On January 29, 2026, Microsoft described a phased move toward disabling network NTLM by default. The roadmap starts with auditing, adds capabilities intended to reduce compatibility gaps, and places default disablement in a future major Windows Server release and associated clients. It does not announce that every existing domain has already stopped using NTLM. Read Microsoft's roadmap and availability notes.

For a business, the planning decision is straightforward: find the dependencies while there is time to give them owners, budgets, and test windows. Treat feature dates as vendor rollout information and verify availability on the versions you operate before relying on them.

Find out why NTLM is still being selected

Microsoft's enhanced auditing for Windows 11 version 24H2 and Windows Server 2025 records NTLM activity from clients, servers, and domain controllers. The logs can identify the account, process, target, and reason for using NTLM. Documented reasons include a direct application request, a local account, an IP-address target, or an inability to contact a domain controller. See Microsoft's NTLM auditing reference.

Our recommendation is to use those observations as the beginning of an application inventory. A hostname without an owner is not an actionable migration plan. Ask who depends on the workflow, when it runs, what a failure would look like, and how the team will confirm that the replacement authentication behaves correctly.

Work through a small pilot first

Select a representative application with an available owner and a test environment. Agree the user journeys to exercise before changing policy: an ordinary sign-in, a scheduled job, remote access, and a recovery scenario where relevant. Record the authentication that actually occurs during each test rather than assuming that a successful screen proves the protocol changed.

• Baseline: document the workflow and current authentication evidence.
• Change: remediate the identified dependency with the application owner.
• Validate: repeat the workflow and check both functionality and authentication.
• Expand: move to the next agreed group of systems after reviewing the result.

A useful exception includes the affected application, a responsible owner, the reason it remains, the controls around it, and a review date. Avoid treating a successful pilot as permission to change unrelated systems. A warehouse integration and an office file service may have different operating hours, support arrangements, and recovery requirements.

Connect the migration to your AD security priorities

We recommend reviewing the business impact of remaining dependencies alongside the migration effort. Which accounts carry sensitive permissions? Which systems sit across a boundary you expect to be restricted? Which exceptions are attached to applications that the business could retire? Those answers help distinguish work that reduces meaningful exposure from work that only improves an inventory count.

An Active Directory penetration test can investigate selected authentication paths and validate their impact within an agreed scope. Pair that evidence with application compatibility testing and a production change plan. The deliverable should help your team decide what to fix first, who owns it, and how to confirm that the change worked.