NTLM Disabled by Default: How Do You Find Your NTLM Dependencies?

Quick answer. As of September 2026, Microsoft’s current target is to disable network NTLM by default in the next major release of Windows Server and Windows client, a release it has not dated and calls subject to change, while in-market versions of Windows continue to support NTLM, so the practical step now is to turn on enhanced NTLM auditing, read why each NTLM connection happened, and fix or explicitly allow each dependency. NTLMv1 is already blocked in Windows Server 2025 and Windows 11, version 24H2, and, according to Microsoft’s Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025, Windows updates released on and after October 13, 2026 changed the BlockNtlmv1SSO default to Enforce on devices where that registry value is not set. After the default changes, administrators will be able to re-enable NTLM by policy, but Microsoft’s Retiring NTLM: Frequently asked questions says that ability will narrow over time, and IAKerb and LocalKDC, in Windows Insider preview as of September 2026, will close a number of fallback cases but not all.

The next Windows Server upgrade request will reach your desk with a question attached that no one on the team can answer yet: what still uses NTLM? Microsoft’s Advancing Windows security: Disabling NTLM by default roadmap of January 29, 2026 put network NTLM on a path to default-off, and a penetration test or the security office may already have flagged NTLM in your estate. The answer is sitting in logs Windows already writes, on clients, servers and domain controllers, and it can trace back to a short list of causes. This guide covers what Microsoft has and has not committed to, what is already off, where NTLM hides, how to find it, which fixes are yours to make, what the coming Kerberos features will not fix, and how to test NTLM off with a written exception for everything that stays.

What Microsoft has announced, and what it has not dated

If someone on your team has said this is years away, the honest answer is that no one outside Microsoft knows, because Microsoft has dated the change to a release, not to a calendar day. Microsoft’s Deprecated features for Windows client page recorded the starting point in June 2024: “All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated.” Microsoft’s January 29, 2026 roadmap, Advancing Windows security: Disabling NTLM by default, explains what that word means: “Deprecated features remain available, but no longer receive updates or enhancements and may be removed in a future release.”

The same roadmap sets out the end state for “the next major Windows Server release and associated Windows client releases”, and Microsoft’s Advancing Windows security: Disabling NTLM by default post lists two changes for that release:

• “Network NTLM will be disabled by default.”
• “NTLM usage will require explicit re-enablement through new policy controls.”

Microsoft’s newest statement is its September 9, 2026 Retiring NTLM: Frequently asked questions, which states: “Our current target for default disablement is the next major release of Server and Client (subject to change).” It gives no year and no version, and neither does this guide. The same FAQ separates that release from the servers you run today: “Default disablement applies to the future release train.” And: “In-market versions of Windows client and Windows Server will continue to support NTLM.”

Disabled is not removed. Microsoft’s Retiring NTLM: Frequently asked questions states that “NTLM is being disabled by default, not removed outright”, that administrators will be able to re-enable NTLM through Group Policy or registry configuration when default disablement ships, and then adds: “Over time, as customer environments mature and dependencies are eliminated, the ability to re-enable NTLM will be narrowed.” Microsoft’s Features removed or no longer developed in Windows Server page states that “NTLMv2 will continue to work but will be removed from Windows Server in a future release.”

This guide’s planning rule: plan to the Windows Server release you will install, not to a calendar date, and treat re-enabling NTLM after that upgrade as a temporary exception with an owner, never as the plan.

What is already off: NTLMv1, and the October 2026 single sign-on default

The part of this change that does not wait for a future release is NTLMv1, and a team that assumes it has time can find out otherwise on a Wi-Fi or VPN connection. Microsoft’s Deprecated features for Windows client page states: “NTLMv1 is removed starting in Windows 11, version 24H2 and Windows Server 2025.” Microsoft’s Retiring NTLM: Frequently asked questions adds that “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.”

What remains is single sign-on that still derives NTLMv1 credentials, and Microsoft’s KB5066470, Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025, states: “Windows updates released on and after October 13, 2026, strengthen NTLMv1 security by changing the internal default behavior when the BlockNtlmv1SSO registry value is not set”. That change moved the default of the BlockNTLMv1SSO registry key from Audit to Enforce. Four conditions in that KB decide whether it touches you:

