How should security teams replace MFA flows that attackers can proxy in real time?

Why proxyable MFA fails as a control

When an attacker can relay the user’s interaction in real time, the problem is not just password strength or one-time code entropy. The weakness is that the authentication ceremony is still reusable by a live proxy. Security teams should treat that as a signal to move high-value access to phishing-resistant authenticators that bind the login to the device and the relying party.

A useful mental model is that the attack succeeds when the verifier accepts proof that was generated for a different context. Shared secrets, OTPs, SMS codes, and push approval flows can all be proxied if the attacker can sit in the middle of the session. NIST SP 800-63 Digital Identity Guidelines is the clearest external reference for why phishing-resistant authenticators materially change that trust boundary.

The practical replacement path is not “more MFA,” but stronger binding between the authenticator, the device, and the exact service being accessed. That is why passkeys, FIDO2 security keys, and equivalent phishing-resistant methods are preferred for accounts whose compromise would create broad downstream impact. Passwordless and Passkeys Guide and MFA Guide both map to that control shift, especially where relay attacks and token theft are the relevant failure modes.

Which flows deserve first priority

Not every account needs the same response on day one. Prioritise administrative access, remote access, help-desk reset paths, privileged vendor access, and any transaction flow where a relayed login could lead to payment, data export, key management, or policy change. Those are the places where “attacker can proxy it” becomes a material business and security issue.

Security teams should also include recovery and enrollment, not only interactive sign-in. If an attacker can defeat the primary login but then use self-service reset, SMS fallback, or a help-desk workflow to regain access, the new MFA factor is only partially effective. Workforce Identity Security Guide is useful here because it ties phishing-resistant MFA to lifecycle controls, recovery, and session theft rather than treating MFA as a standalone checkbox.

At the implementation level, the most important distinction is between a factor that proves possession and a factor that proves possession in the right context. If the relying party and authenticator do not cryptographically bind the ceremony, a live proxy can often preserve the user experience while breaking the security guarantee. That is why teams should be suspicious of any flow that can be completed entirely through codes, pushes, or browser-mediated relay.

How to migrate without leaving weak fallback paths

The migration path should replace the most proxyable flow first, then remove the fallback that silently reintroduces it. Start with a strict policy for high-risk groups, add phishing-resistant options in parallel, and then constrain or retire OTP, SMS, and push-only methods where the business case permits. IAM and Identity Provider Buyer's Guide is relevant because the identity platform choice determines how cleanly you can enforce method policy, recovery, and step-up controls.

In practice, the hardest part is usually not the primary login factor, but exception handling. Legacy apps, shared admin accounts, contractor access, and emergency recovery often keep weaker flows alive longer than intended. When that happens, the control objective should be to narrow the blast radius, increase step-up on sensitive actions, and make fallback use visible enough to trigger review.

Risk and Threat Considerations

Proxyable MFA creates a false sense of safety because it still looks like successful authentication in logs and user journeys. The attacker does not need to break the factor if they can relay it fast enough, and that means the real exposure is session establishment, not just credential theft.

Failure mechanism: A live proxy, adversary-in-the-middle kit, or token relay preserves the user interaction while forwarding the result to the attacker, so the relying party accepts an authentication ceremony that was completed in the wrong context.

Impact: The attacker can turn a stolen login into account takeover, session hijacking, privileged action, or lateral movement, especially when the same flow can be reused for recovery, admin elevation, or high-value transactions.

Practitioner Guidance

What to prioritise: Replace proxyable factors first on privileged, remote-access, and high-impact transaction paths. Those are the flows where one relayed session can do the most damage, so they should move ahead of low-risk workforce conveniences.

What to verify: Confirm that the chosen method is phishing-resistant in the real deployment, not just in theory. Check whether the authenticator is device-bound, whether the relying party is bound into the ceremony, and whether any fallback route still accepts OTP, push, or help-desk override.

Common mistake: Keeping SMS, TOTP, or push as “backup MFA” for the very users and systems that were meant to be protected. In practice, the fallback often becomes the path attackers target first.

Practitioner takeaway: The goal is to make authentication non-relayable for the accounts that matter most, then remove the weaker recovery and exception paths that would otherwise reintroduce the same attack surface.

Related resources from NHI Mgmt Group

• How should security teams protect executive accounts from real-time MFA interception?
• How should ecommerce security teams stop checkout abuse when attackers use malicious WordPress plugins to capture payment data in real time?
• How should security teams reduce the risk of AI-assisted social engineering when attackers use stolen accounts and real-time text generation?
• How should security teams detect email attacks when attackers use AI to adapt in real time?