The MFA you have isn’t the MFA you think you have

For nearly a decade, multi-factor authentication has been the control every security leader points to when asked how they’ve reduced account takeover risk. It sits on almost every compliance checklist and nearly every cyber insurance questionnaire, and for good reason — adding a second factor to a password login closed off an enormous share of credential-based attacks, and organizations that adopted it early saw the payoff in fewer compromised accounts. That confidence is now outdated in a way many security teams haven’t fully registered. The MFA adoption rate reported to a board or an auditor rarely distinguishes between the method used to satisfy it. A push notification and a hardware security key both count as “MFA enabled” on the same compliance report, and so does a one-time code sent by SMS — despite sitting at wildly different points on the spectrum of what an attacker can defeat. Uber’s 2022 breach, the MGM Resorts incident, and a growing list of enterprise intrusions traced back to compromised help desks all shared the same root cause: MFA was present, and MFA still failed, because the method in place was never built to resist a targeted attacker. Where push and OTP fail Push notification MFA came first for most organizations, mainly because it was the path of least resistance — nothing for the user to remember, nothing to type and IT could turn it on across the company in an afternoon. That same ease of rollout turned out to be exactly what made it easy to break. Attackers figured out they didn’t need to steal anything sophisticated. They just needed a stolen password and the willingness to send the same approval prompt to someone’s phone over and over, sometimes for hours, until the user got annoyed enough — or tired enough, or confused enough — to tap approve. Security teams call this push fatigue or MFA bombing. It works often enough that it’s now one of the most common ways attackers get past MFA that’s technically “on.” The OTP problem is simpler and uglier than push fatigue. It’s just a code, and a code can be gotten. Sometimes an attacker convinces a mobile carrier to move a victim’s phone number onto a SIM they control — a scam that’s quietly drained crypto wallets and corporate email accounts for years now. Increasingly, though, it doesn’t even require that much effort. Phishing kits built around reverse-proxy tools can now intercept an OTP in real time — the victim types their password and code into what looks like a normal login page, unaware that the page is quietly forwarding everything to the real site on the attacker’s behalf, session and all. Both failure modes share a simple design gap. The authentication method never verifies that the person approving the login and the system requesting it are talking to the same, legitimate destination. That’s the property attackers exploit, and it’s exactly the property newer standards were built to close. Ashish Mishra The property that closes the gap Ask what stops a phishing site from working against FIDO2 or a passkey, and the answer isn’t cleverness — it’s math. A passkey has no code to steal in the first place. What gets created during enrollment is a cryptographic key pair locked to one website, permanently, and a lookalike domain simply isn’t that website, no matter how convincing it looks to a human eye. The browser checks the origin before anything else happens, finds it doesn’t match and the login attempt dies right there — before the user can ever be fooled into approving something they shouldn’t. This origin-binding is the entire point, and it’s worth being precise about it, because vendors market a wide range of products under the “phishing-resistant” label without all of them meeting the bar. A hardware key that still allows a fallback OTP option isn’t resistant if that fallback stays reachable. A passkey stored insecurely on a shared or unmanaged device narrows the gap but doesn’t close it entirely. The strength of the control depends on the full authentication path, not just the strongest link in it. The migration nobody wants to admit is hard. If the technical argument for phishing-resistant MFA is this strong, the natural question is why so many organizations still run on push and OTP. The honest answer isn’t ignorance. It’s friction, and pretending otherwise doesn’t help anyone plan a migration. Older on-premises systems weren’t built with WebAuthn in mind, and neither were some SaaS platforms still in wide use — so somebody ends up bolting on a compensating control or finding a workaround, because ripping and replacing isn’t realistic on most timelines. Hardware keys aren’t free either — multiply even a modest per-user cost across a large workforce, and it adds up fast, and unlike a push notification, a lost or damaged key turns into an actual support ticket. Then there’s the part nobody likes admitting out loud: employees who are used to tapping approve on their phone in two seconds are going to notice, and complain, when the new process means digging a physical key out of a bag and plugging it in. None of that means the migration isn’t worth doing. It means it needs a rollout plan behind it instead of a memo telling everyone to switch by Friday. Starting small, on purpose The organizations making real progress on this aren’t converting their entire workforce overnight. They’re starting where the risk is concentrated, and the resistance to change is lowest: administrator accounts, identity provider access and anyone with the ability to reset another user’s credentials. These are the accounts attackers target first precisely because compromising one unlocks everything downstream, and they’re also the accounts where a small population of technically capable users can absorb a new workflow without much disruption. Finance and engineering come next, along with any other group sitting close to sensitive systems. Legacy applications that can’t yet support the new standard don’t get a permanent pass — they get a conditional access policy in the meantime and a real deadline for when the exception closes. SMS-based OTP should get the same treatment, except with less patience. Of every method still in common use, its weaknesses are the best documented and the most actively exploited, which is exactly why it should carry a sunset date instead of sitting around indefinitely as a fallback. Attackers have already retooled around the MFA most organizations deployed years ago. Waiting for a bigger incident to justify the migration isn’t a strategy; it’s a bet that your organization won’t be next. Start with an honest audit: not which accounts have MFA enabled, but which method is protecting each one.