NTLM elimination in Active Directory needs visibility first

At a glance

What this is: This is a practical guide to finding, assessing, and removing NTLM from Active Directory environments, with the key finding that detection and fallback control matter more than legacy dependency claims.

Why it matters: It matters because identity teams cannot retire NTLM safely without seeing where it persists, why Kerberos fails, and how legacy authentication weakens broader IAM and Zero Trust programmes.

👉 Read Silverfort's guide to detecting and eliminating NTLM in Active Directory

Context

NTLM elimination is an identity governance problem before it is a protocol problem. In Active Directory, legacy authentication often survives because teams can see the application but not the fallback behaviour that keeps NTLM alive. That makes removal difficult across large estates, especially where old applications, misconfigured SPNs, or hostname usage issues push clients back to NTLM.

The governance issue is straightforward: you cannot retire what you cannot observe, and you cannot enforce modern authentication if fallback paths remain hidden. For IAM and identity security teams, the practical question is how to surface NTLM usage, prove where Kerberos fails, and align protocol reduction with broader Windows and application modernisation.

Key questions

Q: How should security teams eliminate NTLM without breaking legacy applications?

A: Start by inventorying where NTLM is actually used, then separate true application dependence from hidden Kerberos fallback. Fix SPN issues, hostname problems, and authentication misconfigurations first, because those are often what keep NTLM alive. After that, block NTLMv1, reduce NTLMv2 dependencies, and retire applications that cannot support stronger authentication.

Q: Why do NTLM fallback paths create more risk than teams expect?

A: Because a successful authentication does not always mean the preferred protocol succeeded. In many environments, Kerberos failure is followed immediately by NTLM success, which hides dependency on weaker authentication and undermines policy assumptions. If fallback is not monitored, teams can believe NTLM is gone when it is still actively protecting nothing.

Q: How do you know if NTLM elimination is actually working?

A: You know it is working when authentication logs show falling NTLM usage, fewer Kerberos failures that convert into NTLM, and a shrinking set of destination systems still relying on legacy authentication. The strongest signal is when application owners can explain why any remaining NTLM dependency exists and when it will be removed.

Q: What should identity teams prioritise before enforcing a full NTLM shutdown?

A: They should prioritise application compatibility, dependency mapping, and executive agreement on replacement timelines. Full shutdown works only when teams have identified which systems can move to Kerberos, federated identity, or certificates, and which systems must be upgraded or retired because they cannot survive without NTLM.

Technical breakdown

How NTLM challenge-response works in Active Directory

NTLM is a challenge-response authentication protocol that lets a client prove knowledge of a password hash without sending the password itself. The client sends a negotiate message, the server returns a challenge nonce, and the client responds with a calculated value based on the stored hash. The domain controller then verifies the response against Active Directory. This design was useful for early Windows networks, but it creates a weak trust model compared with Kerberos and modern federated identity because the protocol depends on legacy hash handling and is vulnerable to relay, brute force, and downgrade paths when controls are weak.

Practical implication: treat NTLM as a legacy exception path and map every place where the protocol still authenticates users or systems.

Why Kerberos failures silently trigger NTLM fallback

A major reason NTLM persists is that applications and clients often fall back to it when Kerberos cannot complete. Common causes include missing or misconfigured Service Principal Names, clients connecting with IP addresses instead of hostnames, or applications that do not implement Kerberos cleanly. This means NTLM elimination is not just about blocking a protocol, but about fixing the conditions that force fallback. If the underlying Kerberos issue is not investigated, successful NTLM authentication can follow immediately after a failed Kerberos attempt and remain invisible in normal administration.

Practical implication: review Kerberos denies as a source of NTLM persistence, and fix the root cause before tightening enforcement.

Why NTLMv1 and NTLMv2 create different risk profiles

NTLMv1 is particularly weak because it relies on DES-based challenge-response calculations that can be cracked quickly with modern tooling. NTLMv2 improves the exchange by adding stronger hash handling and session context, but it still does not eliminate relay or pass-the-hash risk when signing, binding, or target validation is not enforced. That makes the two versions materially different from a risk standpoint. The right governance model is to remove NTLMv1 immediately, then treat NTLMv2 as a transitional state only if business dependencies remain and the fallback paths are actively being reduced.

Practical implication: block NTLMv1 now, then inventory every remaining NTLMv2 dependency with a migration deadline.

Threat narrative

Attacker objective: The attacker aims to exploit legacy authentication handling to gain or reuse access that should have been prevented by stronger identity controls.

