What should teams do when NTLM and other authentication protocols need protection against relay attacks?

Teams should combine patching with protocol-aware policy enforcement. Start by updating Outlook clients, then apply MFA rules to NTLM and, where needed, to related protocols such as Kerberos and LDAP. Include internet-exposed servers first, then extend coverage to sensitive internal resources. The goal is to make stolen credentials far less useful for access and lateral movement.

Why relay protection needs both protocol changes and policy enforcement

Relay attacks succeed when an authentication exchange is accepted somewhere other than the intended target, so the practical defense is not a single control. Teams need to reduce the value of captured challenge-response material, then make sure the receiving service rejects or constrains replayed authentication in the first place. That is why patching alone is usually incomplete.

For NTLM specifically, the highest-risk pattern is exposure of older client or server behavior that still accepts relayed handshakes in places where stronger controls are available. Updating Outlook clients helps close one common path, but the broader objective is to enforce protocol-aware rules that limit where NTLM is still trusted and where stronger authentication requirements apply.

When the same logic is extended to related protocols such as Kerberos and LDAP, the security goal is consistency. If one protocol is hardened but a neighboring protocol still allows relay-friendly behavior, attackers often shift to the weaker path rather than abandon the attempt. Teams should therefore treat relay protection as an access-path problem, not just a protocol-specific bug fix.

Where to apply the controls first

The best rollout order is to cover internet-exposed systems and the authentication paths most likely to be probed first, then expand inward to high-value internal resources. That sequencing matters because relay attempts often begin at the perimeter or through a compromised endpoint, and the biggest reduction in practical risk usually comes from blocking the easiest and most valuable relay targets early.

It is also useful to distinguish between broad coverage and sensitive coverage. Some internal services do not justify the same urgency as directory services, admin consoles, file services, or systems that can directly enable lateral movement. Prioritizing by blast radius helps teams spend effort where a relayed authentication would create the most meaningful exposure.

Patch clients and servers that sit on the most exposed authentication paths first.
Enforce stronger authentication rules on services that accept NTLM or similar protocols.
Extend the policy to adjacent authentication paths so attackers cannot simply move sideways.
Validate that the most sensitive internal systems are covered after perimeter-facing systems are stable.

Risk and Threat Considerations

Relay attacks are dangerous because they turn a legitimate authentication exchange into an access path that can be replayed against a different target. If the target still accepts that protocol or lacks compensating policy controls, a stolen challenge-response exchange can become unauthorized access, privilege escalation, or a foothold for lateral movement.

Failure mechanism: An endpoint, server, or directory service accepts relayed authentication for a protocol that still permits it, or a client remains on an older build that preserves the attack path. Attackers then reuse captured authentication material against a service that trusts the exchange too broadly.

Impact: Stolen credentials and authentication artifacts remain useful for access, movement, and persistence, especially where the relayed protocol reaches sensitive internal resources or administrative interfaces.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 6 — Access Control Management	Relay defense depends on restricting authentication paths and access rights.
	CIS Control 5 — Account Management	Relay attacks become useful when account and access handling stays overly permissive.
Recommendation — Restrict authentication paths and enforce least-privilege access to reduce relay abuse. Audit and tighten account usage rules for services that still rely on NTLM or similar protocols.
NIST CSF 2.0	PR.AC-1 — Identities and Credentials Issued, Managed, Verified, Revoked	Protocol relay protection requires sound handling of authentication and credential trust.
	PR.AC-4 — Access Permissions and Authorizations Managed	Policy enforcement must constrain which systems accept legacy or relay-prone authentication.
	PR.PS-1 — Configuration Management	Updating clients like Outlook is a configuration control that closes known relay paths.
Recommendation — Manage and verify credentials so relayed authentication cannot be reused freely. Constrain access permissions so only approved systems accept the relevant authentication methods. Patch and standardize client and server configurations to remove known relay-prone behavior.
MITRE ATT&CK	T1557 — Adversary-in-the-Middle	Relay attacks are a form of adversary-in-the-middle abuse of authentication flows.
	T1550 — Use Alternate Authentication Material	Attackers rely on reusable authentication material when relaying NTLM or similar protocols.
Recommendation — Detect and disrupt adversary-in-the-middle paths that relay authentication exchanges. Hunt for abuse of stolen authentication material and block its reuse across services.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Relayed authentication becomes valuable when credentials and authentication material remain reusable.
Recommendation — Reduce credential reuse and rotate sensitive authentication material that could be relayed.

Practitioner Guidance

What to verify: Confirm that the controls are enforced on the actual services that matter, not only on a test segment or a single client group. If Outlook is updated but NTLM remains broadly accepted elsewhere, the risk reduction may be far smaller than expected.

Implementation sequence: Start with the highest-exposure client and server population, then check whether Kerberos and LDAP rules create blind spots that let attackers route around the NTLM hardening. If a protocol remains necessary, constrain where and how it can be used rather than assuming the protocol is safe by default.

Practitioner takeaway: The real win is reducing the number of places where captured authentication can still buy access, because relay attacks usually fail only when both the protocol path and the target policy are hardened together.