Multi-factor authentication remains one of the most valuable controls available, and every organization should have it enabled everywhere. That is the starting position, and nothing below argues against it.
What has changed is that attackers adapted. Push bombing, adversary-in-the-middle phishing and session token theft now defeat weak MFA routinely, and they are commodity techniques rather than advanced tradecraft. The uncomfortable conclusion is that having MFA enabled is not the same as being protected, because the method determines whether the control holds.
Why Identity Became the Primary Target
Attackers prefer to log in rather than break in. A valid credential provides a legitimate-looking path that generates far fewer alarms than malware, and an attacker holding a real identity can read mail, reach files, move to connected systems and escalate privilege while looking like an employee.
Several forces concentrated attention here. Credentials are traded at scale, harvested by phishing and stolen by information-stealing malware. Password reuse means one leak can unlock several services. Single sign-on, which is good for security overall, concentrates access so that one compromised identity reaches many applications. And valid logins blend into normal activity, which delays detection.
The practical consequence is that the strength of your identity controls now substantially determines the strength of your whole security posture.
Not All MFA Is Equal
The phrase "we have MFA" covers a range of protection wide enough to be nearly meaningless.
| MFA method | Resistance to current attacks |
|---|---|
| SMS one-time codes | Weak: phishable, and vulnerable to SIM swap |
| App-based codes | Moderate: phishable through a proxied login page |
| Simple approve or deny push | Weak: vulnerable to push bombing |
| Number-matching push | Better: resists blind approval |
| Hardware keys and passkeys | Strong: phishing-resistant by design |
The pattern is consistent. Any method that produces a secret the user can be induced to supply on a page the attacker controls can be phished. Phishing-resistant methods remove that secret entirely, which is why moving high-value accounts to hardware keys and passkeys is among the highest-impact changes available.
Push Bombing
When an attacker already holds a valid password, they can simply trigger approval prompts repeatedly. Some users eventually approve, whether from confusion, from habit, or because the notifications are arriving at two in the morning and they want them to stop.
It works because a simple approve-or-deny prompt asks for a single tap and provides no context about where the request originated.
Defenses are straightforward: move to number matching, which requires the user to enter a code displayed on the login screen; limit prompt frequency and lock accounts after repeated failures; show location and application context in the prompt; and tell people that repeated unexpected prompts mean their password is already compromised and should be reported.
Adversary-in-the-Middle
This is the technique that defeats most MFA deployments in practice, and it does not attack the MFA challenge at all.
The victim is directed to a reverse proxy that relays every request to the genuine login service and every response back. The real login page appears, because it is the real login page. The genuine MFA prompt arrives, and the user approves it legitimately, because they did just try to log in. The proxy captures the session token issued afterward.
Nothing is defeated. Everything works as designed, and the attacker ends up holding an authenticated session. Open-source toolkits made this straightforward several years ago, which is why it is now routine.
Only phishing-resistant MFA stops it outright, because the cryptographic exchange fails against a proxy on a different domain. We have documented a full engagement following this path in phishing that bypassed MFA.
Protecting What Happens After Login
Most identity controls operate at the moment of authentication. The attacks above produce a valid session, so controls that only run at login never engage again.
- Conditional access. Evaluate device compliance, location and risk signals, and require reauthentication when they change.
- Shorter token lifetimes and continuous access evaluation. Reduce how long a stolen token stays useful and revoke sessions when risk changes rather than at expiry.
- Session anomaly detection. A session issued in one place and used shortly afterward from a different network is the clearest available signal.
- Watch follow-on actions. New mail forwarding rules, unusual OAuth consent grants and first-time access to sensitive locations reliably indicate a compromised identity.
Testing Your Identity Controls
Identity is testable, and assumption is expensive here. A red team or targeted social engineering assessment establishes whether your MFA implementation resists the techniques actually in use, whether your detection notices a stolen session, and whether your response process contains it.
The questions worth answering are specific: which accounts still use phishable methods, what an attacker reaches with one compromised identity, whether anything would alert on a session used from an unexpected location, and how quickly you could revoke it.
To have your identity controls tested against these techniques, get in touch.
Frequently asked questions
Is MFA still worth deploying if attackers can bypass it?
Yes, emphatically. MFA stops the large majority of credential attacks, including password spraying, credential stuffing and reuse of credentials from breach corpora. Every organization should have it enabled everywhere. The argument here is not against MFA but against assuming that enabling it ends the conversation, because the method chosen determines whether it holds against current techniques.
What is push bombing?
Push bombing, or MFA fatigue, is where an attacker who already holds a valid password triggers repeated approval prompts to the user's device until the user approves one out of confusion, habit or a desire to stop the notifications. It works against simple approve-or-deny prompts because approval takes a single tap and the prompt gives no context about where the request came from.
What makes an MFA method phishing-resistant?
Cryptographic binding to the legitimate domain. FIDO2 security keys and passkeys complete an exchange that only works with the genuine site, so a proxy on a different domain cannot relay it. Methods that produce a code or an approval the user can be tricked into providing on an attacker-controlled page are phishable by definition, however long the code is.
Should we remove SMS-based MFA entirely?
Move away from it where you can, but weigh the alternative honestly. SMS is phishable and vulnerable to SIM swap, and it should not protect administrative accounts or high-value roles. For a population that would otherwise have no second factor at all, SMS remains considerably better than nothing. Prioritize replacing it where the account matters most.
What happens after the login is what matters. Why?
Because a successful authentication produces a session token, and that token is what an attacker actually steals in modern identity attacks. Once a token exists, further authentication challenges are not presented. Controls that only operate at login therefore protect a moment, while conditional access, token lifetime limits and continuous evaluation protect the session that follows it.