An MFA relay attack is a fraud technique that tricks a user into approving a login while the attacker forwards the authentication in real time. The attacker captures credentials or a one-time code, relays it to the target service, and completes sign-in before the code expires, bypassing the intended second factor.
What an MFA relay attack is
An MFA relay attack abuses the fact that many authentication flows still rely on a user-facing approval, code, or session step that can be forwarded in real time. The attacker is not “breaking” the factor so much as interposing themselves between the user and the target service.
This makes the attack fundamentally different from simple password theft. The credential may be phished, captured, or relayed, but the decisive step is that the attacker preserves the authentication exchange just long enough to complete sign-in before the one-time factor expires.
How the relay works in practice
The usual pattern is simple: the victim is prompted to authenticate, the attacker captures the response as it happens, and the attacker forwards that response to the real service immediately. In many cases the user believes they are approving a legitimate login, while the attacker is actually authenticating to a separate session in parallel.
Because the attack is real time, speed matters. The attacker needs a live channel, a convincing lure, and a target that will accept the relayed proof without strong phishing resistance. That is why relay attacks commonly show up in campaigns that combine social engineering with session theft or token theft.
Related breach writeups such as Uber Breach and Microsoft Midnight Blizzard breach show how real-world compromise often depends on abusing authentication flow weaknesses rather than defeating the password alone.
Why MFA relay attacks succeed
Relay attacks succeed when the second factor is treated as proof that can be forwarded, replayed, or socially engineered in the moment. Push fatigue, unsuspecting code entry, and poorly protected session handoff all weaken the intended separation between the user’s presence and the service’s trust decision.
Phishing-resistant methods change this equation by binding the response to the origin and challenge context, which makes forwarding to another site much harder. Guidance in NIST SP 800-63 Digital Identity Guidelines is especially relevant because it distinguishes stronger authenticators from those that remain relayable in practice.
For teams studying the broader technique family, CISA cyber threat advisories provide current attacker patterns, while MITRE ATT&CK Enterprise Matrix helps map the surrounding credential-access and lateral-movement behaviours.
Security implications for identity and access
An MFA relay attack turns a single successful sign-in into full account compromise, so the downstream impact is often much broader than the login event itself. Once the session is established, the attacker may access email, internal tools, cloud consoles, or privileged workflows if the account already carries those permissions.
This is why authentication quality and authorization scope have to be considered together. A relayable factor does not just weaken login assurance, it can also become a bridge into higher-value assets when the authenticated session inherits excessive access.
Where the login endpoint is exposed through APIs or browser flows, the most relevant control lens is still the authentication journey itself, not just the user interface. In those environments, broken authentication and weak session handling often create the opening that relay attacks exploit.
Risk and Threat Considerations
MFA relay attacks matter because they let an attacker convert a live user interaction into unauthorized access without waiting to crack the factor later. The risk is highest where a stolen session immediately exposes sensitive systems, privileged functions, or trusted internal applications.
Failure mechanism: The attacker relays the challenge or approval in real time, preserving a valid authentication exchange long enough for the target service to issue a session to the attacker instead of the legitimate user.
Impact: The resulting compromise can lead to mailbox takeover, internal tool access, privilege escalation, and secondary theft of secrets or tokens that extend the breach beyond the initial account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authenticators that reduce relayable MFA abuse. |
| Recommendation — Prefer phishing-resistant authenticators for high-risk sign-ins. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Covers identity federation and auth flows where token and login abuse can be relayed. |
| Recommendation — Verify federation flows resist replay, token theft, and approval abuse. | ||
| MITRE ATT&CK | T1110 — Brute Force | Covers credential and authentication abuse patterns that include phishing and session capture. |
| Recommendation — Map observed login abuse to credential-access techniques and alert on suspicious sign-in chains. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Applies where API-backed sign-in or token issuance can be abused through weak authentication. |
| Recommendation — Harden authentication endpoints so forwarded or replayed proofs are rejected. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Covers weak authentication paths and token handling that can enable relay or bypass. |
| Recommendation — Remove authentication paths that can be forwarded, replayed, or socially engineered. | ||
Practitioner Guidance
Why practitioners should care: The practical question is not whether MFA exists, but whether the chosen method is resistant to relay, phishing, and live approval abuse. A strong MFA program can still fail if the authentication flow can be forwarded by an attacker in the middle.
Common misunderstanding: Teams often treat any second factor as equivalent protection. In practice, approval-based and relayable flows deserve different scrutiny from phishing-resistant methods, especially for admin access, remote access, and high-impact applications.
Practitioner takeaway: Treat MFA as a control family, not a single guarantee, and verify whether the actual deployment resists real-time relay rather than assuming it does.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
