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

Why This Matters for Security Teams

NTLM is usually a legacy compatibility layer, not a security strategy. The hard part is proving whether it is still in active use across applications, devices, scripts, and service accounts, because silent dependencies often survive long after the original owner has left. NHI Management Group data shows that only 5.7% of organisations have full visibility into their service accounts, which is why NTLM can persist unnoticed until a migration, hardening effort, or incident exposes it.

Security teams should treat NTLM as a dependency discovery problem first and a protocol decision second. That means mapping authentication logs, identifying where NTLM is generated, and validating whether a modern replacement is viable under real operating conditions. NIST guidance on access control and monitoring in NIST SP 800-53 Rev 5 Security and Privacy Controls supports that evidence-based approach. The practical question is not whether NTLM is old, but whether any business process still breaks without it.

In practice, many security teams discover NTLM dependencies only after a domain hardening project or authentication outage has already forced the issue.

How It Works in Practice

The reliable way to determine whether NTLM is still needed is to measure actual usage, then test replacements in a controlled scope. Start by collecting authentication telemetry from domain controllers, servers, endpoints, and application logs. Look for NTLMv1, NTLMv2, fallback authentication, and services that authenticate with machine accounts or service accounts rather than human users. Then classify each hit by business function, owner, and replacement path.

For many environments, Kerberos is the first candidate replacement because it supports mutual authentication and is already native to Active Directory. Where Kerberos cannot reach a workload, local KDC patterns or IAKerb may help bridge constrained scenarios, but current guidance suggests these are replacement options to validate, not blanket answers. The objective is to prove that the workload still functions when NTLM is removed or restricted.

• Inventory every source of NTLM traffic, including legacy applications, managed devices, scanners, and scheduled jobs.
• Test authentication using Kerberos first, then evaluate local KDC or IAKerb where Kerberos fails.
• Document each remaining NTLM dependency with owner, business justification, and an expiry date.
• Monitor for drift so that a retired dependency does not quietly reappear after patching or vendor updates.

For broader NHI lifecycle discipline, NHI Management Group’s Ultimate Guide to NHIs is useful because the same visibility gap that hides stale service accounts also hides legacy authentication paths. A real-world example of why this matters is the Cisco Active Directory credentials breach, where credential exposure created downstream authentication risk. These controls tend to break down in mainframe-connected, vendor-managed, or protocol-constrained environments because the application owner cannot quickly validate a non-NTLM path.

Common Variations and Edge Cases

Tighter NTLM restriction often increases operational friction, requiring organisations to balance authentication hardening against application stability. That tradeoff is real in brownfield estates, especially where embedded devices, third-party appliances, or line-of-business software only support NTLM at all. Best practice is evolving, and there is no universal standard for this yet, so exceptions should be temporary, reviewable, and tied to a migration plan rather than left as permanent waivers.

Edge cases usually fall into three categories. First, a system may still need NTLM only because it has not been retested against Kerberos after an infrastructure change. Second, a vendor product may advertise support for modern authentication but fail in specific flows such as service-to-service calls or scheduled tasks. Third, local security constraints may require short-lived continuation of NTLM while a replacement is built. In each case, the team should distinguish technical necessity from organisational inertia.

The safest operating model is to treat NTLM as an exception requiring owner sign-off, time-bound approval, and periodic retesting. That aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls for control monitoring and with NHIMG guidance that visibility must extend to service accounts and legacy authentication paths. If a team cannot explain why NTLM remains necessary, it is usually still there because no one has yet forced the dependency to surface.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How do security teams know whether least privilege is actually working?
• How do security teams know whether OIDC-based roles are actually safe?
• How do security teams know whether privacy controls are actually working?