Because relay risk is controlled by the service that accepts the authentication, not by the name of the protocol being used. Kerberos can still be relayed if the target service does not require signing or CBT, so a protocol migration without service hardening leaves the abuse path intact.
What actually has to be hardened to stop relay attacks
Relay attacks survive protocol migration because the weakness is usually in the receiving service’s acceptance rules. If a target still allows inbound authentication that can be replayed or forwarded without message integrity, an attacker can still bridge a victim connection into a valid session even after NTLM is removed. The control point is the service, not just the client-side protocol choice.
In Windows AD, that means looking at the authentication path end to end: what the server accepts, what protections it requires, and whether the negotiated session is bound strongly enough to the channel. Without those checks, switching to Kerberos only changes the mechanism on paper. It does not remove the relay condition that lets an attacker reuse a live authentication exchange against a different target.
That is why signing, channel binding, and protocol-specific hardening matter more than a simple “disable NTLM” policy. For a relay to fail, the target must reject messages that are not cryptographically tied to the intended channel or service. If the service can be reached through an exposed, unsigned, or weakly bound path, the relay path remains operational.
Why Kerberos can still be abused after NTLM is gone
Kerberos is often treated as a safer default, but it is not automatically relay-proof. When the target service does not enforce signing or CBT, an attacker may still be able to forward an authenticated exchange into a service that trusts the session without sufficiently binding it to the original endpoint. The protocol name changed, but the trust assumption did not.
This is where administrators often overestimate the value of migration projects. Replacing NTLM with Kerberos reduces one known relay surface, but relay is a property of the service’s acceptance of authenticated traffic. If the server accepts the session without checking integrity and channel binding, the attacker’s opportunity shifts rather than disappears.
In practice, the most important question is whether the service enforces the protections that make relaying fail in transit. That can include SMB signing, LDAP signing, EPA or channel binding where supported, and disabling unauthenticated or weakly authenticated access paths. The exact hardening step depends on the service, but the principle is consistent: bind authentication to the intended destination.
Why this is an AD hardening problem, not just an auth migration problem
Windows AD environments usually fail at the boundary between identity policy and service configuration. Teams may complete a protocol migration, yet leave legacy settings, incompatible clients, or convenience exceptions in place on LDAP, SMB, HTTP, or other services that still accept relayed authentication. That leaves a live abuse path even though the authentication stack looks modern.
Guidance from the broader AD hardening literature supports the same conclusion: protect privileged and directory-sensitive services first, then remove weak acceptance points that allow coerced or forwarded authentication. For readers mapping this to operational controls, Active Directory and Entra ID Hardening Guide is the strongest internal navigation point for service hardening priorities, while Cisco Active Directory credentials leak 2025 illustrates how directory credential exposure and lateral movement become operationally dangerous once trust is abused.
Protocol removal is therefore a hygiene step, not a complete defensive outcome. The real control objective is to ensure that authenticated sessions cannot be redirected into a service that lacks the right integrity and binding checks. If that objective is unmet, the environment still has a relay problem regardless of the protocol in use.
Risk and Threat Considerations
Relay exposure matters because it turns any coerced or intercepted authentication into unauthorized access on a downstream service. Attackers do not need to defeat the original protocol if they can reach a target that accepts forwarded authentication without signing or channel binding. In AD environments, that can turn a single weak service into a path toward directory compromise or privilege escalation.
Failure mechanism: The service accepts an authentication exchange that is not tightly bound to the original channel or target, so the attacker forwards it to a different endpoint and obtains a valid session.
Impact: Credential abuse can continue after NTLM removal, especially on legacy or weakly hardened services, and the resulting access may enable lateral movement, privilege escalation, or persistent footholds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Relay resistance depends on strong server-side authentication handling and channel binding. |
| SC-23 — Session Authenticity | Relay attacks exploit sessions that are not bound to the intended peer or channel. | |
| IA-5 — Authenticator Management | Hardening relay paths depends on managing authenticators and removing weak legacy acceptance paths. | |
| Recommendation — Require services to enforce authenticated sessions with binding and integrity checks. Enforce session binding so relayed authentication cannot be reused elsewhere. Retire weak authenticators and enforce controlled credential lifecycle handling. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question centers on refusing implicit trust in an authenticated connection. |
| Recommendation — Treat every authenticated request as untrusted until the service verifies channel and context. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Relay prevention requires removing weak access paths and tightening service acceptance rules. |
| Recommendation — Restrict service access paths that still accept relayed authentication. | ||
Practitioner Guidance
What to verify: Validate the protections on the service itself, not just the auth stack. If the service can accept inbound auth without signing, strong channel binding, or equivalent protection, treat it as relay-prone even when NTLM is disabled.
Decision rule: If the environment still has LDAP, SMB, HTTP, or other services with weak acceptance settings, prioritise service hardening before claiming the relay path is closed. If you cannot verify binding and integrity requirements, assume the attack path still exists.
Practitioner takeaway: Removing NTLM reduces one relay mechanism, but only service-level hardening closes the abuse path; authentication must be bound to the target, not merely expressed through a different protocol.