NTLM elimination in Active Directory needs visibility first

At a glance

What this is: This is a practical guide to removing NTLM from Active Directory, with the central finding that visibility into NTLM fallback is the first blocker practitioners must solve.

Why it matters: IAM and identity security teams need to understand where NTLM still appears because hidden fallback paths can keep legacy authentication alive long after policy changes say it should be gone.

Context

NTLM elimination in Active Directory is less a single policy change than a visibility problem. NTLM often persists because applications silently fall back to it when Kerberos fails, which means teams can believe they have modernised authentication while legacy paths remain active in production.

For identity governance teams, the challenge is to identify where the protocol is still used, why clients fall back, and which applications still depend on it. The practical issue is not only the protocol itself, but the control gap created when authentication telemetry does not show the fallback chain clearly enough to govern it.

The article treats NTLM retirement as part of broader Windows and identity modernisation rather than a standalone hardening task. That makes it relevant to Active Directory governance, application dependency mapping, and migration planning across legacy and modern authentication methods.

Key questions

Q: Where does NTLM elimination usually fail in Active Directory programmes?

A: It usually fails at visibility and fallback detection. Organisations often know NTLM should be removed, but they cannot easily see which applications or clients still fall back to it when Kerberos fails. Without that evidence, policy changes can create false confidence while the legacy path continues to operate.

Q: Why is NTLMv1 treated differently from NTLMv2?

A: NTLMv1 is much weaker because its challenge-response mechanism is easier to brute force, so it should be blocked as an immediate risk. NTLMv2 is stronger, but it can still be exposed to relay or pass-the-hash scenarios if signing and channel binding are not enforced, so it should be treated as transitional.

Q: What are the signs that Kerberos issues are forcing NTLM fallback?

A: The clearest sign is a failed Kerberos authentication followed immediately by a successful NTLM authentication for the same destination. That pattern often points to a misconfigured SPN, IP-based connection behaviour, or another application setup problem that should be fixed before the protocol is removed.

Q: How should teams respond when legacy authentication is still needed for compatibility?

A: Treat compatibility as a controlled exception, not a permanent state. Keep the number of NTLM-dependent services as small as possible, watch for abnormal session behaviour, and apply contextual access controls so that any residual fallback path is tightly constrained and observable.

Technical breakdown

How NTLM fallback hides in Active Directory

NTLM is a challenge-response authentication protocol that often appears when Kerberos cannot be established. In Active Directory, the client computes the response, the server forwards it to the Domain Controller, and the DC validates the stored hash. The governance problem is that a failed Kerberos attempt may be immediately followed by successful NTLM authentication, so the legacy path remains operational without drawing attention. That means application owners can misread authentication health unless they inspect both failure and fallback behaviour, not just successful logons. Practical implication: trace Kerberos denial events together with NTLM success events to expose the real dependency chain.

Practical implication: trace Kerberos denial events together with NTLM success events to expose the real dependency chain.

Why NTLMv1 and NTLMv2 demand different controls

NTLMv1 and NTLMv2 do not carry the same risk profile. NTLMv1 uses weak challenge-response mechanics that are easier to brute force, while NTLMv2 adds session context and stronger hashing but still leaves relay and pass-the-hash exposure when signing and channel binding are not enforced. That means a blanket view of NTLM misses the operational distinction practitioners need for prioritisation. Active Directory teams should treat NTLMv1 as an immediate removal candidate and NTLMv2 as a temporary residual risk while applications are migrated. Practical implication: distinguish version-level exposure before setting blocking policy.

Practical implication: distinguish version-level exposure before setting blocking policy.

How application configuration keeps legacy authentication alive

Many NTLM dependencies are not true hard dependencies. Misconfigured Service Principal Names, IP-based connections, and incomplete Kerberos setup can force applications to fall back to NTLM even when the software supports Kerberos, OIDC, SAML, or certificate-based login. This is why elimination work has to include application and connection-path review, not just domain controller policy. When the root cause sits in application design or deployment choice, the authentication protocol becomes a symptom of a broader identity integration problem. Practical implication: inventory applications by supported authentication methods and fix the conditions that trigger fallback.

Practical implication: inventory applications by supported authentication methods and fix the conditions that trigger fallback.

Threat narrative

Attacker objective: The attacker objective is to exploit weak or relayable legacy authentication paths that remain available despite the organisation believing NTLM has been retired.

1. Entry occurs when a client cannot complete Kerberos and silently falls back to NTLM during normal authentication.
2. Credential abuse follows when the environment continues to accept NTLMv1 or vulnerable NTLMv2 exchanges that can be replayed or relayed.
3. Impact emerges when legacy authentication remains available long enough to preserve weak authentication paths across Active Directory.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.

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