1. Entry occurs through legacy authentication paths that allow NTLM to remain active when Kerberos cannot be used successfully.
2. Escalation happens when weak NTLMv1 responses or unprotected NTLMv2 sessions can be relayed, reused, or abused for broader access.
3. Impact is the continued exposure of credentials and the persistence of a downgrade path that weakens Active Directory security at scale.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NTLM elimination is really a fallback governance problem, not a protocol cleanup exercise. The article shows that NTLM survives when Kerberos fails and no one is watching the reason for the fallback. That means the real control gap is observability over authentication path selection, not just a policy switch. Practitioners should frame NTLM removal as governance over exception handling.

Legacy authentication persistence creates hidden identity risk across human and machine flows. NTLM does not only affect users at sign-in; it also persists through applications, service paths, and clients that silently retry with weaker methods. That is why protocol governance belongs in the same conversation as service account visibility, access reviews, and application dependency mapping. Practitioners should treat NTLM as part of broader identity lifecycle control.

Standing protocol trust was designed for a world where fallback was rare and visible. That assumption fails when clients can automatically drop from Kerberos to NTLM without operational scrutiny. The implication is that teams must rethink how much assurance they assign to successful authentication alone, because the protocol path itself may be the real risk signal.

NTLM activity is hard to detect inside Active Directory is the operational blind spot that keeps legacy authentication alive. Once fallback becomes invisible, retirement plans become wishful thinking instead of enforceable change. Practitioners should demand protocol-level reporting before they promise NTLM removal.

Modern identity programmes should use NTLM elimination as a forcing function for Zero Trust discipline. The article ties NTLM deprecation to modernization, which is the right strategic framing. If an environment still depends on legacy fallback, it is not yet operating with strong protocol assurance. Practitioners should use the removal effort to expose where authentication design is still permissive.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often identity hygiene lags behind operational reality.
• The NHI Lifecycle Management Guide is the next resource to read if you are aligning protocol retirement with lifecycle control and access reduction.

What this signals

NTLM removal will expose the difference between authentication policy and authentication reality. Many programmes believe a policy change is enough, but NTLM persistence usually comes from application dependencies and client fallback paths. Teams that can surface those paths early will have a much cleaner migration to Kerberos, federation, or certificates.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, legacy authentication often compounds a broader over-permission problem rather than standing alone. That is why protocol cleanup should be linked to access review, service account governance, and application modernisation.

NTLM elimination is also a useful readiness test for Zero Trust execution. If an environment cannot explain why it still needs a weak fallback protocol, it will struggle to enforce stronger identity assurance elsewhere. Use the deprecation window to pressure-test the full authentication chain, not just the protocol banner.

For practitioners

• Map every NTLM dependency across applications and clients Use authentication logs, NTLM protocol filters, and destination grouping to identify where NTLM is still used, then separate application dependence from client fallback behaviour.
• Review Kerberos failures before tightening NTLM policy Investigate denied Kerberos attempts for SPN issues, hostname misuse, or application errors, because unresolved Kerberos problems will keep reintroducing NTLM as a fallback path.
• Block NTLMv1 and treat NTLMv2 as transitional Use Group Policy to refuse LM and NTLMv1, then build a migration plan for any remaining NTLMv2 dependencies so the environment does not settle into permanent exception handling.
• Retire applications that cannot move off NTLM Prioritise upgrades, replacements, or decommissioning for systems that cannot support Kerberos, OIDC, SAML, or certificate-based authentication, and align the work with broader Windows modernisation.

Key takeaways

• NTLM persists less because it is needed and more because fallback behaviour is hard to see.
• Kerberos failures, weak NTLM variants, and legacy application dependencies together create the risk surface that keeps NTLM alive.
• The practical path is to map usage, fix fallback causes, block NTLMv1, and retire systems that cannot move to stronger identity methods.

Key terms

• NTLM: NTLM is a legacy Windows authentication protocol that uses challenge-response mechanics instead of sending passwords in clear text. It is still found in older Active Directory environments, but it is widely considered weaker than modern authentication methods because it relies on legacy hash handling and can be difficult to govern at scale.
• Kerberos Fallback: Kerberos fallback is the behaviour where a client or application attempts Kerberos first and then silently uses NTLM when Kerberos cannot complete. In practice, this creates hidden dependency on weaker authentication and makes protocol retirement harder because successful login events can mask the underlying failure path.
• Service Principal Name: A Service Principal Name is an identity mapping that lets Kerberos match a service instance to the correct account. When SPNs are missing or misconfigured, Kerberos often fails and NTLM becomes the fallback, which is why SPN hygiene is a core part of legacy protocol removal.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Silverfort: Eliminating NTLM in Active Directory. Read the original.