# Why Your MFA Is Failing You — And What to Do About It
For years, security teams have treated multi-factor authentication as the silver bullet for account compromise. It appears on compliance checklists, cyber insurance forms, and boardroom slide decks with little scrutiny. The uncomfortable truth, however, is that not all MFA is created equal, and the gap between having “something” in place and having something truly secure has never been wider.
A growing number of high-profile breaches are revealing an unsettling pattern: organizations had MFA enabled, yet attackers still walked through the front door. The difference lies entirely in which authentication method was in place — and whether that method was ever designed to withstand a deliberate, targeted attack.
## The Limits of the Familiar
Push notification authentication became popular because it was effortless to deploy. IT teams could enable it company-wide with minimal training, users appreciated the simplicity of tapping a notification on their phone, and the compliance boxes got checked. Unfortunately, that ease of adoption became the very thing that made it exploitable.
Attackers discovered they could trigger repeated push notifications to a single device, bombarding the user with approval requests until the fatigue set in. A user distracted by a busy day, confused by the volume of prompts, or simply eager to make them stop would eventually tap “Approve” — handing the attacker full access to the account. This technique, sometimes called MFA bombing or push fatigue attacks, has become one of the most reliable ways adversaries bypass authentication that is technically “active.”
One-time codes delivered via SMS face an even more fundamental problem: the codes themselves can be intercepted. SIM-swapping fraud, where an attacker convinces a mobile carrier to redirect a victim’s phone number, has been used to drain cryptocurrency accounts and breach corporate email for years. More recently, sophisticated phishing kits running behind reverse proxy servers have made it possible to capture SMS codes in real time. The victim enters their credentials and the code into what appears to be a legitimate login page, not realizing that everything is being forwarded to the attacker, who immediately uses it to establish a live session.
## What Actually Protects You
The critical weakness shared by push notifications and SMS codes is that they never confirm the destination. There is no cryptographic guarantee that the device the user is approving on is talking to the genuine service, not a convincing copy operated by an attacker.
Standards like FIDO2 and WebAuthn — the technology behind hardware security keys and passkeys — close this gap through origin binding. During enrollment, a cryptographic key pair is generated and permanently tied to a specific website. When the user later attempts to authenticate, the browser verifies that the site requesting the login matches the site the key was registered to. If the domains don’t match — even if the page looks identical to the real thing — the authentication attempt is rejected before the user ever sees a prompt.
No human judgment is required. No code needs to be typed or forwarded. The security is rooted in mathematics and protocol design, not in whether a user noticed something looked off.
It is important to understand, however, that not every product marketed as “phishing-resistant” actually meets this standard. A hardware security key that still permits an SMS fallback leaves a door open. A passkey stored on a shared device that multiple people can access weakens the protection. True resilience depends on the integrity of the entire authentication chain, not just the strongest component sitting at the end of it.
## Facing the Real Migration Hurdles
If phishing-resistant authentication is this effective, why do so many organizations still depend on push notifications and SMS codes? The honest answer is that the transition is genuinely difficult — and pretending otherwise undermines every planning effort.
Legacy on-premises applications were built long before WebAuthn existed, and some modern SaaS platforms still lack native support. These environments often require compensating controls, conditional access policies, or creative workarounds that keep older methods in place for the time being. Hardware keys introduce a per-user cost that can scale quickly, and every lost or damaged key generates a support ticket that a push-only system simply does not produce. There is also an undeniable human element: employees accustomed to confirming a login in seconds will push back when the new workflow requires retrieving a physical device and inserting it into a computer.
None of these obstacles make the migration impossible — they make it necessary to approach with a deliberate plan rather than a blanket deadline.
## A Practical Path Forward
The organizations that are successfully modernizing their authentication are not attempting a single, company-wide cutover. They are prioritizing ruthlessly, focusing first on the accounts that attackers find most valuable.
Privileged administrators, identity platform access, and anyone with the ability to reset other users’ credentials should be the first line of defense. These accounts are the highest-value targets, and compromising a single one can cascade into a full organizational breach. Because these users are typically smaller in number and more technically fluent, they can adapt to a new workflow with minimal disruption.
Finance and engineering teams, along with anyone with deep access to sensitive systems, form the next priority. Legacy applications that cannot yet support the modern standard should receive temporary conditional access policies rather than being allowed to remain on weak authentication indefinitely.
SMS-based one-time codes deserve particular attention. Their vulnerabilities are among the most thoroughly documented in the cybersecurity landscape, and they are actively exploited by adversaries on a wide scale. Organizations should assign a firm deprecation timeline to SMS OTP rather than letting it linger as a default fallback.
The starting point for any organization serious about this work is not “which accounts have MFA turned on,” but “which method is protecting each account.” That audit alone can be revealing — and sometimes sobering.
—
## Frequently Asked Questions
**Does enabling any form of MFA meaningfully reduce account takeover risk?**
Yes. Even the weaker forms of MFA raise the bar for attackers significantly compared to passwords alone. The issue is not whether MFA is worthwhile — it is that not all methods offer the same level of protection against a targeted adversary. Organizations should aim to strengthen their methods over time rather than treating any MFA implementation as a finished state.
**Can passkeys be compromised if the device is lost?**
Passkeys are designed with built-in recovery mechanisms. Most modern platforms allow users to sync passkeys across devices or set up backup authentication methods. However, if a passkey is stored on a single unmanaged device with no recovery path, losing that device can create access problems. Proper enrollment and backup configuration are essential.
**Are hardware security keys the best option for every user?**
Hardware keys offer strong protection, but they introduce logistical challenges around distribution, replacement, and user training. They are an excellent choice for high-privilege accounts and teams where the workflow can be adopted smoothly. For broader workforce deployment, passkeys stored on managed devices may provide a better balance of security and usability.
**What happens when a legacy application does not support modern authentication?**
Organizations should implement conditional access policies that either limit the exposure of those applications or require additional verification steps at the network or identity layer. These exceptions should have a defined sunset date and a plan for either upgrading the application or removing its access to sensitive data.
**Is it realistic to replace SMS-based OTP entirely?**
It is both realistic and recommended. The documented weaknesses of SMS OTP make it the least resilient common method. Most organizations can replace it with a combination of push notifications (as an interim step) and phishing-resistant methods (as the long-term goal). The key is setting a clear timeline and not allowing SMS to persist as a permanent fallback.
—
## Conclusion
Multi-factor authentication remains one of the most impactful security controls available, but the era of treating it as a binary checkbox is over. The method you use matters enormously, and the gap between convenience-focused methods and genuinely phishing-resistant standards has become a serious risk vector that attackers are actively exploiting. Moving toward FIDO2-based authentication and passkeys requires effort, investment, and careful planning — but the alternative is leaving your most critical accounts protected by mechanisms that were never designed to stop a determined attacker. Start with your highest-risk accounts, build a realistic timeline, and treat authentication as an evolving control rather than a one-time deployment.
Thank you for reading