• Scope: the article says “if Windows Credential Guard is enabled on the device, these changes do not take effect.”
• Who notices first: the article’s “examples include Wi-Fi, Ethernet, and VPN deployments using MS-CHAPv2 based authentication, including PEAP-MSCHAPv2 and EAP-MSCHAPv2”.
• What keeps working: “manually entering credentials will continue to work in Enforce mode.”
• What to read now: Event ID 4024 in Audit mode and Event ID 4025 in Enforce mode, both in the NTLM Operational log.

Microsoft’s KB5066470, Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025, also strongly recommends deploying Credential Guard where its requirements are met.

This guide’s planning rule: read event 4024 on your Windows 11, version 24H2 and Windows Server 2025 devices now, decide per network access method, and set the BlockNTLMv1SSO key deliberately rather than inherit the Enforce default.

Where NTLM hides in a regulated estate

The upgrade that breaks something rarely breaks the application anyone was worried about; it breaks the scanner, the file share mapped by address, or the service account no one has touched since it was created. Microsoft’s NTLM overview states: “Kerberos version 5 authentication is the preferred authentication method for Active Directory environments, but a non-Microsoft or Microsoft application might still use NTLM.” Microsoft’s Retiring NTLM: Frequently asked questions sorts the reasons into four patterns:

• “Hardcoded NTLM: An application explicitly requests NTLM and does not attempt Negotiate/Kerberos.”
• “Missing Kerberos prerequisites: The app uses Negotiate, Kerberos fails (missing SPN, IP address, no DC line-of-sight), and NTLM previously succeeded as fallback.”
• “Legacy protocol / device dependency: The client talks to a legacy server, embedded device, or third-party appliance that only supports NTLM end-to-end.” For that pattern the FAQ is blunt: “Vendor updates will be required.”
• “Local-account or special identity flows: The application authenticates using local accounts over the network.”

Two cases deserve their own line in the inventory. The first is the address: Microsoft’s Retiring NTLM: Frequently asked questions states that “Kerberos does not natively understand IP addresses, so authentication requests made using an IP address (rather than an SPN) fall back to NTLM.” The second is the boundary: “Cross-domain authentication without a configured trust is a scenario that today requires NTLM.” And standalone machines stay where they are for now: Microsoft’s NTLM overview states that NTLM “is still supported and must be used for Windows authentication with systems configured as a member of a workgroup.”

The reason the security office cares is on Microsoft’s own list in Advancing Windows security: Disabling NTLM by default: “Vulnerability to replay, relay, and pass-the-hash attacks”.

In a regulated estate the usual categories are line-of-business applications with hardcoded authentication, vendor-packaged applications, non-Windows clients and network appliances, embedded devices such as scanners and controllers, file shares reached by address, and service accounts whose SPNs were never registered or were registered twice. This guide’s planning rule: sort the inventory by those four causes, not by server, because each cause has one fix that applies to every row under it.

Finding every dependency with enhanced NTLM auditing

A team that tries to find NTLM by asking application owners gets a list of what people remember, which is not the same as what Windows logged. Microsoft’s KB5064479, Overview of NTLM auditing enhancements in Windows 11, version 24H2 and Windows Server 2025, describes the logs that answer it directly, and Microsoft’s Retiring NTLM: Frequently asked questions states where they run: “Enhanced NTLM auditing is available for Windows 11, versions 25H2 and 24H2 and Windows Server 2025.” For older servers, the same FAQ said on September 9, 2026: “We are also working on bringing back enhanced auditing to Windows Server 2019 and Windows Server 2022.” Per Microsoft’s KB5064479, enhanced NTLM auditing for Windows Server 2019 and Windows Server 2022 is now available in Windows updates released on and after October 13, 2026.

Microsoft’s KB5064479, Overview of NTLM auditing enhancements in Windows 11, version 24H2 and Windows Server 2025, states: “These logs can be found in Event Viewer under Applications and Services Logs > Microsoft > Windows > NTLM > Operational” and “By default, the events are enabled.” Client and server logging is controlled by the “NTLM Enhanced Logging” policy, and domain-wide logging on domain controllers by the “Log Enhanced Domain-wide NTLM Logs” policy. The events to collect, per the same KB:

• Clients: “Event ID 4020 (Information), 4021 (Warning)”
• Servers: “Event ID 4022 (Information), 4023 (Warning)”
• Domain controllers, same domain: “Event ID 4032 (Information), 4033 (Warning)”
• Domain controllers, cross-domain: “Event ID 4030 (Information), 4031 (Warning)”

