Guest: Gil Rosenthal
Today I’m digging into MFA fraud, which is one of those topics that sounds simple until you get into how many ways it can actually go wrong. Multifactor authentication is supposed to make accounts safer, and a lot of the time it does. But if you work in fraud, you already know the harder question is not whether MFA exists. It is whether the right person actually completed it, under the right conditions, for the right reason.
That is where things get interesting.
In this episode, I sat down with Gil Rosenthal to talk about the vulnerabilities and workarounds fraud teams keep seeing across SMS authentication, email authentication, authentication apps, magic links, and other verification flows. Because at first glance, a successful MFA event can look reassuring. But when you dig in, it can also be the beginning of the real problem.
We talk through how criminals get around MFA, what root causes tend to sit underneath spikes in these attacks, and why it is so important to review what happens after an authentication event, not just the authentication itself. That part matters a lot. Because if an account gets accessed, a withdrawal is made, or a large purchase clears right after MFA succeeds, fraud teams need to understand whether the person who passed that step was actually the legitimate customer.
And honestly, that is the part too many teams miss.
Here is what that means in practice:
- MFA fraud often happens when companies trust the authentication event without examining the context around it
- OTP fraud and one-time password fraud can still lead to account takeover fraud even when the code was technically valid
- Account takeover prevention gets stronger when teams look at what changed before and after MFA was completed
- Suspicious login detection should include phone changes, email changes, carrier changes, and post-login behavior
What you’ll hear in this episode:
- How criminals exploit multifactor authentication across SMS, email, apps, and magic links
- Why OTP fraud, push notification fraud, and MFA fatigue still work on real customers
- What fraud teams should investigate when MFA attack volume suddenly spikes
- How SIM swap fraud and account profile changes can signal higher account takeover risk
- Why phishing-resistant MFA matters, but still is not the whole answer on its own
You should listen to this episode if you:
- Work in fraud, risk, identity, banking, or fintech and need a better framework for MFA fraud
- Want stronger account takeover prevention tied to real suspicious login detection signals
- Are dealing with OTP fraud, SMS authentication abuse, or unauthorized claims after MFA succeeds
- Need to understand how SIM swap fraud, email authentication abuse, or push notification fraud fit into the bigger picture
- Care about fraud detection that goes beyond “MFA passed” and looks at what happened next
If you liked this episode, be sure to subscribe and review the podcast on iTunes, Spotify, YouTube, or wherever you listen to podcasts. It really helps with getting the word out.
Episode notes & key takeaways
Why MFA fraud is still a real problem
Let’s break this down.
A lot of companies talk about multifactor authentication like it is a clean solution. Turn it on, add friction, reduce account takeover. And yes, it can absolutely help. But fraud teams know the reality is a lot messier than that.
Because MFA only works if the person completing the challenge is actually the right person.
That is the issue.
If an attacker can manipulate the customer into handing over a code, intercept the step through SIM swap fraud, abuse a weak recovery flow, or trick someone into approving a prompt they do not fully understand, then the authentication event becomes a trust signal built on the wrong person. And once that happens, the rest of the session can look much more legitimate than it really is.
This is exactly why MFA fraud deserves a more practical conversation. Not whether multifactor authentication is good in theory, but how it fails in practice and what fraud teams should watch for when it does.
- MFA fraud happens when the step is completed successfully but the intent behind it is not legitimate
- Account takeover fraud can still happen after strong authentication if the attacker controls the flow
- Fraud detection needs to evaluate context, not just whether a code or prompt was accepted
- Account takeover prevention gets much stronger when teams stop treating MFA success as the end of the story
How OTP fraud and MFA fatigue usually work
Here’s what’s actually happening.
A lot of MFA abuse still comes back to one basic idea. Attackers do not always need to break the technology. They just need to manipulate the person using it. That is why OTP fraud and MFA fatigue keep showing up so often.
A one-time password can be technically valid and still be used for fraud.
That matters.
Maybe the customer got tricked into sharing the code during a phishing flow. Maybe they thought they were confirming something legitimate. Maybe they were rushed, confused, or coached through it in real time. Push notification fraud works in a similar way. Attackers generate enough prompts that the customer eventually approves one just to make it stop or because the prompt feels routine enough.
That usually does not end well.
Because once the attacker gets the valid step-up they need, the session may be treated as trusted. Then the real damage starts. Account access. Funds movement. Large purchases. New payees. Profile changes. Whatever the account makes possible.
- OTP fraud often succeeds because users are manipulated, not because the code itself is weak
- One-time password fraud can authorize a high-risk session that looks legitimate afterward
- MFA fatigue works by wearing down the customer’s attention and judgment
- Push notification fraud should be treated as a behavioral problem, not just a technical one
Why account changes often reveal the real risk
This is one of the most useful parts of the conversation with Gil.
When teams see a spike in MFA fraud or unauthorized use claims after MFA was successful, one of the smartest things they can do is go backwards and ask what changed on the account first. Did the phone number change? Did the email change? Did the carrier change? Did the account recovery method get updated? Was there a recent password reset or profile edit?
That is where the real risk often starts to show itself.
Because those changes can tell you a lot about whether the attacker was preparing the account for takeover before the customer ever saw the MFA step. A SIM swap fraud case, for example, may not look obvious if all you examine is the successful login. But if the phone number was moved or the carrier changed shortly before the event, the story looks very different.
Right.
And this is why suspicious login detection has to be broader than just geolocation or device mismatch. Fraud teams need to connect profile changes, authentication method changes, and downstream behavior to understand what actually happened.
- SIM swap fraud often becomes visible only when teams connect it to account changes before the login
- SMS authentication abuse can be part of a longer preparation phase, not just a one-time event
- Suspicious login detection should include recent account edits and recovery-channel changes
- Fraud detection improves when teams review the sequence of events, not just the final login state
Why phishing-resistant MFA still is not the whole answer
This is where nuance matters.
I am very much in favor of stronger authentication. And yes, phishing-resistant MFA is a real improvement over weaker methods. But it is still important not to oversimplify the problem. Stronger authentication helps. It does not remove the need for fraud judgment after access is granted.
Because the login is not always the end goal.
Sometimes the attacker wants the account. Sometimes they want the money movement after the login. Sometimes they want to add a payee, change settings, or create the kind of trusted session that makes later activity easier. So even when you upgrade authentication, you still need to monitor what happens next.
That is the part fraud teams should care about.
If a customer passes MFA and immediately initiates an unusual withdrawal, changes their contact information, or makes a high-risk purchase that does not fit their normal behavior, that should still trigger attention. Stronger authentication does not eliminate the need for post-auth fraud detection.
- Phishing-resistant MFA reduces some risk, but it does not eliminate downstream account abuse
- Account takeover prevention should include post-login monitoring, not just access controls
- Fraud detection needs to evaluate what a user does after authentication succeeds
- Better authentication works best when paired with stronger decisioning around risky actions
Why “MFA passed” should never be the final answer
Honestly, this is the biggest takeaway from the episode.
Too many teams treat a successful MFA event like a case closed. The user passed. The code matched. The prompt was approved. The step-up worked. And from a pure authentication standpoint, maybe that is all true. But from a fraud standpoint, that answer is often incomplete.
Because the real question is not just whether MFA passed. It is who passed it, how they passed it, and what happened next.
That is the part that holds up.
Gil and I talk a lot in this episode about root causes, not just symptoms. If a company sees more unauthorized claims after MFA success, the goal should not be to shrug and assume the control worked. The goal should be to understand whether the control was used by the wrong person, whether the user was manipulated, or whether the fraud shifted into the post-authentication stage.
The big takeaway from this episode is pretty straightforward. MFA fraud is not proof that authentication is useless. It is proof that fraud teams need to think beyond whether the challenge succeeded. OTP fraud, MFA fatigue, SMS authentication abuse, email authentication abuse, and SIM swap fraud all show how attackers work around trust signals when the surrounding controls are weak. If you want stronger account takeover prevention, you have to look at the setup, the context, and the behavior after MFA, not just the login itself.
That is the part I would pay attention to.
