Microsoft’s NTLM deprecation shows why legacy auth must go

At a glance

What this is: This is Expel’s February Patch Tuesday and NTLM deprecation analysis, with the key finding that legacy authentication still creates exploitable identity risk across Windows environments.

Why it matters: It matters because IAM, PAM, and security teams still have to govern service accounts, local accounts, and fallback authentication paths that attackers can abuse for credential replay and lateral movement.

By the numbers:

• Microsoft’s February 2026 Patch Tuesday addresses 59 security vulnerabilities, including six zero-days already being exploited in the wild.
• Microsoft says NTLM will be disabled by default in 2026.

👉 Read Expel’s analysis of NTLM deprecation and February Patch Tuesday risk

Context

NTLM is a legacy Windows authentication protocol that persists mainly as a fallback for older applications, local accounts, and non-domain joined systems. That persistence matters because fallback paths are often the easiest place for attackers to steal or relay credentials, especially when modern identity controls are unevenly deployed across the estate.

Expel’s analysis treats this as an identity governance problem as much as an authentication problem. The practical issue is not whether organisations prefer Kerberos in theory, but whether they have visibility into where NTLM still exists, which identities depend on it, and which systems are still exposed to relay and pass-the-hash abuse.

The February Patch Tuesday backdrop reinforces the same theme: identity weaknesses rarely stay isolated from broader vulnerability management. In environments where legacy authentication remains available, patching alone does not remove the attack path, because the protocol itself can still become the pivot point for escalation and lateral movement.

Key questions

Q: What breaks when NTLM is still enabled in Active Directory?

A: NTLM preserves a replayable trust path that attackers can abuse once they obtain cached hash material from a compromised endpoint. The result is not just weaker authentication, but a lateral movement path that bypasses password cracking and can turn one host compromise into broader directory access.

Q: Why do legacy authentication protocols increase lateral movement risk?

A: They allow attackers to reuse captured authentication material instead of forcing a fresh, mutually verified login. When the protocol trusts the hash or supports relaying, one compromised endpoint can become a launching point for broader account impersonation and downstream system access.

Q: How can security teams know whether NTLM is still actually needed?

A: They should inventory applications, devices, and service accounts that still generate NTLM traffic, then test whether Kerberos, local KDC, or IAKerb can replace that dependency. If a system still requires NTLM, the exception should be documented, time-bound, and owned.

Q: What is the difference between hardening NTLM and removing it?

A: Hardening reduces exposure by adding controls such as SMB signing and extended protection for authentication, while removal eliminates the fallback protocol entirely. Hardening is a transition step, but it does not solve the core problem if NTLM remains broadly available in production.

Technical breakdown

Why NTLM remains a credential replay risk

NTLM validates a password hash rather than proving the original secret in a modern, mutual-authentication flow. That design leaves it exposed to pass-the-hash attacks, where an attacker uses the hash directly instead of cracking it, and to relay attacks, where captured authentication traffic is forwarded to another service. Weak legacy hashing and the absence of salting further reduce resistance to offline abuse. In identity terms, NTLM creates an authentication artefact that can behave like a reusable credential, which is exactly what modern IAM programmes try to avoid.

Practical implication: treat every remaining NTLM dependency as a credential-replay surface until it is inventoried and removed.

How relay and AitM attacks exploit one-way trust

NTLM does not require the server to prove itself to the client in the way a stronger mutual-authentication pattern would. That one-way trust allows adversary-in-the-middle positioning, where the attacker intercepts or redirects a login attempt and relays it to a target service. When combined with legacy local accounts or unmanaged endpoints, the attack can succeed without the victim noticing anything unusual. This is why NTLM is not just an old protocol. It is a structural trust shortcut that attackers can operationalise across multiple systems.

Practical implication: enforce protections that block relaying while legacy dependencies are being remediated.

Why NTLM deprecation is an identity lifecycle issue

Microsoft’s move toward auditing, hardening, and then disabling NTLM by default shows that protocol retirement is a lifecycle exercise, not a single switch. Teams have to identify where NTLM is in use, assess the dependent identities and systems, migrate them to Kerberos or modern identity providers, and then remove fallback access in a controlled sequence. Local KDC and IAKerb matter because they extend Kerberos-style authentication to scenarios that historically depended on NTLM. That is the real governance lesson: deprecation succeeds only when identity dependencies are mapped first.

Practical implication: build a phased deprecation plan that ties NTLM removal to asset, application, and identity dependency discovery.

Threat narrative

Attacker objective: The attacker wants to reuse or relay legacy authentication material to gain unauthorized access and move laterally through the environment.

1. Entry occurs when an attacker coerces or intercepts NTLM authentication from a user or endpoint, often through phishing, malicious content, or an adversary-in-the-middle position.
2. Escalation occurs when the attacker relays the captured NTLM material or reuses the hash directly through pass-the-hash techniques to impersonate the account.
3. Impact follows when the attacker reaches unauthorized access, lateral movement, or privilege escalation inside the Windows environment, especially where legacy accounts still trust NTLM.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 persistence is a governance failure, not just a protocol legacy. Organisations that still allow NTLM are maintaining a fallback authentication path that attackers can abuse long after the original business need has faded. The real problem is not that NTLM exists in the codebase, but that identity teams have not fully mapped which accounts, devices, and applications still depend on it. Practitioners should treat residual NTLM use as unmanaged identity exposure, not as harmless technical debt.