NHI Mgmt Group analysis

Visibility, not policy, is the first control gap in NTLM elimination: NTLM persists when teams cannot see the fallback chain from Kerberos failure to NTLM success. That means the governance problem is not simply whether NTLM is allowed, but whether the environment can prove where it is still happening. Identity programmes should treat hidden fallback as an exposure state in its own right, not as a minor logging issue.

NTLMv1 elimination and NTLMv2 reduction are different governance decisions: NTLMv1 is structurally weak, while NTLMv2 is still an interim legacy control with residual relay risk. Collapsing both into one remediation bucket delays the right decision at the right layer. Practitioners should separate immediate blocking from staged migration so policy reflects actual exposure.

Legacy authentication is often an application integration problem, not a protocol preference: Misconfigured SPNs, IP-based connections, and incomplete identity configuration can force NTLM fallback even in environments that claim to support Kerberos or federated identity. That means the real remediation target is the dependency chain between applications, clients, and directory services, not the protocol alone.

NTLM deprecation turns Active Directory visibility into a migration prerequisite: When Microsoft signals protocol retirement, organisations that have not mapped fallback behaviour will discover their dependency only after change pressure increases. The practical implication is that identity teams must align authentication modernisation with application rationalisation, because unobserved dependencies become delivery blockers.

Identity blast radius is larger when legacy authentication remains silent: A protocol that continues to work invisibly is harder to govern than one that fails loudly. That creates a standing assurance gap in Active Directory programmes, because the organisation cannot reliably tell whether the modern authentication estate is actually modern. Practitioners should treat silent fallback as a control failure with operational and security consequences.

What this signals

NTLM visibility is a governance prerequisite, not just a logging exercise: Active Directory teams that cannot see fallback behaviour cannot prove that legacy authentication has actually been removed. The control boundary shifts from policy declarations to authenticated evidence, because silent NTLM use can survive long after administrators think the migration is done.

Fallback analysis should become part of normal identity operations: Kerberos failures, SPN hygiene, and connection-path choices now sit inside the same operating model as access policy and authentication standards. In practice, that means identity teams need ongoing detection for legacy protocol reappearance, not a one-time cleanup project.

Active Directory modernisation now intersects with application rationalisation: NTLM removal is rarely solved by directory settings alone. The practical programme impact is that application inventory, authentication method review, and infrastructure refresh have to move together if organisations want to reach a no-NTLM state.

For practitioners

• Map NTLM usage by destination and client Collect authentication logs, apply an NTLM filter, and group results by destination so you can see which applications and servers still rely on legacy authentication.
• Investigate Kerberos failures before blocking NTLM Review denied Kerberos events, identify whether SPN issues or IP-based connections are causing fallback, and fix the root cause before tightening policy.
• Separate NTLMv1 from NTLMv2 remediation Block NTLMv1 as an immediate risk, then track NTLMv2 as a temporary state while applications are migrated or reconfigured to use stronger methods.
• Check each application’s supported authentication methods Verify whether applications can use Kerberos, SAML, OIDC, or certificate-based login so you can remove false NTLM dependencies caused by configuration gaps.
• Plan NTLM shutdown alongside application modernization Create a decommissioning timeline for applications that still depend on NTLM and align it with broader Windows and infrastructure refresh work.

Key takeaways

• NTLM remains embedded in many Active Directory environments because applications can silently fall back to it when Kerberos fails.
• The article’s central risk is not just legacy protocol use, but poor visibility into where NTLM still operates across clients and applications.
• Elimination work should start with fallback discovery, then separate NTLMv1 blocking from NTLMv2 migration and application remediation.

Key terms

• NTLMv1: NTLMv1 is an older Microsoft authentication protocol used in Windows environments. It relies on weak cryptography and limited challenge-response protection, which makes captured traffic easier to crack or reuse. In modern Active Directory estates, it is treated as a legacy risk because it can support replay, relay, and offline credential attacks.
• Kerberos Failure Signal: A Kerberos failure signal is the observable authentication denial that indicates the preferred protocol could not complete successfully. In identity operations, it is important because many environments follow that failure with NTLM success, so the denial is often the first clue that legacy authentication is still being used.
• SPN Misconfiguration: SPN misconfiguration occurs when a service principal name is missing, incorrect, or not aligned with how a client connects to a service. That breaks Kerberos in otherwise capable applications and often forces fallback to NTLM, turning a configuration issue into a legacy authentication dependency.
• Legacy Authentication Dependency: A legacy authentication dependency exists when an application or connection path still requires an older protocol to function. In Active Directory, the challenge is often that the dependency is assumed rather than verified, so teams keep NTLM in place longer than necessary because they have not tested the available alternatives.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.