{"id":9694,"date":"2026-09-30T10:00:00","date_gmt":"2026-09-30T10:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9694"},"modified":"2026-09-30T10:00:00","modified_gmt":"2026-09-30T10:00:00","slug":"the-mfa-you-have-isnt-the-mfa-you-think-you-have","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9694","title":{"rendered":"The MFA you have isn\u2019t the MFA you think you have"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

For nearly a decade, multi-factor authentication has been the control every security leader points to when asked how they\u2019ve reduced account takeover risk. It sits on almost every compliance checklist and nearly every cyber insurance questionnaire, and for good reason \u2014 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.<\/p>\n

That confidence is now outdated in a way many security teams haven\u2019t 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 \u201cMFA enabled\u201d on the same compliance report, and so does a one-time code sent by SMS \u2014 despite sitting at wildly different points on the spectrum of what an attacker can defeat. Uber\u2019s 2022 breach, the MGM Resorts incident<\/a>, 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.<\/p>\n

Where push and OTP fail<\/h2>\n

Push notification MFA came first for most organizations, mainly because it was the path of least resistance \u2014 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\u2019t need to steal anything sophisticated. They just needed a stolen password and the willingness to send the same approval prompt to someone\u2019s phone over and over, sometimes for hours, until the user got annoyed enough \u2014 or tired enough, or confused enough \u2014 to tap approve. Security teams call this push fatigue or MFA bombing<\/a>. It works often enough that it\u2019s now one of the most common ways attackers get past MFA that\u2019s technically \u201con.\u201d<\/p>\n

The OTP problem is simpler and uglier than push fatigue. It\u2019s just a code, and a code can be gotten. Sometimes an attacker convinces a mobile carrier to move a victim\u2019s phone number onto a SIM they control \u2014 a scam that\u2019s quietly drained crypto wallets and corporate email accounts for years now. Increasingly, though, it doesn\u2019t even require that much effort. Phishing kits built around reverse-proxy tools can now intercept an OTP in real time \u2014 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\u2019s behalf, session and all.<\/p>\n

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\u2019s the property attackers exploit, and it\u2019s exactly the property newer standards were built to close.<\/p>\n