MFA and Passkey Fallback Risks

Back to learning

MFA and passkeys raise the cost of account takeover. They are still not the end of the account-protection problem.

The strongest authentication method can be weakened by the flows around it: lost-device recovery, support override, fallback codes, remembered devices, session tokens, phishing pressure, and device migration. Attackers do not need to defeat the best path if a softer path reaches the same account.

MFA does not remove account risk

MFA helps when an attacker only has a password. A reused or breached password is less useful if the attacker also needs an authenticator app, hardware key, passkey device, or other factor.

The gaps are usually around the control:

• Users can be tricked into sharing one-time codes.
• Push prompts can be abused through fatigue or social engineering.
• SMS can be exposed to SIM swap and phone-number lifecycle issues.
• Recovery flows can reset the factor.
• Stolen sessions can bypass a fresh MFA prompt.
• Help desk overrides can remove the factor under pressure.

That does not make MFA weak. It means MFA should be treated as one decision point inside a wider account-control surface.

Passkeys shift the problem

Passkeys can reduce phishing and credential stuffing because they are bound to the right service and do not rely on a reusable password. That is a real improvement. It also shifts attention to enrolment, device trust, recovery, sync, revocation, and fallback.

Teams should ask:

• Who can add a new passkey?
• What happens when a device is lost?
• Can a support process remove or replace passkeys?
• Are old sessions reviewed after passkey or MFA changes?
• Are high-risk actions protected after fallback recovery?
• Can the customer see recently added authenticators?

If the fallback path is weaker than the main path, attackers will aim for the fallback.

Where step-up belongs

Authentication should be tied to action sensitivity. A low-risk account view may not need the same treatment as changing a payout method, exporting data, disabling MFA, or creating an API key.

Step-up checks are useful when the session context changes or the action has higher consequence. The trigger might be a new device, unusual network, residential proxy context, first-seen browser, breached credential signal, recent recovery event, or a sensitive route.

None of these signals is proof by itself. They help decide whether the current request has enough confidence for the action being requested.

What to measure

Track both abuse and friction:

• Accounts protected by MFA or passkeys
• Recovery events after failed login pressure
• MFA resets and support overrides
• Sensitive actions after fallback recovery
• Failed step-up attempts
• False-positive challenges and abandonment
• Confirmed account takeover after successful authentication

MFA and passkeys work best when they reduce reusable credential risk without hiding the rest of the account lifecycle. Protect the strong path, then make sure the fallback path does not quietly become the real login.