What breaks when NTLM is still enabled in Active Directory?

Why This Matters for Security Teams

NTLM is not just a legacy authentication option. When it remains enabled in active directory, it preserves a replayable path that can be abused after an endpoint is compromised, even if the attacker never learns the user’s password. That changes the problem from credential theft to directory trust abuse, where one leaked hash or relay opportunity can become broad lateral movement.

Security teams often underestimate how much NTLM expands the blast radius of routine endpoint compromise. Password hygiene alone does not close that gap, because the issue is protocol behaviour, not just credential strength. NHI Management Group has documented how identity compromise often moves faster than remediation, with the Ultimate Guide to NHIs showing that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, a reminder that weak identity paths are routinely exploited once attackers get inside. The same pattern appears in real incidents such as the Cisco Active Directory credentials breach, where identity material became the pivot for broader access.

Practitioners who treat NTLM as a harmless fallback usually discover too late that it creates an attacker-friendly trust layer rather than a defensive safety net. In practice, many security teams encounter NTLM abuse only after a workstation or helpdesk account has already been turned into a directory foothold, rather than through intentional removal of the protocol.

How It Works in Practice

NTLM breaks modern access control assumptions because it relies on challenge-response behaviour that can be relayed, replayed, or coerced in ways that Kerberos is designed to resist. If an attacker captures NTLM material from a compromised endpoint, they may not need to crack anything. They can often relay that authentication to another internal service, impersonate the user to a target host, or chain access into privileged systems that still trust NTLM.

This is especially dangerous in environments where service accounts, legacy applications, or unmanaged appliances still depend on NTLM. Those systems tend to become hidden trust anchors. Once NTLM is enabled broadly, defenders lose a clean boundary between authenticated and exploitable traffic, which makes least privilege harder to enforce and incident containment slower.

• Use protocol auditing to identify where NTLM is still accepted, then map those endpoints to business-critical dependencies.
• Replace NTLM with Kerberos wherever possible, and plan staged exceptions only for systems that cannot be remediated immediately.
• Restrict NTLM through policy, not just documentation, because users and admins will otherwise fall back to it during outages.
• Pair decommissioning with monitoring for relay attempts, unusual authentication flows, and repeated fallback to legacy logons.

For baseline control design, NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports strong authentication, account management, and least-privilege enforcement, but current guidance is only part of the answer because protocol exposure must also be removed. These controls tend to break down when NTLM is still required by line-of-business apps or domain-joined legacy systems because defenders cannot fully eliminate the fallback path without a migration plan.

Common Variations and Edge Cases

Tighter NTLM restriction often increases migration effort, requiring organisations to balance immediate attack reduction against application compatibility and support cost. That tradeoff is real, especially in mature Active Directory estates with old print services, embedded devices, vendor appliances, or applications that were never rebuilt for Kerberos.

Best practice is evolving rather than universally settled for every edge case. Some environments can disable NTLM outright, while others need a phased approach that includes application inventory, authentication telemetry, and exception governance. The important distinction is that exceptions should be temporary and measurable, not permanent because a legacy team requests them. Where business constraints prevent full removal, treat every NTLM allowance as an explicit risk acceptance with expiry.

Organizations also need to distinguish between technical dependency and operational convenience. If NTLM remains enabled simply because “it still works,” the real issue is usually ownership, not compatibility. NHI Management Group’s research shows how often identity hygiene gaps persist unnoticed, which is why the same governance discipline used for service accounts should apply to legacy authentication paths as well. In practice, NTLM survives longest in environments where nobody has a clear inventory of which systems still need it and which ones only appear to need it.

Related resources from NHI Mgmt Group

• Why do Active Directory service accounts complicate zero trust programs?
• What breaks when Active Directory accounts are still trusted after exposure?
• What breaks when passkeys can still be enrolled through weak proofing steps?
• How should security teams reduce NTLM relay risk in Active Directory?