Not All MFA Is Equal: A Decision-Maker's Guide to TOTP, Passkeys, and Everything Between

You rolled out MFA across your company's accounts. The dashboard shows a satisfying row of green checkmarks. Then an employee gets phished anyway — and the attacker walks right past the second factor like it isn't even there.

I've spent enough time in identity and access management to know why this keeps happening: not all multi-factor authentication is equal. Some MFA methods stop attackers cold. Others just add a 30-second speed bump before the inevitable. The specific method you deploy matters far more than the fact that you technically "have MFA enabled."

This post breaks down every major MFA method, explains what actually defeats each one, and gives you a practical decision framework for what to deploy — based on your actual risk profile, not a vendor's slide deck.

What MFA Actually Means

Multi-factor authentication requires proof from at least two independent categories:

Two passwords stacked together is not MFA. A password plus a fingerprint is. The categories have to be genuinely independent — that's the whole point. An attacker who steals your password still can't fake your thumbprint.

Here's what most people miss, though: even within the "something you have" category, the specific method creates wildly different security outcomes. A TOTP code from an authenticator app and a FIDO2 hardware key are both technically "possession factors" — but they defend against completely different attacks.

TOTP: The Workhorse of Modern MFA

Time-based One-Time Passwords (TOTP) are the six-digit codes you see in Google Authenticator, Authy, or 1Password. They refresh every 30 seconds, work fully offline, and need no phone number or network call to function.

The algorithm itself is refreshingly simple. Both your phone and the server independently compute the same number from two shared inputs: a secret established once at setup, and the current time.

Here's the core logic in pseudocode:

T = floor(current_unix_time / 30)
hmac = HMAC-SHA1(shared_secret, T)
offset = last_nibble(hmac)           // 0-15
code = extract_4_bytes(hmac, offset) // dynamic truncation
otp = code % 10^6                    // 6-digit output

That's it. Both sides divide time into 30-second buckets, hash the bucket number against the shared secret, and extract six digits. No network call, no server round-trip — your phone can sit in airplane mode and TOTP still works.

The security model holds up well for what it is: the shared secret never crosses the wire again after initial setup, each code is valid for roughly 30 seconds, and a properly implemented server rejects reused codes. An attacker guessing blind has a 1-in-1,000,000 shot, and rate limiting makes brute force impractical.

But TOTP has one critical weakness: it's phishable.

A six-digit code has no concept of where it's being entered. If an attacker stands up a convincing fake login page using a tool like Evilginx, the victim types their password and TOTP code into that fake page. The attacker relays both to the real site in real time, captures a valid session, and the victim never notices anything wrong. The second factor worked exactly as designed — and protected nothing.

This is the fundamental fault line running through all of MFA: methods that can be relayed by a middleman, and methods that can't.

The MFA Spectrum: Weakest to Strongest

Here's every major method, ranked by real-world security posture:

The dividing line is phishing resistance — whether the method cryptographically binds the authentication attempt to a specific website origin. FIDO2 and passkeys do this by design: the signed challenge is tied to the legitimate domain, so a phishing site on a different domain gets a signature it can't use. Everything below that line produces a portable token — a code, an approval tap — that an attacker sitting in the middle can simply relay onward.

What Actually Breaks Each Method

Understanding the attack helps you pick the right defense.

Adversary-in-the-Middle (AitM) Proxy Attacks

Tools like Evilginx, Modlishka, and EvilProxy sit between the victim and the real login page, proxying everything in real time. The victim sees what looks like the legitimate site, enters their password, enters their TOTP code — and the proxy captures both and forwards them to the real site as they're typed. The real site issues a valid session cookie. The attacker now owns that session.

This defeats SMS codes, TOTP codes, email OTP, push approvals, and even number matching. The user did nothing wrong. The MFA worked exactly as designed. The account is compromised anyway.

Only FIDO2/WebAuthn stops this cold, because the cryptographic signature is bound to the origin domain at the protocol level. A proxy sitting on a fake domain gets back an assertion for the wrong origin — and the real server rejects it outright.

SIM Swapping

An attacker calls your mobile carrier, impersonates you using data pulled from breaches or social media, and convinces support to port your number to a new SIM. Every SMS code from that point on goes straight to the attacker.

This isn't a theoretical edge case. In the UK, Cifas's 2024 Fraudscape report recorded unauthorized SIM swap cases jumping from 289 in 2023 to nearly 3,000 in 2024 — a 1,055% surge in a single year. It's a daily attack pattern against financial accounts, crypto wallets, and corporate VPNs, and SMS-based MFA offers zero defense against it.

MFA Fatigue (Push Bombing)

In 2022, an attacker compromised Uber's internal systems by spamming an employee with push-approval requests for roughly an hour, until the employee tapped "Accept" just to make the notifications stop. No sophisticated exploit — just persistence and annoyance.

Number matching (where the app shows a two-digit code the user must type back) mitigates the blind-approval version of this attack, but it doesn't stop an AitM proxy — the attacker just relays the same number to the victim.

Recovery Flow Bypass

The most common real-world MFA bypass doesn't attack the second factor at all — it goes around it entirely. A password reset or account recovery flow that skips the second factor effectively reduces your account's real-world security to whatever that recovery flow demands. If recovery only needs an email link, and that inbox is protected by a weaker MFA method (or none), your "MFA-protected" account is only as strong as its weakest recovery path.

The Regulatory Landscape

If you're in a regulated industry, the compliance picture has converged hard on phishing-resistant MFA:

NIST SP 800-63B-4 (finalized July 2025) — SMS/PSTN is now formally classified as a "restricted authenticator," the first time NIST has created this explicit category. It isn't banned outright, but using it now requires a documented risk assessment, a migration plan, and user notification. Synced passkeys are explicitly recognized at AAL2, and email-based OTP delivery is prohibited under the updated verifier requirements.

PCI-DSS 4.0.1 — MFA is now required for all access into the cardholder data environment, not just administrative access. Phishing-resistant methods are recommended, and the standard references NIST and the FIDO Alliance directly.

Essential Eight (Australia) — At Maturity Level 2 and above, only "multi-factor cryptographic hardware" (FIDO2 keys, hardware-backed passkeys, smart cards) qualifies. TOTP and app-based push are excluded at ML2+.

FTC enforcement — Recent consent decrees against breached retailers have required authentication resistant to phishing and have explicitly excluded telephone- or SMS-based methods as acceptable compliance controls.

The direction of travel is unmistakable: regulators have moved from "do you have MFA?" to "what kind of MFA do you have?"

Decision Framework: What to Deploy

Match the MFA method to the risk tier of the account, not a one-size-fits-all policy:

Tier 1: Privileged Accounts (IT admins, finance, executives, DevOps)

Deploy now: FIDO2 hardware security keys (YubiKey, Feitian, Titan)

These accounts are the highest-value targets in your org — a single compromised admin account can expose your entire infrastructure. Hardware keys provide AAL3 assurance with full phishing resistance. Cost runs $25–60 per key, typically issued in pairs (one as backup). For accounts facing the most sophisticated attacks, the ROI here is immediate.

Tier 2: General Workforce

Deploy now: TOTP via authenticator apps (Google Authenticator, Microsoft Authenticator, Duo) Migration path: Enable optional passkey enrollment now; plan a mandatory passkey rollout within 12 months

TOTP remains the practical enterprise baseline. It's free, works everywhere, needs no phone number, and is a massive step up from passwords alone — Microsoft's own research found that over 99.99% of MFA-enabled accounts in their dataset stayed secure through the investigation period. But TOTP is still not phishing-resistant, so treat it as a stepping stone rather than a destination.

Tier 3: Consumer / Customer Accounts

Deploy now: TOTP as the baseline, with passkey support offered as an option Incentive: Offer something for enabling it — extended trial, a badge, bonus storage

For consumer-facing apps, adoption matters as much as raw strength. TOTP has low setup friction and no hardware requirement. Passkeys should be the premium, security-conscious option sitting alongside it — and the option is getting more attractive fast: the FIDO Alliance's May 2026 State of Passkeys report puts global passkey usage at roughly 5 billion, with 68% of surveyed organizations already deploying or actively piloting them for employee sign-in.

Tier 4: Legacy Systems / Low-Risk Apps

Acceptable as a documented exception: SMS OTP, with a defined migration timeline

If a legacy system only supports SMS and an upgrade isn't immediately feasible, document it explicitly as a known gap, set a remediation deadline, and don't let it quietly become the steady state.

Recovery Flows

Whatever assurance level you enforce at login, enforce the same at recovery. A recovery path that's weaker than the login path sets your account's true security to whichever one is weaker. Enroll at least two recovery factors at setup, require both during actual recovery, and treat single-use backup codes as an acceptable last resort — not a primary recovery method.

The Passkey Future

Passkeys are where authentication is heading, and the numbers back that up. The FIDO Alliance's State of Passkeys 2026 report — released for World Passkey Day, May 2026 — puts global passkey usage at an estimated 5 billion, with 68% of surveyed organizations already deployed or actively piloting passkeys for employee sign-in.

A passkey is a cryptographic key pair stored on the user's device, unlocked by biometrics or a PIN. The user authenticates with a fingerprint or face scan — no password, no separate code to type. One gesture replaces the entire password-plus-second-factor flow.

Passkeys are simultaneously:

• Phishing-proof — cryptographically bound to the origin domain
• Password-free — nothing to steal or brute-force in the first place
• Convenient — one gesture instead of two separate steps
• Synced across devices via iCloud Keychain, Google Password Manager, or 1Password

NIST and the FIDO Alliance increasingly treat a well-implemented passkey as a complete authentication solution on its own, not just one factor in a stack.

Where to start: enable optional passkey enrollment at your identity provider today, let early adopters use it, and work out the infrastructure kinks before they become user-facing problems. From there, expand to mandatory enrollment for new users, then run a migration campaign for everyone else. If you want to see the mechanics of a passkey flow end-to-end before rolling it out internally, I've got a working demo running at passkey-demo.sandbox99.cc — worth poking at before you commit to an identity provider's implementation.

The Bottom Line

MFA isn't a checkbox — it's a spectrum. The method you choose determines whether you're building a speed bump or a wall.

• TOTP is the minimum viable MFA. If you're running zero second factor today, start here. It's free, universal, and stops the vast majority of automated attacks.
• FIDO2/passkeys are the current standard. For anything privileged, regulated, or high-value, this is the only acceptable answer in 2026.
• SMS is a documented exception, not a strategy. If you're still leaning on SMS OTP, you're sitting at the weakest end of what both regulators and attackers consider acceptable.

Audit your current MFA deployment. Identify which risk tier each user population actually falls into. Start migrating toward phishing-resistant methods — beginning with your highest-risk accounts today, and the rest of the workforce within the year.

The attackers aren't waiting. Neither should you.