A real-time relay attack breaks the assumption that a successful MFA challenge proves the legitimate user is present. The login can be genuine at the protocol level and still be attacker-controlled, because the adversary replays the password and live code in the moment they are entered. That makes the session trustworthy only in appearance, not in origin.
What a Real-Time Relay Attack Actually Breaks
A real-time relay attack does not usually break the MFA protocol itself. It breaks the assurance model behind it: the system accepts that a valid second factor means the right person is present, when in fact the attacker is simply passing the challenge through in real time.
That distinction matters because the authentication event can be technically successful while the session is still attacker-owned. The control answered the question “can someone complete MFA?” but not the more important question “is the authenticating party the legitimate user, at the legitimate endpoint, in the legitimate moment?”
In practice, the attack works by preserving timing and interaction. The victim types the password or approves the challenge, the adversary relays it immediately, and the relying party sees a normal login flow. Nothing in the protocol necessarily signals that the person and the browser, phone, or device in the middle are not the same trusted context.
Why the Session Still Looks Legitimate
Real-time relay attacks exploit a gap between authentication and trust in the current session. The system may have strong MFA, but it may still lack phishing-resistant binding to the origin, device, or transaction that initiated the login. That is why relay attacks are often described as a form of adversary-in-the-middle abuse, not simple password theft.
The practical failure is not just that the attacker sees credentials. It is that the attacker can complete the entire exchange before the MFA factor expires or loses relevance. The result is a live authenticated session, often with the same privileges the user would have had, but established from an attacker-controlled channel.
This is why methods that resist relaying, such as passkeys or other phishing-resistant authenticators, are materially stronger than one-time codes delivered through channels that can be forwarded in the moment. NIST SP 800-63 Digital Identity Guidelines is useful here because it distinguishes authenticator strength and phishing resistance from mere second-factor presence.
What It Means for Defenders and Identity Controls
The defender’s job is to reduce the value of a successful relay, not just to increase the number of factors. If the authenticator can be relayed in real time, then MFA may still stop opportunistic password spraying, but it will not reliably stop a determined interactive attacker who can proxy the user’s own login.
That is why phishing-resistant MFA, session binding, and tighter conditional access matter together. A real-time relay attack shows that a login control can be both “working” and still insufficient if it does not verify the channel, device, or transaction context strongly enough.
For practitioners, the most useful response is to treat relayed MFA as a trust failure with downstream identity impact, not as a narrow authentication glitch. NHIMG’s MFA Guide and Passwordless and Passkeys Guide are directly relevant because they connect bypass patterns to the controls that actually reduce relay success.
Risk and Threat Considerations
A successful relay attack can give an attacker a clean initial foothold that looks indistinguishable from a normal sign-in in logs. The main risk is not only account takeover, but also silent downstream use of that authenticated session for data access, privilege escalation, or lateral movement before the compromise is noticed.
Failure mechanism: The attacker proxies the login in real time, so the verifier sees a valid MFA event even though the factor was satisfied through an intermediary rather than directly by the legitimate user and device.
Impact: Security teams may trust an authentication success that does not actually prove user presence, which can delay detection, weaken incident triage, and allow attacker-controlled sessions to access resources with legitimate privileges.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) 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 and assurance concepts central to relay resistance. |
| Recommendation — Prefer phishing-resistant authenticators that bind the sign-in to the user and device. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Organizational sign-ins depend on authenticating the right user, not just completing a factor. |
| IA-5 — Authenticator Management | Relay attacks exploit authenticators whose value can be forwarded in real time. | |
| Recommendation — Require stronger user authentication for workforce access paths. Manage authenticators to reduce replayable or relayable sign-in methods. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account access must be governed so a relayed sign-in does not create broad exposure. |
| Recommendation — Restrict and review account access to limit the impact of compromised sign-ins. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Relay attacks undermine implicit trust in the sign-in event and session context. |
| Recommendation — Validate each access request instead of trusting the initial login alone. | ||
Practitioner Guidance
What to verify: Verify whether the authentication method is phishing-resistant and bound to the origin or device, not just whether MFA is enabled. If a method can be forwarded live, treat it as vulnerable to relay in adversary-in-the-middle scenarios.
What to prioritise: Prioritise the sign-in paths that protect high-value accounts, remote access, and session issuance, because those are the places where a successful relay has the highest blast radius. A control gap here is more serious than the same gap on a low-impact application.
Practitioner takeaway: The key lesson is that MFA success is not the same as trustworthy user presence; if the factor can be relayed, the login may be valid in protocol terms and still be unsafe in security terms.
Related resources from NHI Mgmt Group
- What breaks when phishing panels can relay MFA codes in real time?
- What breaks when MFA does not evaluate user risk in real time?
- What breaks when MFA is present but the login can still be relayed in real time?
- What breaks when telemetry is forced through brittle collection methods instead of real-time sources?