Microsoft retiring NTLM in Windows: Frequently asked questions

NTLM has been a loyal companion to Windows since 1993. It helped us log in and share files, but it also quietly fueled a generation of red-team demos and incident reports. We're grateful for the service. We're also, respectfully, showing it the door.

This FAQ collects the questions we hear most often from customers, partners, and the community as we move Windows to a Kerberos-first, NTLM-optional (and eventually NTLM-free) future. If you've emailed us, cornered us at a conference, or filed a support case that started with "so, about this weird auth thing…", chances are that your question is answered here.

If your question isn't answered here, please reach out to ntlm@microsoft.com or work with your Microsoft account team, Customer Success Account Manager, or Microsoft Support to route feedback to the product group.

Strategy, timeline, and roadmap​

What is "NTLMless"?
NTLMless is Microsoft's multi-phase effort to move Windows to a secure-by-default authentication posture by disabling NTLM as the default fallback and expanding Kerberos to cover the scenarios that historically forced NTLM usage. It is a platform shift, not a single feature or policy.

Why is Microsoft doing this now?
NTLM is deprecated and no longer under active feature development. It relies on weak cryptography, has no mutual authentication, and remains a leading vector for credential relay and pass-the-hash attacks that continue to drive real-world breaches. Reducing NTLM usage strengthens security posture and aligns with modern identity standards and post-quantum cryptography (PQC) readiness.

Is NTLM being removed or just disabled?
NTLM is being disabled by default, not removed outright. The underlying code will remain in Windows for a period after default disablement so administrators can re-enable it via policy for exceptional or edge-case scenarios where it's still required. Complete removal is a longer-term goal and will only happen after known dependencies have been addressed and viable Kerberos-based migration paths are broadly available.

When will NTLM be disabled by default?
Our current target for default disablement is the next major release of Server and Client (subject to change). Interim milestones (IAKerb and LocalKDC, enhanced auditing, blocking policies) will roll out ahead of that date. We publicly announced this direction in early 2026.

Does this mean NTLM will stop working on my existing Windows Server 2019/2022/2025 or Windows 10/11 devices?
No. Default disablement applies to the future release train. In-market versions of Windows client and Windows Server will continue to support NTLM. However, Microsoft strongly encourages customers to begin reducing NTLM usage now using the enhanced auditing and Kerberos improvements that are already shipping to supported versions of Windows.

What happens after NTLM is disabled by default? Can I re-enable it?
Yes, at least initially. When we ship default disablement, administrators will be able to re-enable NTLM via Group Policy or registry configuration to accommodate legacy applications and edge scenarios. Over time, as customer environments mature and dependencies are eliminated, the ability to re-enable NTLM will be narrowed. Our long-term objective is a Windows platform that doesn't need NTLM at all.

Kerberos enhancements replacing NTLM​

What is IAKerb?
Initial and Pass-through Authentication using Kerberos (IAKerb) is a Kerberos extension that lets a client authenticate to a Key Distribution Center (KDC) when the client does not have direct line-of-sight to a domain controller. The target server acts as a proxy, securely passing Kerberos messages between the client and the KDC. That matters most in the scenarios KDC Proxy was never really designed for: machine-to-machine SMB, standalone servers, and (paired with LocalKDC) local-account authentication where there's no domain KDC in the picture at all.

What is LocalKDC?
LocalKDC is a lightweight KDC embedded in Windows that issues Kerberos tickets for local accounts. It removes one of NTLM's longest-standing dependencies by allowing Kerberos to be used for local-account authentication in workgroup, non-domain-joined, standalone-server, small-business, and peer-to-peer.

Note: NTLM in the enterprise (domain accounts, lateral movement, relay, credential theft against high-value identities) and NTLM for local accounts are different risk profiles with different urgency. For most enterprises, the domain-account case is the one that shows up in your threat model, your pen test report, and your board deck. LocalKDC doesn't address that. The enterprise work is IAKerb, the SPN and DFS improvements, and the blocking policies covered elsewhere in this FAQ. LocalKDC closes a different, narrower gap: it means "local account" no longer automatically means "NTLM." That's real cleanup, but it's not the enterprise headline.

Click to expand...

