An identity relay chain is the sequence in which one compromised account, token, or mailbox is used to gain more access through trusted workflows. It is especially dangerous because the attacker can move from initial compromise to internal trust exploitation without needing malware on every endpoint.
What an Identity Relay Chain Is
An identity relay chain is not a single compromise event, it is a sequence of trusted handoffs. One account, token, or mailbox is abused to reach the next system or identity, allowing an attacker to move laterally by exploiting normal trust relationships.
The idea matters because the initial foothold is often small, but the path forward is built on legitimate workflows. That makes the chain harder to spot than overt malware-based intrusion, since each step can look like ordinary authentication, delegation, forwarding, or approval activity.
Relay chains often begin with stolen credentials, token replay, mailbox compromise, or session abuse, then progress through delegated access, inbox rules, OAuth grants, shared links, internal tickets, or service workflows. The security problem is not just the first compromise, but the fact that trust is reused as the attacker’s transport mechanism.
How the Chain Progresses Through Trusted Workflows
Relay chains usually depend on identity relationships that were designed to reduce friction, such as single sign-on, delegated administration, mailbox forwarding, approval flows, or application-to-application trust. When those relationships are overly permissive, the attacker does not need to break each boundary from scratch. They can reuse the existing one, then step into the next.
That is why the chain is especially dangerous in hybrid environments where human and non-human access overlap. A mailbox, token, or service credential can become a launch point for internal pivoting, and the next hop may be a platform account, privileged role, or connected application rather than a direct endpoint compromise. Resources such as Ultimate Guide to NHIs — What are Non-Human Identities help frame how token-based and workload-based access can become part of that trust path.
Because the relay is built from legitimate mechanisms, defenders often see only pieces of the path unless identity, mail, and access telemetry are correlated. A control failure at one step can be amplified by the next step’s inherited trust, which is why the whole chain must be understood as one abuse pattern rather than several unrelated incidents.
Why Identity Relay Chains Are Hard to Detect
Relay chains are difficult because each individual action may be valid in isolation. A login can succeed, a mailbox rule can be created, a token can be used, or an approval can be issued without triggering obvious alarms. The abuse emerges only when those actions are viewed in sequence and tied to unusual trust movement.
Detection also breaks down when organizations rely on narrow signal ownership. Email security may see the mailbox compromise, identity teams may see the login, and application teams may see the downstream access, but none of them sees the entire abuse path alone. MITRE ATT&CK Enterprise is useful here because it models credential access, privilege escalation, and lateral movement as linked behaviors rather than isolated events.
In practice, the most suspicious pattern is often not a single high-severity alert, but a believable sequence of low-friction trust transitions, especially where one identity suddenly begins exercising access that normally belongs to another.
Controls That Break the Relay Path
Stopping a relay chain requires more than password resets. The underlying trust path has to be tightened so that one compromised identity cannot easily unlock the next one. That means limiting delegated access, reducing standing privilege, restricting forwarding and token persistence, and making cross-system trust more explicit and revocable. The broader lifecycle and governance implications are well covered in NHI Lifecycle Management Guide and Identity Security Programme Guide.
For technical governance, authentication strength, token handling, and identity assurance need to match the value of the downstream access. NIST SP 800-63 Digital Identity Guidelines is relevant where assurance, authenticator strength, and session trust determine whether the first compromise can be chained into more access. In cloud environments, CSA Cloud Controls Matrix is a useful control lens for identity governance and access control discipline.
Practically, the best defense is to reduce the value of any single foothold and make every handoff observable, bounded, and easy to revoke.
Risk and Threat Considerations
Identity relay chains create disproportionate risk because they turn trusted workflows into attacker infrastructure. A compromise that begins in email, SSO, or token handling can expand into broader internal access without malware, which makes the intrusion quieter and often longer-lived.
Failure mechanism: The attacker abuses legitimate identity transitions, such as forwarding, delegation, consent, token reuse, or inherited trust, to move from one account or system to the next while staying inside expected workflow behavior.
Impact: The result can be mailbox takeover, privilege escalation, unauthorized application access, internal data exposure, and faster lateral movement across business systems.
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 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | Identity relay chains rely on abused legitimate accounts and sessions. |
| T1114 — Email Collection | Mailbox compromise often serves as the first relay step in trusted workflows. | |
| Recommendation — Hunt for valid-account abuse and correlate unusual access sequences across identities. Monitor mailbox access, forwarding, and rule changes for chaining behavior. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Relay chains often exploit token, secret, and session lifecycle weaknesses. |
| AC-6 — Least Privilege | Relay chains succeed when one identity can unlock too much downstream access. | |
| Recommendation — Enforce short-lived authenticators and revoke compromised credentials quickly. Limit delegated and standing access so one compromise cannot fan out. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Assurance strength shapes how much trust downstream systems place in an identity event. |
| Recommendation — Align assurance requirements to the sensitivity of downstream access decisions. | ||
Practitioner Guidance
What to watch for: Treat unusual trust chaining as a first-class investigation signal, not just a series of routine logins. A sudden sequence of mailbox changes, token use, new delegations, cross-account access, or approvals from an unexpected identity often indicates relay behavior rather than ordinary user activity.
Governance implication: Ownership for mail, identity, token, and application trust paths should be explicit, because relay chains exploit seams between teams as much as they exploit technical weakness. If no team is accountable for the full chain, the attacker effectively gets one.
Practitioner takeaway: The key question is not “was the first account compromised?”, but “what trusted path did that compromise unlock next?”