How can teams tell whether their MFA is still too easy to relay?

What “too easy to relay” means in practice

MFA is still too easy to relay when it proves only that someone saw a code or approved a prompt, not that the authenticating party is the real user on the real device, from the real origin. That gap matters because attackers do not need to break the second factor if they can forward it, replay it, or borrow the session it creates.

Teams should treat relay resistance as a property of the whole sign-in flow, not a single checkbox. A control that depends on one-time codes, push approval, or a browser session that can be replayed from elsewhere is still exposed if it lacks phishing-resistant binding to device, certificate, origin, or token recipient context.

How to test whether your MFA is relay-resistant

The most direct test is to walk the login flow through a realistic attacker path and ask whether a code, prompt, or assertion can be captured and reused by a separate party. If a fake site can collect the factor and the target service accepts it, the control is not stopping relay. That is the difference between MFA and phishing-resistant MFA.

It also helps to inspect what the service actually validates at authentication time. Stronger designs bind the factor to a device or key pair, verify the browser or origin, or require an authenticator that cannot be replayed elsewhere. We recommend comparing current behaviour with a baseline like NIST SP 800-63 Digital Identity Guidelines, which distinguishes phishing-resistant authenticators from weaker second factors.

A practical way to evaluate the flow is to check whether the same sign-in would still succeed if the attacker controlled the webpage, network path, or relay endpoint but did not control the user device. If the answer is yes, you are likely depending on a factor that authenticates the user to the site, but not the site to the user.

Signals that the control is still too weak

Weak relay resistance usually shows up as visible operational shortcuts: SMS or OTP prompts that can be entered on any site, push approvals that can be social-engineered, legacy protocols that ignore modern authentication checks, or sessions that remain valid after the factor was relayed once. Those patterns show that the authentication step is still separable from the trust decision.

Good evidence of a stronger posture is harder to fake: device-bound credentials, passkeys or security keys, origin-aware assertions, and authentication methods that fail when moved to a different browser context. An implementation that resists relay should make it materially harder for an attacker to turn user participation into reusable authentication material. A useful reference point is MFA Guide, which compares the bypass patterns teams should expect across common factors.

Relay weakness is often easiest to spot when the control still works after the attacker has inserted a man-in-the-middle step. If the user can be convinced to complete the flow and the service still issues a usable session, the design is relying on secrecy of the prompt rather than proof of possession or origin.

Risk and Threat Considerations

Relay-friendly MFA creates a deceptive sense of protection because the login appears to succeed for the legitimate user while the attacker receives an authenticated session at the same time. That makes the control especially attractive to adversaries who use phishing kits, reverse proxies, or social engineering to harvest live authentication events.

Failure mechanism: The factor or session artifact is accepted without strong binding to the authentic device, browser origin, or cryptographic key, so the attacker can proxy the exchange and reuse the result elsewhere.

Impact: Attackers can bypass MFA without stealing the user’s device, then move into email, VPN, SaaS, or admin portals and escalate from initial access to broader account compromise.

Practitioner Guidance

What to verify: Test whether your highest-risk sign-ins use phishing-resistant authenticators, and confirm that the service rejects relayed codes or assertions that arrive from a different origin or device context. If your environment still allows OTP relay, treat that as a design gap, not a tuning issue.

What good looks like: The strongest sign is that a user interaction on a fake page fails to produce a usable session, even when the attacker perfectly forwards prompts or codes. In practice, that usually means moving critical access paths toward passkeys, FIDO2 security keys, or other bound authenticators.

Practitioner takeaway: If the attacker can complete the login by relaying the factor, your MFA is proving participation, not possession of the real sign-in context, and that is not enough for phishing resistance.

Related resources from NHI Mgmt Group

• How can teams tell whether workload access is still too secret-driven?
• How can security teams tell whether their remote access model is still too dependent on perimeter trust?
• How can teams tell whether identity processes are too easy to manipulate?
• How can security teams tell whether a legacy application is still too trusted?