When will IAKerb and LocalKDC be generally available?
Both features are currently available in Windows Insider preview builds. They will be generally available for Windows Server 2025 and Windows 11 in the coming months. Official release announcements will be made through the Windows IT Pro Blog and Microsoft Learn.

What about SPN, IP-address, and cross-domain scenarios where Kerberos historically failed?
These are the "stubborn" NTLM fallback cases, and they fall into two buckets: the ones we're fixing in the platform, and the ones only you can fix in your environment. Being honest about that split is important for your planning. These improvements are targeted for the same Windows Server and Windows client releases that brings default disablement.

What we're addressing in the platform:

• Domain-based DFS namespaces — historically a reliable source of NTLM fallback, because the client's target resolution and the referral path didn't line up with a Kerberos-resolvable SPN. We're addressing this so DFS access can stay on Kerberos end to end.
• Cross-domain and trustless scenarios, and broader, safer target-resolution behavior generally.

What you'll need to address yourselves:
We want to be direct here: we cannot fix missing, duplicate, or malformed SPNs in your directory. If a service account has no SPN, or the same SPN is registered on two accounts, or the client is requesting an SPN that doesn't match what's registered, Kerberos will fail and NTLM will pick up the slack. No platform change makes that go away. This is directory hygiene, and it is work that needs to start now rather than when default disablement lands.

The good news:
This is well-trodden ground with mature guidance. Start with Kerberos authentication troubleshooting guidance. To troubleshoot specific SPN failures, see Kerberos generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE error, which walks through finding the offending SPN with setspn -Q / setspn -X and correcting it.

What are the new NTLM blocking policies?
NTLM blocking is being consolidated into a centralized, policy-driven engine. Administrators will have consistent controls to allow, audit, block for single sign-on only, or block NTLM entirely using policies that consider account type, device state, target characteristics, and whether the request is SSO or credential-based. Stay tuned for more information on this one in the coming weeks!

Scope, impact, and compatibility​

Which scenarios may break when NTLM is disabled?
The most common failure patterns fall into four categories:

• Hardcoded NTLM: An application explicitly requests NTLM and does not attempt Negotiate/Kerberos. Auto-Redirect and application updates address most of these.
• Missing Kerberos prerequisites: The app uses Negotiate, Kerberos fails (missing SPN, IP address, no DC line-of-sight), and NTLM previously succeeded as fallback. IAKerb, LocalKDC, and SPN/IP support close these gaps.
• Legacy protocol / device dependency: The client talks to a legacy server, embedded device, or third-party appliance that only supports NTLM end-to-end. Vendor updates will be required.
• Local-account or special identity flows: The application authenticates using local accounts over the network. LocalKDC addresses the majority; a small subset (e.g., local interactive logon) is out of scope for LocalKDC.

Is NTLM only used on Windows endpoints?
Primarily, yes. NTLM is a Windows authentication protocol. However, non-Windows clients (macOS, Linux, Android, iOS, network appliances) can and do use NTLM when connecting to Windows resources such as SMB file shares, on-premises Exchange, or Windows-hosted web apps. This is especially common with third-party SMB clients, Outlook for Mac, and mobile device management scenarios. These clients will continue to work if they can negotiate Kerberos with the Windows server. The goal is to make Kerberos possible in more of these scenarios via IAKerb and LocalKDC.

What about cross-domain authentication without a trust?
Cross-domain authentication without a configured trust is a scenario that today requires NTLM. We're aware customers avoid cross-forest trusts for ransomware-containment reasons. This is one of the scenarios being addressed in the same Windows Server and Windows client release that brings default disablement so that trustless cross-domain authentication can succeed on Kerberos.

What about IP-address-based authentication?
Kerberos does not natively understand IP addresses, so authentication requests made using an IP address (rather than an SPN) fall back to NTLM. The single most important thing to know: do not wait for a platform fix here. Start auditing and eliminating IP-based authentication now. The majority of the transition is addressable today and every instance you remove is one less thing to unblock later.

Start here:

