Blind one-tap push approve still finishes a workforce login after a stolen password. According to CISA on 31 October 2022, organizations should implement phishing-resistant MFA against phishing and other known cyber threats, and shops still on mobile push should enable number matching to blunt MFA fatigue. Phishing-proof device-bound MFA closes those credential-phase paths outright: there is no blind push left to spam, and no transferable OTP to relay on a fake or proxied login. Number matching only stops one-tap accept on push; it is not origin-bound cryptography. For the guidance-month attack-chain framing, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA stop the push-fatigue path CISA described?
Yes. Phishing-proof MFA would stop the push-fatigue path in CISA’s October 2022 guidance because there is no mobile approve prompt left to spam. MFA fatigue works when an attacker already holds the password and keeps sending push notifications until one accidental tap finishes workforce login. Device-bound, origin-bound signatures replace that transferable approval. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Is CISA number matching enough for workforce MFA?
No. CISA number matching is not enough as a permanent workforce MFA end state. The CISA alert states that number matching is not as strong as phishing-resistant MFA, though it is one of the best interim mitigations when push cannot be retired immediately. Number matching only forces the user to enter a challenge digit so blind one-tap accept fails. It does not bind the ceremony to the real origin, and it does nothing for SMS or app OTP a user can still type into the wrong page. Treat it as a bridge control, then move up the ladder: password, OTP/SMS, push, phishing-resistant login (FIDO2/passkeys/WebAuthn), then phishing-proof MFA 2.0 across the full identity lifecycle.
How does phishing-proof MFA 2.0 differ from the phishing-resistant MFA CISA urges?
Phishing-resistant MFA (FIDO2, passkeys, WebAuthn-class) hardens the login act with origin-bound signatures so relayed OTP-style secrets fail. Phishing-proof MFA 2.0 keeps that login strength and removes phishable factors at every lifecycle stage, not authentication alone. CISA’s hierarchy correctly ranks phishing-resistant factors above push and OTP. The next rung is prevention, not detection: no prompt to fatigue and no code to type. Public reporting on the alert does not name a specific AiTM kit or TAP path; the prevention claim still holds for the credential-phase classes CISA called out.
Does device-bound phishing-proof MFA also close phishable OTP and proxied-login abuse?
Yes. Device-bound phishing-proof MFA closes phishable OTP and proxied-login abuse of the kind CISA’s phishing-resistant push targets. SMS codes, app OTP, and similar transferable second factors can be entered on a fake page and completed in real time while the real IdP issues a session. Origin-bound device keys never leave the enrolled hardware as a reusable secret, so the kit cannot finish that ceremony remotely. Why legacy MFA was dropped starts with exactly those transferable factors. Number matching does not solve OTP relay.
What does phishing-proof MFA not undo after a good login already exists?
Phishing-proof MFA does not undo post-authentication token theft from malware on a machine that already holds a legitimate session. CISA’s October 2022 package is about stopping weak MFA at sign-in (push fatigue and phishable second factors), not about cleaning cookies after endpoint compromise. Fooling a user into a fatigue approve or a typed OTP is easy. Planting malware is not. Revoke, short lifetimes, and endpoint controls remain hygiene for that residual path; they are not a substitute for closing the phishable login first.
