It fails when teams assume one mitigation blocks all relay paths. The guidance here is specific to AD CS, but the same coercion technique can still be used against other targets if NTLM remains available elsewhere. Hardening one service does not remove the underlying authentication exposure across the domain.
Where NTLM Relay Defense Breaks When Only One Server Is Hardened
ntlm relay defense fails at the boundary, not just the target. If teams harden only the victim server, they often leave other NTLM-enabled services reachable, so the relay path still exists somewhere else in the domain. The practical failure is assuming a single hardened endpoint removes a protocol-level exposure that is really distributed.
The key issue is that NTLM relay is a trust-boundary problem. One server may reject relay in its own configuration, but if coercion, SMB signing gaps, unconstrained delegation patterns, or AD CS-related endpoints remain available elsewhere, the attacker can pivot to a different service that still accepts the relayed authentication.
This is why “the victim is hardened” is not the same as “relay is broken.” The security outcome depends on whether the broader environment still permits authentication reuse across multiple reachable services, not on one machine’s local posture alone.
Why Single-Target Hardening Misses the Real Relay Path
Hardening one server can reduce one exploit path, but it does not remove the attacker’s ability to search for another reachable NTLM consumer. In practice, relay succeeds when there is any place to send the coerced authentication that still trusts NTLM and lacks the right protections. That means the defender must reason about the whole set of reachable services, not one victim system.
For this reason, NTLM relay defenses are usually only durable when they combine service hardening with broader control reduction: disabling NTLM where possible, enforcing signing or channel binding where supported, reducing coercion opportunities, and closing the downstream services that can still be abused. A point fix on the eventual target leaves the authentication mechanism intact.
The most useful mental model is that relay defense is a path problem. The attacker needs one source of coerced authentication and one destination that will accept it. If either side remains available somewhere else, the technique can still work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Relay defense hinges on controlling authentication use across reachable services. |
| PR.AC-4 — Access Permissions and Authorizations | A relayed NTLM response succeeds when downstream services still grant access. | |
| Recommendation — Restrict authentication paths and enforce access controls across all reachable services. Remove unnecessary authorization paths that still accept relayed credentials. | ||
| CIS Controls v8 | 6.3 — Data Recovery and Identity Management | NTLM relay exposure persists when legacy authentication remains available in the environment. |
| Recommendation — Disable or tightly limit legacy authentication and verify remaining access paths. | ||
| NIST SP 800-63 | 5 — Authentication and Lifecycle Management | The question concerns how an authentication method remains reusable across services. |
| Recommendation — Assess whether the authentication method can be reused outside the intended trust boundary. | ||
| MITRE ATT&CK | T1187 — Forced Authentication | NTLM relay commonly starts with coerced authentication before the relay destination is chosen. |
| Recommendation — Detect and block forced-authentication attempts that feed relay attacks. | ||
Practitioner Guidance
What to verify: Confirm whether NTLM is still accepted by any service that can be reached from the same coercion path, not just by the server you hardened. Check related AD CS endpoints, SMB signing enforcement, and any legacy applications that still rely on NTLM.
Decision rule: If the control only protects one host but leaves other relay destinations or coercion conditions in place, treat the mitigation as partial and assume the relay path still exists.
What good looks like: NTLM is either removed or tightly constrained across the domain, and the reachable service set has been reduced so that a coerced authentication cannot be reused against an alternate target.
Practitioner takeaway: Effective relay defense is domain-wide path reduction, not single-server hardening; if any reachable NTLM target remains, the attack may still be viable.
Related resources from NHI Mgmt Group
- Where do MCP server deployments most often fail in practice?
- What are the signs that attackers may be using credentials after an initial server compromise?
- What are the signs that identity protections are failing in practice?
- Why does device fingerprinting improve brute force defense compared with IP based rate limiting?