A Warning, in the KB’s words, “Indicates a downgrade of NTLM security, such as the use of NTLMv1.” The most useful field is on the client event: the KB’s Usage Id/Reason field “highlights why NTLM authentication was used.” Microsoft’s KB5064479, Overview of NTLM auditing enhancements in Windows 11, version 24H2 and Windows Server 2025, lists the reason values, among them:

• 1: “NTLM was called directly by the calling application.”
• 2: “Authenticating a Local Account.”
• 7: “The target name contains an IP address.”
• 8: “The target name was found to have been duplicated in Active Directory.”
• 9: “No Line of Sight could be established with a Domain Controller.”

One caution from the same KB belongs in the plan. Existing collection is not disturbed: “The enhanced NTLM auditing changes do not affect the current NTLM logs; if the current NTLM auditing logs are enabled, they will continue to be logged.” Microsoft’s Retiring NTLM: Frequently asked questions adds a cross-check that works everywhere, “Security Event ID 4624 shows the authentication package used”, and three working rules: “Give yourself several weeks of data to establish a baseline”, the calling process name is “your remediation worklist”, and “Group findings by root cause (e.g., missing SPN, hardcoded caller, legacy appliance) so you can remediate at scale rather than machine-by-machine.”

This guide’s planning rule: collect on clients, servers and domain controllers, baseline for several weeks, then keep one row per caller with its process, target, reason value, owner and disposition. Windows’ own logs are enough to build that list.

Fixing what only you can fix

The expensive mistake is waiting for a Windows feature to fix a cause that lives in your own directory or your own code. A hardcoded caller can be the cheapest fix on the list: Microsoft’s Deprecated features for Windows client page states that “Calls to NTLM should be replaced by calls to Negotiate, which tries to authenticate with Kerberos and only falls back to NTLM when necessary,” and Microsoft’s Retiring NTLM: Frequently asked questions states: “In most cases, the fix is the same one-line change: ask for Negotiate instead of NTLM.”

SPNs are yours alone to fix. Microsoft’s Retiring NTLM: Frequently asked questions is direct about it: “we cannot fix missing, duplicate, or malformed SPNs in your directory.” It continues: “This is directory hygiene, and it is work that needs to start now rather than when default disablement lands.” On connections made to an IP address, the same FAQ says: “do not wait for a platform fix here.”

There is a Windows setting for Kerberos to an IP address, and Microsoft’s Kerberos clients allow IPv4 and IPv6 address hostnames in Service Principal Names (SPNs) page sets out why it is a last resort:

• “By default Windows will not attempt Kerberos authentication for a host if the hostname is an IP address.”
• “This registry value will need to be set on each client machine that needs to access Kerberos-protected resources by IP address.”
• “registering an IP address-based SPN is a manual process and should only be used when it’s impossible to switch to a DNS-based hostname.”

For software you do not own, Microsoft’s Retiring NTLM: Frequently asked questions states: “For hardcoded-NTLM in third-party products, open cases with your ISVs so they can plan their own remediation.” Open those cases now; a vendor’s answer is part of the exception record if the fix does not arrive before your upgrade.

An application you move from NTLM onto Kerberos also needs a service account that can use Kerberos’ current encryption types, which is a separate decision this guide does not cover.

This guide’s planning rules: use names, not addresses; register one SPN per service on one account and remove the duplicates; and ask for Negotiate, never NTLM, in anything your team writes or configures.

What IAKerb and LocalKDC will fix, and what they will not

A plan that assumes a coming Windows feature will absorb the hard cases is a plan that slips when the feature does. In January, Microsoft’s Advancing Windows security: Disabling NTLM by default roadmap targeted the second half of 2026 for these features on Windows Server 2025 and Windows 11, version 24H2 and later. On June 2, 2026, Microsoft’s Reducing NTLM Dependency: IAKerb and LocalKDC in Windows Insider Preview announced both as “coming to client and server public preview later this month for Windows Insiders in the Canary Channel”. The current status is the September 9, 2026 Retiring NTLM: Frequently asked questions: “Both features are currently available in Windows Insider preview builds” and “They will be generally available for Windows Server 2025 and Windows 11 in the coming months.”

