Notifications
Clear all
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.
NHIMG editorial — based on content published by Silverfort: Eliminating NTLM in Active Directory
Questions worth separating out
Q: How should security teams eliminate NTLM without breaking legacy applications?
A: Start by inventorying where NTLM is actually used, then separate true application dependence from hidden Kerberos fallback.
Q: Why do NTLM fallback paths create more risk than teams expect?
A: Because a successful authentication does not always mean the preferred protocol succeeded.
Q: How do you know if NTLM elimination is actually working?
A: You know it is working when authentication logs show falling NTLM usage, fewer Kerberos failures that convert into NTLM, and a shrinking set of destination systems still relying on legacy authentication.
Practitioner guidance
- Map every NTLM dependency across applications and clients Use authentication logs, NTLM protocol filters, and destination grouping to identify where NTLM is still used, then separate application dependence from client fallback behaviour.
- Review Kerberos failures before tightening NTLM policy Investigate denied Kerberos attempts for SPN issues, hostname misuse, or application errors, because unresolved Kerberos problems will keep reintroducing NTLM as a fallback path.
- Block NTLMv1 and treat NTLMv2 as transitional Use Group Policy to refuse LM and NTLMv1, then build a migration plan for any remaining NTLMv2 dependencies so the environment does not settle into permanent exception handling.
What's in the full article
Silverfort's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Event ID 4624 and 4776 log collection for NTLM discovery
- Group Policy settings for refusing LM and NTLMv1 in Domain Controllers
- Practical examples of SPN troubleshooting and hostname-based Kerberos recovery
- Driver-level and application-level checks for moving workloads off NTLM
👉 Read Silverfort's guide to detecting and eliminating NTLM in Active Directory →
NTLM elimination in Active Directory: are your controls ready?
Explore further
25/06/2026 9:38 am
NTLM elimination is really a fallback governance problem, not a protocol cleanup exercise. The article shows that NTLM survives when Kerberos fails and no one is watching the reason for the fallback. That means the real control gap is observability over authentication path selection, not just a policy switch. Practitioners should frame NTLM removal as governance over exception handling.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often identity hygiene lags behind operational reality.
A question worth separating out:
Q: What should identity teams prioritise before enforcing a full NTLM shutdown?
A: They should prioritise application compatibility, dependency mapping, and executive agreement on replacement timelines. Full shutdown works only when teams have identified which systems can move to Kerberos, federated identity, or certificates, and which systems must be upgraded or retired because they cannot survive without NTLM.
👉 Read our full editorial: NTLM elimination in Active Directory needs visibility first
