Common pitfalls of MFA and how to avoid them

Multi-Factor Authentication (MFA) has become the badge of “modern security hygiene,” and for good reason. It adds an extra layer of defense, requiring not just a password, but also a second proof of identity — a code, a push, a key.

But here’s the problem: MFA isn’t bulletproof. Phishable factors, weak fallback flows, inconsistent enforcement, and “push fatigue” are just a few of the ways MFA can go sideways. Worse, attackers have adapted: from real-time reverse proxies to SIM swap-as-a-service, they know exactly how to slip through the cracks.

This post breaks down the most common implementation mistakes — and how to fix them before they’re exploited.

Over-reliance on SMS-based MFA

SMS-based MFA is widely adopted because it’s easy to implement and familiar to users. However, it's vulnerable to SIM swapping, phishing, and interception. Attackers don’t need to guess your password when they can just convince a telecom rep to hand over your phone number.

If you're still relying on SMS, it's time to upgrade. TOTP apps like Authy or Google Authenticator are a baseline. Push-based MFA is better. But the gold standard? FIDO2 or WebAuthn hardware keys. Phishing-resistant and frictionless — if you can make them work for your user base, they’re worth the effort.

Push fatigue is real and exploitable

A user gets five push notifications in a row. They tap “Approve” just to make the buzzing stop. Sound familiar? That’s MFA fatigue, and attackers are abusing it.

They flood users with authentication prompts during busy hours, usually after stealing credentials, betting on frustration or confusion. And they win — more often than you’d think.

So how do you make push-based MFA smarter — not just noisier?

• Number matching: Instead of blindly approving a push, the user is shown a two-digit number on the login screen (e.g., 37). They have to enter that number in the push prompt on their phone. It’s a small UX tweak, but it proves they initiated the login and aren’t just approving random prompts.
• Geolocation prompts: Display the approximate location (e.g., “San Francisco, CA”) or IP address of the login attempt inside the push notification. It gives the user more context — and a chance to spot weird behavior like a login from a country they’ve never visited.
• Device context: Some MFA providers show the device name, OS, browser, or login method (e.g., “MacBook Pro using Chrome”). If a user sees an unfamiliar combo — or something that looks automated — they’re less likely to approve it.
• Rate-limiting pushes: Don’t let attackers spam the user with an infinite number of requests. After 3-5 failed pushes in a short window, throttle or lock out push-based MFA for that session. Alert the user. Make noise.
• Biometric step-up: For sensitive flows (like privilege elevation or financial actions), require biometric confirmation instead of just “approve” — e.g., Face ID or fingerprint on the device receiving the push. Adds friction where it matters.

These aren’t silver bullets, but they turn MFA into a signal-rich control — not just a nagging prompt.

Partial coverage across systems

One of the easiest ways to undermine MFA is to implement it inconsistently. It’s great if your SaaS apps are covered, but what about VPNs? Git access? CI pipelines? Admin panels? Legacy systems?

Attackers go for the weakest link. And if MFA is missing anywhere along the chain — especially for privileged users — the rest doesn’t matter.

Treat MFA like you treat logging: if it’s not everywhere, it’s not working.

Recovery flows: the backdoor no one checks

• Use backup codes securely stored by the user.
• Require re-verification via a secondary trusted device.
• Build a secure identity recovery process that includes human-in-the-loop review.

It’s ironic how often recovery flows bypass all the security of MFA. Someone loses their device, and suddenly support is resetting MFA via email or — worse — security questions.

These paths are gold for attackers. If your fallback method is easier to compromise than your primary flow, you've just built a glorified speed bump.

Good recovery requires friction. Use backup codes, alternate trusted devices, or escalation paths that require manual review. Don’t make the recovery path the weakest part of your system.

Good recovery flows add friction, and they’re designed to resist abuse. Here’s what that actually looks like:

• Backup codes (single-use, securely stored): Give users a set of one-time-use recovery codes when they set up MFA. Let them download or print these, and educate them to store them somewhere safe (not in plaintext in their email or notes app). Rotate them on use or reset. This is the most direct recovery path — and it works offline.
• Trusted devices / alternate factors: Let users verify via a previously enrolled device or another factor (e.g., a YubiKey, desktop push, or TOTP on a secondary device). This allows for recovery without breaking the MFA chain — especially helpful in BYOD environments.
• Deliberate delay + notifications: Introduce a delay (e.g., 24–48 hours) for recovery actions like resetting MFA. Send email notifications to the account and any trusted devices with details like timestamp, location, and IP. This gives real users time to detect suspicious requests and respond.
• Escalation flows with human review: For high-value accounts or admin users, route MFA reset requests to a manual review queue. Require government-issued ID, webcam verification, or internal manager approval. It’s a pain — and that’s the point. You’re trading convenience for protection against targeted account takeovers.
• Tamper detection / audit trail: Log every recovery request and flag anomalies: sudden reset requests from unfamiliar devices, locations, or users who haven't logged in for months. Integrate with SIEM tools and set up alerting thresholds.
• Don’t trust email alone: If your fallback flow is “click this link we emailed you,” and that email account isn’t protected by MFA, you’ve just created a circular vulnerability. Make sure fallback paths don’t rely solely on email unless you’ve verified the security posture of the associated email account.

Recovery is where attackers go when MFA works. If you’ve built a strong front door, make sure the side entrance isn’t wide open.

Phishing is evolving

