Microsoft’s NTLM deprecation shows why legacy auth must go

At a glance

What this is: This is an analysis of Microsoft’s NTLM deprecation timeline and why NTLM’s design still creates relay and lateral-movement risk in Windows environments.

Why it matters: It matters because IAM teams still have legacy authentication paths in production, and those paths can undermine Kerberos migration, control validation, and deprecation planning for human and machine access.

By the numbers:

• This February’s Patch Tuesday includes 59 CVEs.

Context

NTLM deprecation is an identity governance problem as much as an authentication one. Legacy authentication survives because organisations still have applications, local accounts, printers, scanners, and workflow dependencies that do not fit modern federation models.

Expel’s analysis frames NTLM as a control boundary that has outlived its security assumptions. The protocol remains attractive to attackers because it tolerates weak credential handling, supports pass-the-hash abuse, and lacks mutual authentication, which leaves relay paths open in mixed Windows environments.

For IAM and PAM teams, the practical issue is not whether Kerberos is preferable in theory. The issue is how quickly the estate can be inventoried, segmented, and moved off NTLM without breaking operational access for systems that still depend on it.

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 relay risk?

A: Legacy authentication increases relay risk when the client proves itself without the server proving it is genuine. That asymmetry lets an attacker intercept an authentication exchange and forward it to another service that still trusts the protocol. The outcome is unauthorized access through a valid-looking session, which is why mutual authentication is such an important replacement criterion.

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 should organisations do with local accounts that still depend on NTLM?

A: Organisations should move local-account use cases to Kerberos alternatives such as local KDC or IAKerb where possible, then treat any remaining NTLM requirement as a temporary exception with a named owner. The key decision is whether the access path can be preserved without leaving hash replay and relay exposure in place.

Technical breakdown

Why NTLM relay remains possible in legacy Windows estates

NTLM authenticates by proving possession of a hash rather than a password, and that design makes relay attacks possible when the protocol is still accepted by downstream services. Because NTLM does not require the server to prove its identity to the client, an attacker can intercept an authentication exchange and forward it to another system. That one-way trust model is the core reason relaying survives in mixed environments. In practice, any legacy dependency that still accepts NTLM becomes a relay target, especially where SMB signing or extended protection is absent.

Practical implication: identify every service that still accepts NTLM and treat relay exposure as an authentication-path problem, not just a patching problem.

Pass-the-hash turns credential theft into lateral movement

Pass-the-hash works because NTLM validates the hash itself, so an attacker does not need the cleartext password to impersonate the account. If a hash is extracted from a workstation, server, or domain controller, it can often be reused directly against other systems that trust it. That is why NTLM creates a lateral movement risk distinct from ordinary password theft. The weakness is structural: the credential artifact is portable, and the protocol accepts it as sufficient proof of identity. Once one hash is compromised, the blast radius can expand quickly across administrative and service-account pathways.

Practical implication: reduce hash reuse opportunities by prioritising service accounts, local accounts, and any privileged identity that still authenticates through NTLM.

Why mutual authentication is the missing control in NTLM

Mutual authentication means both sides of the session prove who they are before trust is established. Kerberos does this with tickets and session keys, but NTLM only asks the client to prove itself to the server. That asymmetry makes adversary-in-the-middle and relay scenarios much easier to stage because the user has no cryptographic assurance that the server is genuine. In a deprecation programme, this matters because the protocol gap is not cosmetic. If the authentication method cannot validate the endpoint as well as the user, it leaves room for interception, redirection, and unauthorized access.

Practical implication: use NTLM removal as a forcing function to move every feasible workload and user flow to mutually authenticated methods.

Threat narrative

Attacker objective: The attacker aims to reuse captured NTLM material to gain unauthorized access and move laterally through Windows systems that still trust legacy authentication.

1. Entry occurs when an attacker positions a malicious endpoint or social-engineering lure to capture an NTLM authentication exchange from a Windows user or legacy client.
2. Credential access follows when the NTLM hash or authentication message is captured, giving the attacker a reusable identity artifact without needing the cleartext password.
3. Escalation and lateral movement happen when the hash is passed to another service or relayed to a different target that still trusts NTLM, enabling unauthorized access across the environment.
4. Impact is the attacker’s ability to pivot into additional systems, impersonate users, and extend compromise through trusted legacy authentication paths.