What each one does, in the words of Microsoft’s Reducing NTLM Dependency: IAKerb and LocalKDC in Windows Insider Preview:

• “IAKerb (Initial and Pass-Through Authentication using Kerberos) enables Kerberos to work when the initiating device (Kerberos client) does not have direct connectivity to a domain controller.”
• “LocalKDC is a local Key Distribution Center implementation in Windows that enables Kerberos-based authentication for local account scenarios.”

And what they will not do, from the same Microsoft post: “IAKerb and LocalKDC address many of these gaps (though not all) by extending Kerberos support, reducing reliance on NTLM fallback across customer environments.” It goes further: “These features are designed to address important NTLM fallback scenarios but will not eliminate every remaining NTLM dependency in Windows environments; some scenarios may still require NTLM based on application behavior, infrastructure assumptions, or legacy dependencies.” Asked whether to wait for them, Microsoft’s Retiring NTLM: Frequently asked questions answers: “No, you can start the audit and remediation work today with in-market Windows.”

This guide’s planning rule: pilot IAKerb and LocalKDC in preview where the reason value is 9 (no line of sight to a domain controller) or 2 (a local account), and keep fixing every other row now.

Testing NTLM off before the release does it for you

The first time NTLM is off in production should not be the day the new Windows Server goes in. Microsoft’s Advancing Windows security: Disabling NTLM by default roadmap asks organizations to “Begin testing NTLM-off configurations in non-production environments.” Microsoft’s Retiring NTLM: Frequently asked questions sets the order for production: “Pilot NTLM blocking: Use the ring-based approach (start with high-value/privileged accounts and non-critical services) and iterate outward.”

One blocking control ships today. Microsoft’s Block NTLM connections on SMB page states: “Starting with Windows Server 2025 and Windows 11, version 24H2, you have the option to configure SMB to block NTLM.” It also states that “NTLM blocking is an SMB client capability only,” and it provides a “Block NTLM Server Exception List” policy for the servers that still need it. Microsoft’s FAQ also says that “NTLM blocking is being consolidated into a centralized, policy-driven engine.” Microsoft has not yet published how that engine will be configured, so plan around the controls that exist.

This guide’s planning rule: every dependency that keeps NTLM gets a written exception, and each exception records:

• Caller: the calling process and the target it reached.
• Cause: the reason value from the NTLM Operational log.
• Why it stays: why it cannot move to Kerberos today, with the vendor’s written answer where there is one.
• Ownership: the owner, the review date and the retirement plan.

A device that will never do Kerberos is a legacy-system decision rather than an authentication fix, and legacy system security consulting covers that decision. Whether an exception record meets an obligation your organization carries is a determination for your compliance counsel or assessor; this guide makes no such claim.

When this guide is the wrong starting point

Before you fund an NTLM inventory, check that it is the decision in front of you. Microsoft’s Retiring NTLM: Frequently asked questions is one test for the cases that follow:

• The question is detecting NTLM relay or pass-the-hash attacks against your directory. That is a detection decision, and this guide does not cover it.
• An application cannot use Kerberos or any modern sign-in at all. The platform decision comes first, and IAM platform selection for a hybrid enterprise covers it; putting stronger sign-in in front of such an application, or moving it to cloud sign-in, is a separate decision again.
• The estate is mostly workgroup or standalone systems. NTLM is still required there today, and LocalKDC, still in preview, is the path to watch.
• No Windows Server upgrade is planned. In-market versions keep supporting NTLM, but the NTLMv1 change and the Enforce default released on and after October 13, 2026 do not wait for an upgrade, and neither does the security finding.
• You need a fixed date. Microsoft says its timelines are subject to change, so parts of this guide will change when Microsoft publishes its next step.

What to ask of whoever does the work

Whether your own team or an outside one does the work, ask for evidence against Microsoft’s Retiring NTLM: Frequently asked questions before you accept a plan:

• Show the inventory from Windows’ own NTLM logs on clients, servers and domain controllers before any setting changes.
• Show every caller sorted by root cause, each with a named owner.
• Show the Negotiate, SPN and name fixes before any exception is granted.
• Show that no plan treats a blanket re-enable of NTLM as the answer.
• Show non-Windows clients and appliances tested, not assumed.
• Show every exception written down with an owner and a retirement date.
• Show people who have implemented identity and access management in regulated Microsoft estates.
• State plainly that your team owns the directory and its monitoring after the project.

