Why do TOTP codes and push MFA create more account takeover risk than WebAuthn security keys?

Why TOTP and Push MFA Are Easier to Defeat

TOTP and push MFA improve on passwords, but they still depend on a shared secret or a user decision that can be stolen, relayed, or pressured into approval. That makes them vulnerable to phishing kits, adversary-in-the-middle setups, MFA fatigue, and prompt abuse. WebAuthn security keys change the trust model by binding the response to the real origin, so the authenticator will not sign a challenge for a spoofed site.

That origin binding is the critical difference: the attacker can trick a user into reading or approving a code, but cannot easily reuse a WebAuthn assertion against a different site. TOTP and push are therefore stronger than passwords, yet they still leave room for interception and social engineering that phishing-resistant authenticators close off.

How the Attack Path Works

TOTP is a time-based one-time password. It reduces password reuse risk, but it is still a bearer factor: whoever sees the code first can usually use it within the valid time window. Push MFA is even more exposed to human pressure, because the user is being asked to approve a login rather than independently verify a cryptographic challenge.

In practice, attackers exploit that gap by placing a fake sign-in page between the victim and the real service, or by overwhelming the user with repeated push requests until one is accepted. Once the attacker captures a valid TOTP code or gets a push approved, they can complete the session establishment step and move into the account as if they were the legitimate user.

• TOTP weakness: codes can be relayed in real time during a phishing session.

• Push weakness: approval fatigue, social pressure, and unclear prompts can override careful judgment.

• WebAuthn advantage: the authenticator verifies the site origin and signs only for the intended relying party.

For that reason, WebAuthn security keys materially reduce adversary-in-the-middle success, because the attacker cannot simply transplant the authentication ceremony to another domain. The model breaks down in environments where users are conditioned to approve prompts without verification or where teams treat push approval as equivalent to strong possession-based proof.

Common Variations and Edge Cases

Tighter authentication often increases friction, so organisations have to balance convenience against resistance to phishing and session theft. That tradeoff becomes sharper when users are mobile, when helpdesk recovery is weak, or when legacy applications still expect OTP-style workflows.

There are also important edge cases. TOTP can still be useful as a fallback or step-up factor, but it should not be the preferred control for high-value accounts when phishing resistance is the goal. Push MFA is better than password-only access, yet it remains sensitive to fatigue attacks unless number matching, device binding, and contextual challenge data are enforced.

Current guidance from NIST SP 800-63 Digital Identity Guidelines aligns with that distinction by treating phishing-resistant authenticators as the stronger option for high-assurance use cases. For implementation teams, the practical question is not whether MFA exists, but whether the factor can be replayed, relayed, or socially engineered under realistic attack pressure.

In mixed environments, the hard part is often migration: the weakest method allowed for recovery or legacy access usually becomes the method attackers target first.

Risk and Threat Considerations

These factors create account takeover risk because they can be abused without breaking the underlying password at all. The attacker only needs to intercept a code, induce an approval, or relay the authentication flow fast enough to win the race.

Failure mechanism: TOTP and push MFA are not origin bound, so a phishing proxy or adversary-in-the-middle kit can capture a valid response and reuse it during the live session. Push approvals also create a human factor failure mode, where repeated prompts, urgency, or ambiguity lead to accidental approval.

Impact: Once the attacker completes sign-in, they can establish a trusted session, reset recovery settings, access sensitive data, and pivot to adjacent systems that trust the compromised account.

Practitioner Guidance

What to prioritise: Treat WebAuthn or another phishing-resistant method as the default for privileged users, administrators, and any account that can approve financial, identity, or security changes. Keep TOTP only where you need compatibility or as a controlled fallback.

What to verify: Review whether your push flow still allows silent fatigue attacks, whether recovery paths downgrade users back to weaker factors, and whether helpdesk processes can be abused to re-enrol a compromised device. If a factor can be relayed or approved under pressure, it should not be your highest-assurance option.

Practitioner takeaway: The real decision is not “MFA or not”, it is whether the factor binds the user to the genuine service strongly enough that a phishing kit cannot reuse the authentication event elsewhere.

Related resources from NHI Mgmt Group

• Why does push bombing create account takeover risk even when MFA is enabled?
• Why does SMS-based MFA still create account takeover risk?
• Why do security questions create account takeover risk?
• Why do repeated MFA prompts create account takeover risk?