Authentication relaying is an attack technique that forwards a victim’s login attempt to another service in real time. The attacker does not need to know the password or crack the hash, because the service accepts the relayed authentication exchange as if it came from the original user.
How authentication relaying works
Authentication relaying is dangerous because the attacker is not breaking the password, they are reusing the victim’s valid sign-in exchange in real time. That makes the technique effective against systems that trust the authentication handshake itself, especially where the protocol or deployment does not require strong channel binding or relay-resistant verification.
Relaying is most often discussed alongside protocol-level weaknesses rather than user mistakes alone. It can succeed when an application accepts a forwarded authentication exchange, when a service account or legacy endpoint is reachable, or when the environment allows an attacker to sit in the middle of a valid login flow.
In practice, the technique sits at the intersection of authentication design and adversary abuse of trust. It is less about guessing secrets and more about intercepting, forwarding, and replaying a legitimate exchange before the session context can be tied to the original endpoint or user gesture.
Why authentication relaying is effective
The core weakness is trust in the authentication transaction rather than only the user’s secret. If a service accepts the forwarded challenge-response exchange without proving that the client is the same endpoint that started it, the attacker can turn one successful login attempt into access to another system.
This is why relaying is particularly relevant in environments with older authentication paths, weak mutual-authentication expectations, or permissive trust relationships between internal services. It is also why relay attacks are often paired with credential interception, local network positioning, or forced authentication events that make a victim initiate the handshake.
Relay success can expose not just an account, but the privileges attached to that session. Once the attacker lands in a trusted application or management plane, they may be able to enumerate resources, access internal data, or pivot into adjacent systems using the authenticated context they have captured.
Where organisations should look for exposure
Exposure usually starts with the authentication surface itself: legacy protocols, internal-only services that still accept older login methods, and systems that cannot distinguish a real endpoint from a forwarded exchange. A complete asset inventory matters because relays often succeed on the forgotten service, not the flagship one.
Internet exposure can also matter when authentication endpoints, gateways, or related support services are reachable in ways the organisation did not intend. Vendor advisories and protocol guidance are important here because version-specific hardening details often determine whether a relay path is still practical.
Detection and review should focus on unexpected authentication patterns, unusual source or destination relationships, and signs that an interactive login was used to reach a service that normally should not be accessed that way. After a suspected relay, organisations should review what the authenticated session could do, not just whether a password was known.
Mitigations and compensating controls
Defences work best when they make the authentication exchange non-transferable. Stronger authentication designs, relay-resistant protocol settings, and channel-bound or certificate-bound approaches reduce the chance that a forwarded login will be accepted as genuine.
Where immediate remediation is not possible, organisations should reduce the value of any relayed session by tightening access paths, limiting where authentication is accepted, and removing legacy or unnecessary trust relationships. Segmentation and least privilege help because a relayed login is only as useful as the permissions behind it.
It is also important to harden the surrounding identity flow. Strong recovery processes, reduced reliance on legacy authentication, and better session controls make it harder for an attacker to turn a single intercepted login into durable access. NHIMG’s MFA Guide is useful background on how attackers bypass weaker sign-in methods, and the NIST SP 800-63 Digital Identity Guidelines provide a reference point for phishing-resistant authentication design.
What post-compromise review should cover
After a suspected relaying incident, the most important question is what the attacker could reach with the relayed session. That means reviewing access logs, service interactions, administrative actions, and any secondary authentication tokens or secrets issued during the session.
If the relayed login was used to access privileged tools, internal applications, or token-issuing services, organisations should treat the event as more than a single account issue. The resulting session may have exposed API keys, bearer tokens, service credentials, or other secrets that need rotation or revocation.
Follow-up should also include a search for persistence. An attacker who successfully relays authentication once may return through the same weak path, so the review should confirm whether the original relay condition has been closed and whether any additional trust path remains open.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Relaying abuses weak authentication assurance for user sign-ins. |
| IA-5 — Authenticator Management | Relay incidents often require review and rotation of issued authenticators or credentials. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Many relay paths affect external or partner access portals as well as internal users. | |
| Recommendation — Enforce strong user authentication and reject login flows that can be forwarded unchanged. Rotate affected credentials and tokens after suspected relay exposure. Apply stronger authentication requirements to external access paths that can be relayed. | ||
| OWASP ASVS | V6 — Authentication | Authentication relaying is an authentication failure mode that ASVS tests should cover. |
| V7 — Session Management | Relay attacks often succeed by abusing how a valid session is established and reused. | |
| V8 — Authorization | A relayed session becomes dangerous when authorization is too broad. | |
| Recommendation — Verify that authentication flows resist relay and other exchange-forwarding attacks. Check that session handling cannot be detached from the original authentication context. Review authorization boundaries so a captured session cannot perform excessive actions. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | CSF 2.0 explicitly covers authenticating and controlling access in a way relay attacks undermine. |
| Recommendation — Strengthen identity and access controls so forwarded sign-ins are not accepted as legitimate. | ||
| MITRE ATT&CK | T1550.002 — Use Alternate Authentication Material: Pass the Hash | Authentication relaying belongs to the broader adversary pattern of abusing authentication material instead of knowing the password. |
| Recommendation — Map relay-related detections to credential-abuse techniques and hunt for unusual authentication reuse. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org