Pass-the-hash turns authentication material into a reusable NHI-like asset. Once a hash can be replayed, the security model changes from secret verification to credential possession. That is precisely why classic IAM assumptions fail here: the protocol itself creates a transferable artefact that behaves like a non-human identity credential even when it was never intended to. Security teams should reframe this as a credential lifecycle problem spanning issuance, use, and revocation.

NTLM deprecation exposes the hidden local-account problem in Windows estates. Microsoft’s phased plan acknowledges that local and non-domain scenarios still need a workable path to Kerberos-style authentication. The named concept here is fallback authentication debt: every exception granted to preserve legacy access extends the period during which replay and relay remain viable. Practitioners should expect the hardest part of deprecation to be exception governance, not the protocol change itself.

Protocol retirement only works when identity dependency discovery comes first. Auditing, hardening, and disabling are the correct sequence because teams cannot safely remove what they cannot see. Event logging, application inventory, and dependency mapping are therefore identity control prerequisites, not optional prep work. The implication for the field is clear: deprecating NTLM is a lifecycle governance exercise across humans, service accounts, and local machine identities, not a single Windows setting.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
• For a broader lifecycle lens, the Ultimate Guide to NHIs explains why identity scope and credential sprawl now define the control problem.

What this signals

Fallback authentication debt: NTLM is a useful label for a wider pattern that security teams should track across the estate. Any identity path that exists only because a legacy dependency has not yet been retired creates the same governance drag, whether that identity is human, service-based, or local machine-bound. The programme implication is to treat protocol retirement as part of identity lifecycle management, not as a one-time infrastructure cleanup.

The shift to Kerberos-capable alternatives should also sharpen IAM ownership boundaries. When infrastructure teams own the technical migration but identity teams own the exception process, unresolved dependencies tend to linger. For practitioners building a deprecation roadmap, the key signal is whether exceptions are shrinking faster than legacy traffic. If they are not, the environment is still carrying avoidable authentication debt.

For practitioners

• Inventory every remaining NTLM dependency Enable NTLM auditing through group policy and review domain controller logs for legacy applications, service accounts, printers, scanners, and local accounts that still rely on NTLMv1 or NTLMv2.
• Prioritise relay-resistant hardening while migration is underway Enforce SMB signing and extended protection for authentication on systems that cannot be migrated immediately, so relay attempts are less likely to succeed during the deprecation window.
• Migrate fallback accounts to Kerberos-capable paths Use local KDC and IAKerb where required so local and non-domain joined scenarios can authenticate without preserving NTLM as the default fallback.
• Create an exception register with expiry dates Document every approved NTLM exception, assign an owner, and require a retirement date so temporary business need does not become permanent protocol debt.
• Disable NTLM by default after remediation Once dependencies are cleared or consciously accepted, set NTLM to disabled by default and keep re-enable rights tightly governed for break-glass use only.

Key takeaways

• NTLM remains dangerous because it converts legacy authentication into a reusable attack surface for relay and pass-the-hash abuse.
• Microsoft’s deprecation timeline confirms that the real challenge is discovering every dependency before disabling fallback access.
• Practitioners should treat NTLM removal as a lifecycle governance programme, with inventory, hardening, exception control, and retirement in sequence.

Key terms

• Pass-the-Hash: An authentication abuse technique where an attacker uses a stolen password hash instead of the cleartext password. It matters in Windows environments because cached credentials can sometimes be enough to gain access, turning one compromised host into a broader lateral movement opportunity.
• NTLM Relay: NTLM relay is an attack technique where an authenticated challenge-response session is captured and forwarded to another service that accepts it as legitimate. The attacker does not need the password itself, only a reusable authentication exchange that the target will trust.
• Fallback authentication: Fallback authentication is the secondary method used when the primary sign-in factor is unavailable. For passkey deployments, fallback must be tightly governed because it often becomes the attacker’s preferred route if it remains easier to abuse than the main login path.
• Extended Protection for Authentication: Extended Protection for Authentication is a set of safeguards that bind authentication to the right endpoint and transport context. For admin tooling, it reduces relay risk, but only when the enforcement point is actually active in the host or middleware path that makes the trust decision.

What's in the full article

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

• A phased NTLM deprecation plan with the specific event IDs and policy settings used to find residual usage.
• Practical guidance for handling legacy applications, printers, scanners, and local accounts that still depend on NTLM.
• The Microsoft-authored replacement paths for local KDC and IAKerb, including when each fits.
• Hardening guidance for SMB signing and extended protection for authentication during the transition period.

👉 The full Expel post covers NTLM auditing, hardening, and the Microsoft migration path in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine 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 or identity security programme, it is worth exploring.