Should organisations remove NTLM entirely or keep it with compensating controls?

Why NTLM usually belongs in the exception bucket, not the default design

NTLM is a legacy authentication path, so the key question is not whether it can be secured in a narrow sense, but whether it still deserves operational trust in a modern Windows environment. In practice, the answer depends on exposure: if NTLM is still needed, it should be tightly bounded, explicitly monitored, and treated as a compatibility control rather than a preferred authentication pattern.

The protocol’s weakness is not just age. It is that NTLM can remain useful in exactly the kinds of places defenders struggle to fully constrain, especially when old applications, mixed domain configurations, or service dependencies still require it. That makes the security decision about NTLM less about policy preference and more about whether the surrounding environment can actually absorb the protocol’s risk.

For organisations trying to reduce dependency, the most defensible long-term position is to push toward stronger authentication paths and reserve NTLM only where removal would break essential business flows. The practical test is whether the remaining NTLM use can be isolated enough that it does not become a standing trust bridge across systems that should not authenticate to each other so freely.

What compensating controls can and cannot change

Compensating controls can reduce exposure, but they do not change NTLM’s core limitation: if the protocol is still accepted on valuable systems, especially domain controllers or similarly privileged hosts, it can remain an attack path. Controls such as signing, channel binding, service restriction, and tighter exposure boundaries are valuable because they shrink the set of places where NTLM can be abused.

Active Directory and Entra ID Hardening Guide is relevant because NTLM decisions sit inside broader domain hardening, where delegation, tiering, privileged groups, and service-account exposure all affect whether legacy authentication becomes a durable weakness. If the surrounding directory architecture is loose, NTLM controls are easier to bypass in practice.

Cisco Active Directory credentials leak 2025 illustrates why stolen authentication material is so dangerous in Windows environments, even when the immediate incident is not “about NTLM” alone. Once credentials or hashes are exposed, legacy authentication paths can extend the blast radius and make lateral movement easier.

Compensating controls are most credible when they are enforced at the protocol boundary and at the service boundary at the same time. If NTLM is permitted only for a known set of applications, with logging and alerting around unexpected use, it is easier to defend than if it is broadly available and merely discouraged by policy.

How to decide whether to keep NTLM at all

The right decision is usually conditional, not absolute. If there is a clean migration path to stronger authentication, removing NTLM entirely is the safer end state because it eliminates an old fallback mechanism that can be abused under pressure. If there is no viable migration yet, then the organisation should define NTLM as a controlled exception with an expiry plan, not as a permanent convenience layer.

Where NTLM must stay, the most important judgment is whether any relayable or high-value path still exists. If NTLM can reach domain controllers, privileged services, or cross-trust systems in a way that enables relay or downgrade behaviour, the protocol risk becomes structural rather than cosmetic. In that case, compensating controls may lower risk but will rarely neutralise it fully.

Segregation of Duties (SoD) Guide fits here because NTLM often survives in environments where ownership, exception handling, and service-account administration blur together. Strong governance on who can approve, extend, or operate legacy authentication is part of keeping the exception from becoming permanent drift.

For practitioners, the real decision criterion is exposure plus privilege. If NTLM is confined to low-value compatibility scenarios, with no path to privileged systems, it can sometimes be tolerated. If it is available where compromise would materially expand access, removal should be the objective even if that requires phased application remediation.

Risk and Threat Considerations

NTLM is risky because it can preserve legacy trust in places modern environments no longer need it, and that trust can be abused for relay, credential reuse, or privilege escalation. The main issue is not only direct authentication weakness, but the way NTLM can keep old paths alive inside high-value administrative boundaries.

Failure mechanism: If NTLM is accepted on sensitive systems, an attacker who can position themselves in the authentication path may be able to relay, downgrade, or reuse authentication material to move from an initial foothold into broader domain access.

Impact: The result can be lateral movement, unauthorized access to privileged services, and a much larger blast radius than the original compromise would otherwise allow.

Practitioner Guidance

What to verify: Confirm exactly which applications, servers, and trust paths still require NTLM, and separate genuine compatibility needs from habit. If you cannot explain why a system still uses NTLM, you probably have an unmanaged exception.

Decision rule: If NTLM is reachable from privileged infrastructure, treat removal as a priority remediation item; if it is limited to isolated legacy services, keep it only with a documented exception, strict monitoring, and a migration date.

Common mistake: Treating “we added controls” as proof that the protocol is now harmless. Controls reduce blast radius, but they do not make a relayable or overexposed legacy authentication path equivalent to a modern one.

Practitioner takeaway: NTLM can sometimes be tolerated, but only as a tightly governed exception. The more it touches privileged infrastructure or relayable paths, the more the right answer shifts from compensating control to removal.

Related resources from NHI Mgmt Group

• Should organisations keep classic PAM if they are moving to dynamic access controls?
• How should organisations keep ISO 27001 controls effective between audits?
• How can organisations keep AI from bypassing infrastructure controls?
• How can organisations keep compliance controls current as access changes?