Topic starter
25/06/2026 12:40 am
TL;DR: NTLM remains deeply embedded in Active Directory, but most organizations do not need it and the larger problem is that NTLM activity is hard to detect, according to Silverfort. Eliminating it requires visibility into fallback paths, risk-based blocking, and migration away from applications that still depend on legacy authentication.
Editorial analysis by NHI Mgmt Group, based on content published by Silverfort: “Guide to eliminating NTLM completely from your environment”.
Key questions
Q: Where does NTLM elimination usually fail in Active Directory programmes?
A: It usually fails at visibility and fallback detection.
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.
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.
Practitioner guidance
- 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.
Bottom line: NTLM remains embedded in many Active Directory environments because applications can silently fall back to it when Kerberos fails.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 9:38 am
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.
A question worth separating out:
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.
👉 Read our full editorial: NTLM elimination in Active Directory needs visibility first