Notifications
Clear all
Topic starter
08/06/2026 5:06 pm
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.
NHIMG editorial — based on content published by WorkOS: Common pitfalls of MFA and how to avoid them
Questions worth separating out
Q: How should security teams implement phishing-resistant MFA for privileged users?
A: Start with the identities that would cause the most damage if compromised, such as administrators, developers, finance, and support staff.
Q: When does MFA create a false sense of security?
A: MFA becomes misleading when organisations count factor enrollment as the security outcome, even though recovery flows, session theft, or push abuse still allow account takeover.
Q: What do security teams get wrong about MFA recovery flows?
A: They often treat recovery as an administrative convenience instead of an attack path.
Practitioner guidance
- Replace phishable MFA for high-risk users Move admins, developers, finance users, and customer-data roles to WebAuthn or another phishing-resistant method first.
- Harden recovery as a governed access path Require manual review, trusted-device verification, or delayed reset workflows for MFA recovery.
- Reduce push approval ambiguity Add number matching, device context, and rate limits to push flows so the user must confirm a real login context, not just silence repeated prompts.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Concrete examples of number matching, geolocation prompts, and device context for push MFA.
- Step-by-step guidance on recovery flows that avoid email-only resets and weak help desk shortcuts.
- Specific deployment advice for WebAuthn and FIDO2 across sensitive user groups.
- Examples of session-intelligence and anomaly-detection signals that extend protection after login.
👉 Read WorkOS's analysis of common MFA pitfalls and phishing-resistant auth →
MFA pitfalls and recovery flaws: are your controls keeping up?
Explore further
08/06/2026 7:06 pm
Phishable second factors are a temporary trust layer, not a durable identity guarantee. SMS, TOTP, and push approval all assume the second factor proves the real user at the real prompt. In practice, phishing kits, SIM swaps, and fatigue attacks separate the factor from the decision, so the assurance is narrower than most programmes assume. The implication is that identity teams need to stop treating second-factor coverage as the same thing as phishing resistance.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why authentication controls without lifecycle visibility still leave major blind spots.
A question worth separating out:
Q: How do you know if MFA is actually protecting users?
A: Look for evidence beyond enrollment counts. Measure whether phishable factors still exist on privileged accounts, whether recovery actions are reviewed, and whether session anomalies are detected after login. If attackers can still get in through fallback flows or token reuse, MFA coverage is incomplete even if every user has a factor enrolled.
👉 Read our full editorial: MFA pitfalls expose why phishing-resistant auth matters now