Modern phishing isn’t just about tricking someone into typing their credentials into a fake login page anymore. It’s about stealing the entire authenticated session, after the user successfully logs in with MFA. This is possible thanks to real-time man-in-the-middle (MITM) attacks — and off-the-shelf phishing kits make it stupidly easy.

Tools like Evilginx, Modlishka, and Muraena act as reverse proxies. Here's what that means:

1. The attacker sets up a fake login page (e.g., fake login.microsoftonline.com) that relays traffic to the real Microsoft login page in real time.
2. The user enters their username, password, and MFA code — all of which are passed directly to the legit service.
3. The user gets logged in… but so does the attacker, who captures the session cookies during this exchange.
4. With those tokens, the attacker skips future MFA checks entirely and hijacks the session.

No malware. No brute-force. No need to compromise the second factor — they just walk right around it.

SMS and TOTP don’t help because these are phishable MFA methods — they don’t bind the authentication challenge to the browser or the origin. If a user types a 6-digit TOTP into a phishing site, it works exactly the same as typing it into the real one.

Once the attacker gets the session, MFA is done. They’re in.

What can help is WebAuthn and hardware keys. Hardware-backed authentication, like WebAuthn, FIDO2, or YubiKeys, is origin-bound. That means:

• The authentication challenge is signed by the physical device.
• It only works if the origin (domain) is an exact match — no phishing site can spoof that.
• There’s no code to type. Nothing to intercept. No session tokens to steal.

In short, even a perfect MITM attack won’t work, because the attacker can’t complete the cryptographic challenge without access to the hardware.

If you can’t deploy WebAuthn across the board (yet), start with your most sensitive users:

• Admins and superusers
• DevOps and CI/CD pipeline maintainers
• Finance, legal, and customer data access roles

At a bare minimum:

• Train users to check the browser address bar and domain.
• Teach them to spot fake login pages and unusual consent flows.
• Consider browser extensions or Identity-Aware Proxies that block known MITM phishing kits.

Shared credentials ruin everything

In some teams (especially small ones), people still share accounts — and with them, MFA devices. Suddenly, you’ve got one TOTP code floating around Slack or taped to a monitor. Congratulations: you’ve just nuked your audit trail.

If you need multiple people accessing the same resource, don’t share accounts. Use RBAC, assign individual credentials, and enforce MFA at the user level. MFA can’t do its job if you’ve skipped basic account hygiene.

MFA is not a silver bullet

It’s easy to fall into the trap of thinking that enabling MFA equals “secure.” It doesn’t — it just raises the bar. And attackers are adapting.

Once someone gets in — through session hijacking, OAuth token theft, or even a legitimate MFA-approved login — MFA stops being relevant. It won’t detect lateral movement, privilege escalation, or malicious use of existing access.

That’s why MFA can’t be the end of your strategy — it’s just the start.

You need continuous context and visibility around what’s happening after authentication. That means:

• Anomaly detection: Is this login happening from a new country or device?
• Session intelligence: Are tokens being reused or suddenly acting suspicious?
• Posture-aware decisions: Is the user coming from an unmanaged device or using outdated browser versions?
• Behavioral baselines: Is a low-privilege user suddenly exporting customer data at 3am?

This is where tools like WorkOS Radar come in.

With WorkOS Radar, you can detect abnormal login patterns and either block them or escalate. You can respond immediately when something looks off. And combined with Audit Logs for advanced event logging and streaming, you’ve moved from “we enabled MFA” to actually monitoring for abuse and misuse in real time.

Fixing MFA the right way

MFA is necessary — but not sufficient. It’s one piece of a modern access security strategy, not a checkbox. And while it raises the bar, motivated attackers will still look for gaps — in recovery flows, session handling, or user behavior.

If you’re serious about stopping real-world threats, the goal isn’t just “have MFA.”

The goal is to have MFA that can’t be phished, recovery that can’t be abused, and visibility that lets you catch misuse in real time.

That’s exactly what we’re building at WorkOS:

• MFA with support for SMS and TOTP using a third-party authenticator app such as Google Authenticator or Authy.
• Passkey support via WebAuthn, making phishing-resistant auth dead-simple to implement.
• Magic Auth, a passwordless authentication method that allows users to sign in or sign up via a unique, six digit one-time-use code sent to their email inbox.
• All recovery actions, MFA resets, login attempts — it’s all recorded via WorkOS Audit Logs and can be streamed to the SIEM of your choice, like Datadog or Splunk. This gives you tamper-resistant visibility into account security actions, critical for compliance and post-incident investigation.
• Protection against bots, fraud, and abuse with WorkOS Radar. Protect against bots, challenge logins from unknown devices, prevent brute force attacks, guard dormant accounts, detect impossible travel scenarios, and more.
• With WorkOS Fine-Grained Authorization, you can evaluate access decisions not just on who the user is, but on context, like geolocation and time of the day. It’s a powerful way to implement adaptive access control.

Security doesn’t have to be duct tape and spreadsheets. With WorkOS, you get the building blocks to ship enterprise-grade auth that’s actually secure — without blowing up your roadmap.

Final thoughts

MFA is necessary — but not sufficient. It works best when it’s part of a layered security model, not bolted on as a checkbox.

If you’re serious about stopping real-world attacks, the goal isn’t just to have MFA.

The goal is to have MFA that can’t be phished, bypassed, or abused.

Want help implementing phishing-resistant auth or rolling out WebAuthn?

Sign up for WorkOS — we’ve seen the mess, and we’ve built the tools to clean it up.