TL;DR: MFA can still be bypassed through phishable factors, push fatigue, weak recovery flows, and session hijacking, according to WorkOS. The real control gap is not whether MFA exists, but whether it resists real-time phishing, abuse of fallback paths, and post-login misuse.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Common pitfalls of MFA and how to avoid them”.
Key questions
Q: What breaks when MFA still allows phishing and push fatigue?
A: The control breaks when users can be tricked into approving a session they did not truly initiate, or when a phishable factor can be relayed through a fake login flow.
Q: Why do weak MFA recovery flows create more risk than the login step itself?
A: Recovery becomes dangerous when support resets, email links, or security questions are easier to compromise than the primary factor.
Q: How can security teams tell whether adaptive MFA is working properly?
A: Look for a lower challenge rate on routine sessions, a higher challenge rate on suspicious transactions, and stable or improved conversion.
Practitioner guidance
- Deploy phishing-resistant authentication for high-value access Use WebAuthn or hardware-backed authenticators for admins, superusers, and other sensitive roles where real-time phishing and prompt abuse would have the highest impact.
- Harden MFA recovery and reset workflows Require manual review, trusted-device verification, or tightly controlled backup codes so recovery cannot be easier to abuse than primary login.
- Eliminate MFA coverage gaps across critical systems Map where MFA is missing across VPNs, admin panels, legacy systems, CI pipelines, and shared accounts, then close those exceptions before they become the easiest path in.
Bottom line: MFA is still bypassed in practice when the second factor can be phished, spammed, or reset through weaker fallback paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Phishing-resistant authentication is now the dividing line, not MFA presence. The article shows that phishable factors can still be relayed through a real-time proxy, which means possession-based MFA does not reliably prove user intent. That is why the relevant governance question is whether the second factor is origin-bound, not whether a box labelled MFA is checked. Practitioners should treat WebAuthn-class protection as the control boundary for high-value access.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: What should organisations do after an MFA-protected session is hijacked?
A: Contain the session, revoke tokens, review the surrounding login and recovery events, and check for privilege misuse after authentication. The goal is to stop the attacker from extending the session into lateral movement or privileged action. MFA is only the entry control, so post-login monitoring and audit trails become essential.
👉 Read our full editorial: MFA pitfalls expose why phishing-resistant auth matters now