Why NTLM is rarely a single switch
In many environments, NTLM was not designed intentionally. It stayed behind: old appliances, scanners, file servers, service accounts and legacy web applications. Blocking it globally often turns dependency discovery into an outage.
The better approach is plain: measure, find owners, reduce, then block.
Project sequence
- Enable NTLM auditing on domain controllers.
- Make incoming NTLM usage visible on servers.
- Identify and remove NTLMv1 first.
- Keep exceptions only with owner, expiry date and target fix.
- Check Kerberos readiness: SPNs, DNS, time, delegation and service accounts.
What usually blocks progress
NTLM reduction is not only a GPO topic. The blockers are often application configuration, missing SPNs, IP-based access or weak service-account design.
What gets better
- Old authentication becomes visible and can be removed from critical paths.
- Kerberos becomes the planned target state again instead of an accidental exception.
- Relay and credential risks lose reach when NTLM is less available.
Where it can hurt
- NTLM dependencies often live in applications, appliances or IP-based access, not only in Windows policies.
- Blocking too quickly causes outages that are hard to assign to an owner.
- Permanent exceptions prevent real risk reduction.
Checks before rollout
- Which NTLM usage comes from clients, servers and service accounts?
- Which cases are NTLMv1 and must go first?
- Which SPNs, DNS names or service accounts prevent Kerberos?
- Which exception expires when?
Bottom line
NTLM does not disappear by intent alone. Good projects make usage visible and remove legacy dependencies step by step.