Mandatory FIDO2 hardware keys stopped Cloudflare’s July 2022 SMS adversary-in-the-middle Okta phishing after three employees already entered passwords on a lookalike page. Attackers texted at least 76 employees and some family members to newly registered cloudflare-okta.com for real-time credential and TOTP relay; according to Cloudflare’s 9 August 2022 post-mortem, no Cloudflare systems were compromised. For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA 2.0 have stopped Cloudflare’s SMS AiTM Okta path?
Yes. Phishing-proof MFA 2.0 would have stopped the Cloudflare July 2022 SMS AiTM path at the same place FIDO2 did: the fake Okta login never completes a usable workforce session. An adversary-in-the-middle attack is a reverse-proxy lure that captures passwords and transferable second factors live and tries to finish sign-in as the victim. Device-bound, origin-bound signatures never leave the enrolled hardware and never bind to the attacker’s domain, so harvested passwords (and any TOTP the kit was built to steal) do not become an Okta session. Closing that phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Why did FIDO2 hardware keys block login after passwords were already phished?
FIDO2 hardware keys blocked Cloudflare account takeover because authentication still required an origin-bound cryptographic ceremony the phishing page could not complete. Three employees entered passwords on cloudflare-okta.com, so the password step failed open for those users. Cloudflare required physical FIDO2 security keys for every employee on all applications. The kit was designed for real-time credential and TOTP relay, which works against phishable factors. It does not satisfy a hardware-bound signature tied to the real IdP origin. Cloudflare stated: “We have confirmed that no Cloudflare systems were compromised.”
Is FIDO2 “phishing-resistant” enough here, or do you need phishing-proof MFA 2.0?
For this Cloudflare incident, phishing-resistant FIDO2 at login was enough because enrollment and recovery were not the abuse path public reporting describes. Passkeys and FIDO2 harden the authentication act with origin-bound signatures. Phishing-proof MFA 2.0 goes further on the strength ladder by removing phishable factors across registration, device onboarding, authorisation, authentication, and decommissioning, not only the login click. When helpdesk re-enrollment or a phishable onboarding code is in scope, resistant login alone can still leave a gap. That gap was not the documented Cloudflare failure mode. The prevention-focused architecture is about eliminating transferable factors before the ceremony, not detecting a session after the fact.
What still needs controls after a blocked AiTM attempt like Cloudflare’s?
After a blocked AiTM attempt like Cloudflare’s July 2022 campaign, you still need ordinary hygiene for any other path that never touches the fake login. Public reporting does not establish that TOTP codes were captured from the three users who entered passwords, and it does not establish how employee and family phone numbers were assembled. Cookie or OAuth replay only matters if a real session already exists. Revoke, short-lived tokens, and endpoint controls remain hygiene when malware lands on a machine that already completed a legitimate sign-in. They are not a substitute for stopping the proxied Okta login. Cloudflare’s outcome shows the primary win is prevention at authentication, not cleanup after ATO.
How does Okta SSO blast radius change the prevention design?
Okta SSO multiplies the cost of a completed workforce login because one issued session can unlock many integrated apps without a fresh proof at each boundary. In the Cloudflare case the FIDO2 requirement denied that first session, so federation blast radius never opened. Architecturally, Secure Explicit Sign-On prefers the same one-tap UX while authenticating each app with its own fresh device-bound signature instead of one shared replayable SSO cookie. Pair that with device-bound enrollment that never hands IT a transferable secret and the industrial SMS-plus-fake-login class loses both the password leg and the soft-factor leg before any app token exists.