1. Audit it: Enhanced NTLM auditing will tell you not just that an IP address was used, but which process used it. That process name is your remediation worklist - it turns a vague "we have some NTLM" into a specific, assignable list of owners.
2. Fix hardcoded IPs in applications: This is consistently the largest bucket. In-house and line-of-business apps with connection strings, config files, or scripts pointing at literal IP addresses. Route them through DNS names instead. This is usually a configuration change, not a rewrite.
3. Educate users: \\10.1.2.30\share in a bookmark, a mapped drive, or a runbook is a small habit with a real cost. Names, not numbers.
4. Use TryIPSPN where you genuinely can't change the target: Windows supports IPv4 and IPv6 hostnames in SPNs when the client registry value TryIPSPN is set under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters, with the corresponding SPN registered via Setspn -s host/<ip.address> <account>.

Note: This must be set on each client that needs it, and IP-based SPNs should have static leases. See Configuring Kerberos for IP Address for the full procedure and caveats.

Click to expand...

What's left after that? Only the genuinely irreducible cases: targets you don't control, appliances that can't be changed, scenarios where no name exists. Those scenarios are what our in-flight work is designed for: effectively an allow list for Kerberos over IP address, scoped deliberately so it stays an exception rather than becoming the new default. The smaller you make that list through the steps above, the smoother your path to default disablement.

Will Microsoft apps still use NTLM after disablement?
No, Microsoft is running a broad internal effort to identify and remove hardcoded NTLM from first-party Windows components. This ensures Windows itself is not silently re-introducing NTLM through hardcoded paths and gives our components the benefit of Kerberos wherever possible.

Will there be a list of Microsoft apps still dependent on NTLM?
We don't plan to publish such a list. Our commitment is that Microsoft-owned dependencies are being fixed as part of the platform work. What matters for your environment is identifying NTLM usage (your own apps, third-party apps, appliances, and services). Enhanced NTLM auditing is designed specifically for this work.

Auditing, visibility, and discovery​

How do I find out where NTLM is being used in my environment?
Enhanced NTLM auditing is the recommended starting point. It's a major upgrade to the legacy NTLM event logging that has been available in Windows for years. The new events answer the three questions we hear most from customers:

• Who is using NTLM - the account, the machine name, the machine IP, and the process
• Why NTLM was used instead of Kerberos - including structured fallback reason codes (missing SPN, no DC line-of-sight, local account, IP address, hardcoded, etc.)
• Where the NTLM authentication is happening - both the source and the target of the request

Which Windows versions have enhanced NTLM auditing?
Enhanced NTLM auditing is available for Windows 11, versions 25H2 and 24H2 and Windows Server 2025. We are also working on bringing back enhanced auditing to Windows Server 2019 and Windows Server 2022.

What about NTLMv1 specifically. Is anything changing there?
Yes. NTLMv1 was blocked and rendered non-functional starting with Windows Server 2025 and Windows 11, version 24H2, with related changes rolling out through recent updates. NTLMv1-derived credentials are still used by some higher-level protocols (Wi-Fi, Ethernet, VPN via MS-CHAPv2), so SSO in those scenarios may be affected. See Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 for more details.

What you can do today​

How can I tell if my code is using NTLM?
Two ways. First, look at what your code says. Second, look at what it actually does at runtime. You need both sets of information because a lot of NTLM usage isn't explicitly requested; it's inherited by accident.

For explicitly hardcoded NTLM (the easy ones to find, once you look). search your source for the literal string NTLM and NTLMSSP. In most cases, the fix is the same one-line change: ask for Negotiate instead of NTLM. Negotiate will use Kerberos when it can and gives you a clean migration path; hardcoding NTLM guarantees you can't.

For accidental NTLM (the ones that hurt), you are looking for code that never mentions NTLM but gets it anyway. This can include:

• Connecting to a literal IP address rather than a hostname (no SPN, no Kerberos)
• Connecting to a target whose SPN is missing, duplicated, or malformed
• Passing explicit credentials where SSO with the ambient identity would work
• Reaching a target the client has no KDC line of sight to

To confirm what is happening at runtime, you have options. The NTLM Operational log records outgoing and incoming NTLM, and Security Event ID 4624 shows the authentication package used. Enhanced NTLM auditing goes further and surfaces the process and target behind each event, which is what converts a log into a fix list. Running the klist command on the client is a fast sanity check. If you expected Kerberos and there's no ticket for the target, you have your answer.

Where do I start?
Here is a pragmatic, phased approach that has worked well for early adopters:

• Audit: Turn on enhanced NTLM auditing on clients, servers, and domain controllers. Give yourself several weeks of data to establish a baseline and identify the top NTLM callers, most-used protocols (SMB, RPC, HTTP), and highest-volume scenarios (fallback reasons, IP-based auth, hardcoded).
• Prioritize: Group findings by root cause (e.g., missing SPN, hardcoded caller, legacy appliance) so you can remediate at scale rather than machine-by-machine.
• Remediate the easy wins: Register missing SPNs, retire NTLMv1, replace legacy scripts that hardcode NTLM, and pilot IAKerb and LocalKDC on the workloads where they help most.
• Pilot NTLM blocking: Use the ring-based approach (start with high-value/privileged accounts and non-critical services) and iterate outward.
• Engage vendors: For hardcoded-NTLM in third-party products, open cases with your ISVs so they can plan their own remediation. Auto-Redirect in Windows will help, but vendor cooperation makes the transition faster and safer.

Should I wait for IAKerb and LocalKDC to be generally available before starting?
No, you can start the audit and remediation work today with in-market Windows. Enhanced auditing is already available, Kerberos hygiene work (SPN registration, credential-guard adoption, NTLMv1 removal) can begin now, and legacy-app inventories almost always take longer than expected. When IAKerb and LocalKDC are broadly available, you'll be positioned to adopt them quickly.

What are the most common blockers other organizations report?

From our readiness survey and direct customer engagements, the top blockers are:

• Legacy applications and third-party devices/appliances with hardcoded NTLM or no Kerberos support.
• Application dependencies whose owners are hard to reach or slow to update.
• Lack of visibility into where NTLM is being used and why - the top single ask from customers is better reporting and diagnostics.
• Cross-domain and non-domain-joined scenarios that historically only worked with NTLM.
• Compatibility risk and the fear of causing an outage - which is why staged blocking, allow-lists, and audit-then-enforce modes matter.
• Time and resource constraints and competing IT priorities.

Are there organizations who have already reduced or eliminated NTLM?
Yes. Multiple enterprises are actively reducing NTLM! Several have reported cutting NTLM usage by more than 90%, and a small number have fully blocked NTLM. Common patterns among success stories: estates running the latest versions of Windows Server and Windows 11, a willingness to invest in enhanced auditing, executive sponsorship for tackling application dependencies, and a phased, ring-based rollout rather than a "big bang" switch.

Support, feedback, and escalation​

Where do I send NTLM-related questions or feedback to Microsoft
Email us at ntlm@microsoft.com. Please include details on the version(s) of Windows Server or Windows client you're running, a short description of the scenario or blocker, and whether you have enabled enhanced NTLM auditing. The team monitors this alias and prioritizes recurring themes for updating our public guidance.

What if I hit a Kerberos or NTLM issue that appears to be a product bug?
Please open a Microsoft Support case through standard support channels. Support will collect diagnostics and, if needed, escalate to the Windows product group. The support ticket path is important; it lets us track scenarios, telemetry, and reproducibility formally rather than through email threads.

How can I stay informed of upcoming NTLM-related changes?
Follow the Windows IT Pro Blog for public announcements and bookmark the Windows message center or subscribe to Windows announcements on the Microsoft 365 admin center message center for tenant-relevant notifications. If you have a non-disclosure agreement (NDA) with Microsoft, you can ask your account team about the NTLMLess newsletter and Management Advisors Program updates. Major NTLM milestones (feature general availability, default disablement dates, backport releases) will be announced through these channels.

Additional resources​

Here is a short list of useful references for going deeper:

• NTLM overview - protocol overview and history
• Reducing NTLM dependency: IAKerb and LocalKDC in Windows Insider Preview - details on feature availability
• The evolution of Windows authentication - the strategic context behind the move away from NTLM
• Advancing Windows security: Disabling NTLM by default - the public roadmap announcement
• Overview of NTLM auditing enhancements in Windows 11, version 24H2 and Windows Server 2025 - how to turn on and read enhanced auditing
• Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 - what's changing for NTLMv1 specifically
• Active Directory hardening series – Part 8: Disabling NTLM - practical guidance for Active Directory administrators
• Block NTLM connections on SMB – Guidance on how to block NTLM authentication on SMB clients
• Eliminating NTLM in Windows - technical deep dive