How i3solutions answers

i3solutions is a Microsoft Systems Integrator with nearly 30 years of experience implementing identity and access management solutions for enterprises in regulated industries. That practice is described on identity and access management solutions, and this work sits inside it: the NTLM inventory from the enhanced auditing, the root-cause fixes in the directory and the applications, the ring pilot and the exception record. i3solutions governs identity and access for regulated Microsoft estates with senior, U.S.-based engineers and leaves an audit-defensible record. i3solutions has deep experience implementing identity governance for enterprises in aerospace and defense manufacturing, financial services, and healthcare, including environments with CMMC and ITAR obligations. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences.

The work runs as a project, with embedded specialists where your team needs them. An i3solutions project engagement does not by itself include ongoing support of what it delivers, which i3solutions scopes separately as Application Managed Services, and it is not a replacement for the internal team, open-ended scope expansion, or vendor lock-in. The inventory, the exception record and the directory belong to your team, which runs them after the project.

Key Takeaways

These points summarize the Microsoft pages this guide cites, chiefly the Retiring NTLM: Frequently asked questions:

• Microsoft’s current target is to disable network NTLM by default in the next major release of Windows Server and Windows client, with no date set and subject to change; in-market versions keep supporting NTLM.
• After that release, NTLM can be re-enabled by policy, and Microsoft says that ability will narrow over time.
• NTLMv1 is already blocked in Windows Server 2025 and Windows 11, version 24H2, and, per KB5066470, Windows updates released on and after October 13, 2026 moved the BlockNtlmv1SSO default to Enforce.
• Enhanced NTLM auditing’s reason values turn the NTLM Operational log into a worklist sorted by cause.
• Missing or duplicate SPNs, IP-address targets and hardcoded callers are yours to fix; IAKerb and LocalKDC will not fix every case.
• Every dependency that keeps NTLM needs a written exception with an owner and a retirement date.

Frequently Asked Questions

When will Microsoft disable NTLM by default?

Microsoft has not set a date. According to Microsoft’s FAQ of September 9, 2026, its current target for default disablement is the next major release of Windows Server and Windows client, subject to change, and it gives no year or version for that release.

Will NTLM stop working on our existing servers running Windows Server 2019, 2022 and 2025?

Not because of the default change. According to Microsoft’s FAQ, default disablement applies to the future release train, and in-market versions of Windows client and Windows Server will continue to support NTLM. According to Microsoft, NTLMv1 is already blocked in Windows Server 2025, which is a separate change.

Can we turn NTLM back on after it is disabled by default?

Yes, for now. According to Microsoft’s FAQ, administrators will be able to re-enable NTLM through Group Policy or registry configuration when default disablement ships, and the ability to re-enable NTLM will be narrowed over time as dependencies are eliminated. Treat re-enabling as a temporary exception with an owner, not as the plan.

How do we find out what still uses NTLM?

Turn on enhanced NTLM auditing and read the NTLM Operational log. According to Microsoft’s KB5064479, the log is written on clients, servers and domain controllers, and the client event’s Usage Id/Reason field records why NTLM was used, such as a direct call by the application, a local account, an IP address target, a target name duplicated in Active Directory, or no line of sight to a domain controller. According to Microsoft, enhanced NTLM auditing is available for Windows 11, versions 25H2 and 24H2 and Windows Server 2025, and Security Event ID 4624 shows the authentication package used.

What changed for NTLMv1 in October 2026?

According to Microsoft’s KB5066470, Windows updates released on and after October 13, 2026 changed the default of the BlockNTLMv1SSO registry key from Audit to Enforce on devices where that registry value is not set, and the change does not take effect where Windows Credential Guard is enabled. According to the same article, Wi-Fi, Ethernet and VPN deployments using MS-CHAPv2 are examples of what is affected, and manually entering credentials will continue to work in Enforce mode.

Do IAKerb and LocalKDC remove the need for NTLM?

No. According to Microsoft, IAKerb and LocalKDC address NTLM fallback gaps, though not all of them, and scenarios can remain that still require NTLM based on application behavior, infrastructure assumptions or legacy dependencies. According to Microsoft’s FAQ of September 9, 2026, both are in Windows Insider preview builds and will reach general availability for Windows Server 2025 and Windows 11 in the coming months.