There is a sentence that appears in security awareness training, vendor documentation, compliance guidance, and board presentations with remarkable consistency: “Enable multi-factor authentication to protect against phishing.” It is not false, exactly. It is a statement that was accurate for a specific threat model in 2018 and has not been updated to reflect what attackers have been doing since approximately 2020.
Adversary-in-the-Middle (AiTM) phishing defeats time-based one-time password (TOTP) authentication in real time. The toolkits to do this are not research prototypes. They are commercial products, available for several hundred pounds, used by criminal phishing-as-a-service operations, and documented extensively in threat intelligence reporting from Microsoft, Mandiant, and others. Evilginx, Modlishka, and their commercial derivatives operate as transparent proxies: the victim authenticates to the real service through the attacker’s infrastructure, the session token is captured, and the attacker has authenticated access that persists beyond the MFA challenge.
The TOTP code was entered correctly. The MFA event was recorded. The session was compromised.
Why This Matters Now
The acceleration of AiTM capability is the story that the MFA conversation has not caught up with. The toolkits have moved from researcher proof-of-concept to criminal-commodity infrastructure. Large-scale phishing campaigns tracked in early 2026 have used commercial AiTM kits against Microsoft 365 and Google Workspace environments with high success rates against organisations that believed their TOTP MFA deployment constituted phishing protection.
What TOTP protects against is password reuse attacks — credential stuffing, password spraying, database dumps from unrelated breaches. These are real threats and TOTP does meaningfully reduce exposure to them. For organisations that have not implemented any second factor, deploying TOTP is still a genuine uplift.
The problem is not TOTP’s existence. The problem is the security community’s continued framing of TOTP as phishing protection when the dominant phishing methodology in use by organised criminal groups and several nation-state actors explicitly bypasses it. Telling users that MFA will protect them from phishing emails when the phishing emails being sent against enterprise targets are designed specifically to defeat TOTP is inaccurate in a way that matters.
The Only Phishing-Resistant Factor
The specification for phishing-resistant authentication exists: FIDO2, implemented via hardware security keys (YubiKey, Titan Key) or platform authenticators (Windows Hello, Face ID, passkeys synced via cloud keychain). The technical reason for its resistance is straightforward — the cryptographic challenge is domain-scoped, meaning the authenticator will not respond to a challenge from a proxy that is not the legitimate origin. An AiTM proxy cannot replay a FIDO2 assertion. The credential cannot be phished because it cannot be presented to the wrong site.
This has been understood for several years. Google’s 2018 analysis of their own MFA deployment found that hardware security keys prevented all phishing attempts against their employee population. The FIDO2 standard is supported by every major operating system and browser. This is not an obscure or emerging technology.
The Enterprise Migration Problem
The reason TOTP remains the recommendation in most security frameworks, compliance documents, and enterprise security programmes is not technical ignorance. It is migration inertia, and the barriers are real.
Deploying FIDO2 at scale requires hardware procurement for users who cannot use platform authenticators. It requires changes to exception management: what happens when a user loses their key, travels with an incompatible device, or needs to authenticate from a shared system? These questions have answers, but they require helpdesk investment, user training, and leadership decisions about acceptable friction in the authentication experience.
More significantly, TOTP is what the compliance frameworks require. PCI DSS 4.0 mandates MFA for administrative access to the cardholder data environment and allows TOTP. NIST SP 800-63B guidance specifies assurance levels but does not prohibit TOTP for general enterprise authentication. ISO 27001 requires MFA without specifying the type. None of the major frameworks explicitly require phishing-resistant authentication for general user access. Organisations are deploying what compliance requires, not what the threat demands.
What to Actually Do
The framing of “TOTP vs FIDO2” as a binary choice is not how enterprise migration works in practice. A realistic roadmap looks like this: identify your highest-risk users first — privileged accounts, executives, finance and HR access, anyone with admin rights to cloud infrastructure — and deploy hardware security keys or enforce FIDO2 platform authenticators for those populations now. The key management and exception handling overhead is manageable at this tier, and the risk reduction is substantial.
For the broader user population, set a realistic migration timeline — 18 to 24 months is achievable for most enterprises — and start deploying platform passkeys as part of device refresh cycles. Communicate to the board that the current TOTP deployment is useful, but that phishing-resistant authentication is the target state and the reason to invest in the migration.
What is not acceptable is presenting TOTP deployment as phishing protection in 2026 without the caveat that it does not protect against the phishing methodology currently in widest criminal use. The security industry has a responsibility to update its recommendations as the threat evolves. On this one, we are behind.