Breaches seen in the wild

• ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NTLM deprecation is really a governance correction for a broken trust model. NTLM was designed for an era when the client-server relationship was simpler and the threat model less hostile. The protocol’s one-way trust, hash validation, and relay exposure make it unsuitable for modern identity governance, especially where access boundaries must be explicit and verifiable. The practitioner takeaway is that legacy authentication should be managed as a lifecycle risk, not tolerated as an exception forever.

Pass-the-hash persists because credential artifacts outlive the session that created them. That is a structural NHI lesson even in a human-authentication article: once a reusable credential token exists, it becomes a movable object that can be replayed elsewhere. The control problem is not merely password strength. It is whether the organisation allows credential material to remain valid in a form that can be repurposed outside the original session. The practical conclusion is that identity controls must assume capture, reuse, and replay.

The architecture gap is the absence of mutual authentication at the point where trust is established. NTLM lets the server trust the client without the client proving the server is genuine, which creates a predictable relay surface. That design assumption was acceptable in older network models but fails in segmented, cloud-connected, and hybrid environments. Practitioners should treat mutual authentication as a baseline expectation for legacy replacement decisions.

Legacy authentication residue: NTLM stays alive because organisations preserve compatibility before they document dependency, ownership, and retirement criteria. That is why deprecation programmes fail when they start with protocol preferences instead of inventory and accountability. The real problem is not only technical debt but governance debt, and the implication is that offboarding legacy auth requires ownership at the application and platform level.

Kerberos migration is a control reallocation exercise, not a simple protocol swap. Microsoft’s local KDC and IAKerb approach shows that some NTLM use cases exist because organisations need a Kerberos path for local and non-domain scenarios. That means the migration question is about preserving access while removing relay-prone trust mechanics. The practitioner conclusion is to map dependencies by identity type, then retire NTLM only where the replacement path is operationally real.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.

What this signals

Legacy authentication deprecation is an access governance programme, not just a protocol preference. The organisations that succeed will be the ones that can identify every place where NTLM still underpins human, service, or device access and then remove those dependencies in sequence. In practice, the hard part is not deciding to retire NTLM, but proving which workflows can survive the cutover.

NTLM’s real risk is credential reusability under hostile conditions. Once authentication material can be replayed or relayed, the control boundary moves from password quality to trust architecture. That is why migration to mutually authenticated methods matters more than preserving the old login path with extra compensating controls.

Legacy account paths often reveal where identity governance has been deferred. When local accounts, service accounts, and embedded device credentials still depend on NTLM, the problem usually extends beyond authentication into ownership, exception management, and retirement discipline. Teams should expect NTLM removal to surface hidden technical debt across access, operations, and PAM.

For practitioners

• Build an NTLM inventory Enable NTLM auditing through Group Policy and review domain controller logs to identify legacy applications, service accounts, and devices that still depend on NTLMv1 or NTLMv2.
• Prioritise relay-hardening controls Enforce SMB signing and extended protection for authentication on systems that must remain compatible while you reduce NTLM exposure.
• Create an NTLM removal roadmap Move identified dependencies to Kerberos or a modern identity provider, then disable NTLM by default once exceptions are documented and owned.
• Review privileged and service accounts first Focus remediation on the accounts that can create the widest blast radius if hashes are reused or relayed across infrastructure.

Key takeaways

• NTLM remains a live security issue because its trust model still enables replay and relay in Windows environments that have not fully moved on.
• Microsoft’s deprecation timeline matters because the remaining NTLM footprint often includes legacy applications, local accounts, and operational devices that are easy to overlook.
• The practical control is a phased removal plan that starts with visibility, hardens the remaining paths, and ends with NTLM disabled by default.

Key terms

• 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.
• 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.
• Mutual Authentication: Mutual authentication is a two-way verification process where each party proves its identity before communication proceeds. In connected operational systems, it prevents devices and services from trusting unauthenticated peers and helps enforce identity-first security across distributed environments.
• Legacy authentication: Older login or protocol methods that remain in place for compatibility even after stronger controls exist. They often preserve weaker trust assumptions, which makes them attractive to attackers and difficult to defend if they are not tightly scoped and eventually retired.

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 building or maturing an IAM programme, it is worth exploring.