Phishing-proof MFA stops Cisco push fatigue

According to Cisco Talos on 10 August 2022, Cisco became aware on 24 May 2022 of a compromise that reached corporate VPN after browser-synced credentials, MFA push fatigue, and multi-day vishing produced a push acceptance, then attacker MFA enrollment. Phishing-proof MFA 2.0 would have blocked the push-acceptance and silent factor-enrollment stages. It would not undo personal Google password sync theft or post-VPN directory lateral movement. For the full attack chain, read the companion on legacymfa.sucks.

FAQ

Would phishing-proof MFA 2.0 have stopped the Cisco 2022 VPN path?

Phishing-proof MFA 2.0 would have stopped the Cisco 2022 VPN path at push acceptance and at attacker MFA enrollment, not at every stage of the incident. According to Cisco Talos, the attacker already held a browser-synced Cisco password from a compromised personal Google account, then flooded MFA push requests and coached acceptance over multi-day vishing until VPN opened in that user's context. Device-bound MFA 2.0 has no approve/deny prompt to spam or coach, and proof is a user-initiated, origin-bound signature. Closing that phishable login stops this path. In-network abuse after a session already exists is a harder, separate problem.

Why does approve/deny push fail against fatigue and vishing?

Approve/deny push failed in the Cisco 2022 breach because the second factor is a transferable decision an attacker can initiate and pressure by voice. Cisco Talos reported sophisticated voice phishing under the guise of trusted support organizations, with callers speaking English in various international accents over multiple days, until the employee accepted an attacker-initiated push. Legacy push MFA treats "Accept" as enough. A prevention-focused design removes standing prompts, so fatigue and coached acceptance have nothing useful to harvest on the phone.

How does hardened enrollment stop attacker MFA registration after VPN access?

Hardened enrollment would have stopped the Cisco 2022 attacker from quietly registering a series of new MFA devices after the first VPN login. Talos described post-access enrollment of attacker-controlled factors so later VPN authentications no longer needed fatigue or vishing. Phishing-proof MFA 2.0 treats adding a device as a high-assurance event that requires an already-enrolled device, not a session cookie or a phishable code alone. The enrolment model closes the lifecycle gap that login-only controls leave open when recovery and device onboarding stay phishable.

Would passkeys alone have been enough for a Cisco-style fatigue attack?

Passkeys alone would harden a Cisco-style login ceremony if approve/deny push were fully replaced, but they are phishing-resistant at authentication only unless enrollment and recovery are locked down too. In the Cisco 2022 case the attacker enrolled new MFA devices after holding a VPN session, and later re-entry attempts also abused weak post-reset password hygiene such as single-character changes. If a deployment still allows phishable recovery or session-driven factor add, brief access can plant an attacker authenticator that later looks legitimate. MFA 2.0 is phishing-proof across registration, device onboarding, authentication, and decommissioning, the step above login-only resistance on the control ladder.

What would MFA 2.0 still not stop in the Cisco attack?

MFA 2.0 would still not stop stages of the Cisco 2022 attack that never presented a workforce login challenge or that ran after authentication already succeeded. Theft of a corporate password already saved in a personal Google Chrome sync is outside that boundary. After VPN access, privilege escalation, Citrix movement, domain-controller reach, NTDS dumping, tooling such as Cobalt Strike, Mimikatz, and Impacket, and confirmed exfiltration of one employee's Box folder contents plus Active Directory authentication data were post-auth problems. Public reporting does not establish access to product development or code-signing systems, and does not establish a quantitative ransom figure. Revoke, endpoint, and directory controls remain required for that residual work.