Multi-factor authentication works. That is not the argument. The argument is that attackers stopped trying to break it some time ago and started working around it instead, and the methods they use now, push approval fatigue, real-time phishing proxies, telephone number takeover, legacy protocol abuse and the help desk, do not require defeating the cryptography at all. MFA fatigue and push bombing are the crudest of these and the most instructive, because they exploit the user rather than the protocol. The technique is simple to the point of insult. An attacker holding a valid password triggers authentication repeatedly, sometimes dozens of times, often at two in the morning. The user, tired and unable to make the prompts stop, approves one. There is no exploit. The second factor performed exactly as designed.
Five bypasses, ranked by how often they work
Approval fatigue. Requires only a valid password and patience. Push notifications that say nothing more than approve or deny give the user no information on which to refuse, which is the design flaw. Real-time phishing proxies. A proxy site relays the victim's credentials and their one-time code to the genuine service within the code's validity window, and captures the resulting session token. Open-source tooling for this has been publicly available since the start of this year and requires very little skill. Crucially, it defeats one-time passcodes of every kind, whether delivered by text message or generated by an authenticator application, because the code is used immediately and legitimately. Telephone number takeover. Persuade a mobile operator to move the number, or exploit a recycled number, and every text-message code follows the attacker. The banking sector has been dealing with this for years; corporate security has largely ignored it. Legacy protocol abuse. This is the one that quietly undoes enterprise deployments. Older mail protocols frequently do not support a second factor, so an account protected for browser sign-in remains reachable by password alone through an old client protocol. Password spraying against those endpoints continues to succeed against organisations that believe they have full coverage. Application consent. Rather than stealing the session, get the user to grant a malicious application permission to read their mail and files. The consent is granted after successful authentication, so the second factor is entirely irrelevant. And behind all five, the help desk, which can reset a factor for whoever sounds sufficiently senior and sufficiently annoyed.
What actually resists this
The distinction that matters is whether the factor is bound to the site the user is visiting. One-time codes are not: a code is a code wherever it is typed, which is why a proxy can relay it. Authentication built on public key cryptography with origin binding, the approach standardised in the web authentication specification that became a formal recommendation earlier this year, cannot be relayed, because the credential simply will not produce a signature for the wrong domain. That is the single most important technical fact in this area, and it implies a clear hierarchy. Hardware security keys and platform authenticators at the top. Push approval with meaningful context next. Authenticator application codes below that. Text message codes at the bottom, above passwords alone but not by a comfortable margin. Alongside the factor choice sits the context. Authentication decisions that account for device state, location, network and the sensitivity of what is being accessed catch a large share of what a factor alone will not, and they reduce prompt volume, which addresses fatigue at its source. Users approve prompts thoughtlessly because they receive too many of them.
Practical Guidance for an MFA Hardening Review
- Disable legacy authentication protocols. This is the highest-value change available and it is usually a configuration setting. Audit which accounts still use them first, because something will break.
- Issue hardware security keys to administrators and executives. A small number of people, a small cost, and the only population for whom compromise is unrecoverable. Do not exempt the executives; exemptions are precisely how these accounts are taken.
- Move off text message codes for anything privileged. Keep them for low-risk consumer-facing use if you must, but not for anyone who can move money, change payroll or administer identity.
- Demand context in approval prompts. Application, location and, where the platform supports it, a value the user must match from the screen. An approve-or-deny prompt with no information is a coin toss delegated to a tired person.
- Cut prompt frequency deliberately. Use trusted devices and sensible session lifetimes so prompts are rare enough to be noticed. Fatigue is a volume problem before it is a behaviour problem.
- Restrict who can consent to applications. Require administrative approval for any application requesting mail or file permissions, and review what has already been granted.
- Harden the help desk. A scripted identity verification for factor resets, a callback to a manager for privileged accounts, and a log of every reset. Then test it by trying to socially engineer your own team.
- Alert on repeated denied prompts. A burst of rejections followed by an approval is the exact signature of this attack and almost nobody monitors for it.
The Regional Angle
The Gulf has standardised on the weakest usable factor more thoroughly than almost anywhere else. Text message codes are the default second factor for regional banking, for government service portals, for telecom self-service and for a great many corporate systems, and they are deeply embedded in public expectation because they work on any handset and require no application. That convenience is real, and it means the regional attack surface is concentrated on a channel that depends entirely on the integrity of a mobile number. That dependency is unusually fragile here for demographic reasons. This is a market of transient residents: people change operators when they change employers, numbers lapse when residents leave the country, and recycled numbers are reissued to new subscribers. An account whose recovery path is a number that now belongs to a stranger is not a hypothetical in a region where a substantial share of the workforce turns over every few years. Every organisation here should be auditing registered mobile numbers against current employment records, and should require re-verification when a number changes rather than accepting a self-service update. The second regional factor is delegation, and it is cultural rather than technical. In a great many Gulf businesses, administrative and public relations staff routinely act on behalf of senior executives, holding credentials and receiving the codes needed to complete government submissions, banking instructions and licensing transactions. This is how work gets done and it will not be eliminated by a policy memo. It can, however, be made legitimate: proper delegated access with its own identity and its own audit trail, rather than a shared password and a forwarded code. Until that is fixed, the strongest authentication in the estate protects an account whose credentials three people possess. Social engineering is also getting better tuned to the region. Arabic-language phishing has improved markedly in the past two years, pretexts now reference local regulators, court notices and visa processes convincingly, and call-based approaches exploit the reality that a genuine call from a government-adjacent entity demanding immediate action is entirely plausible here. An approval prompt arriving during such a call gets approved. Finally, a note on the direction of travel. National digital identity programmes across the Gulf are consolidating authentication into strong, government-issued credentials backed by biometrics and device binding, which is considerably better than a text message and is being extended to private sector integration. Organisations building authentication here should be planning to consume that identity rather than maintaining their own weak second factor indefinitely.
The objection worth taking seriously
The objection comes from two directions at once. From the security side: if a second factor can be relayed, fatigued or reset by the help desk, the industry has spent a decade selling a control that does not hold, and the honest response is to say so rather than to sell the next tier of hardware. From the business side: rolling out physical keys to thousands of staff, disabling protocols that some old line-of-business application depends on, and adding verification steps to the help desk are all real friction, and friction gets escalated to the executives who will then demand the exemption that defeats the whole exercise. The harder version of the argument is that this is an endless treadmill. Passwords were defeated, so we added codes; codes were relayed, so we added push; push was fatigued, so we added hardware keys. Each step cost money, each step was described as decisive, and each step was worked around within a few years. There is no reason to believe the current recommendation is the last one, and organisations are entitled to ask when the spending stops. The treadmill reading is too pessimistic, and the reason is specific. The move from shared secrets to origin-bound public key credentials is not another increment; it removes a whole class of attack, because there is no secret to steal or relay. That is a genuine structural improvement rather than a harder puzzle, and it is why the recommendation to put hardware keys in the hands of your administrators is different in kind from the last five recommendations. On the friction point, the answer is proportionality: a few dozen people hold the accounts that matter, and protecting them properly is cheap. For everyone else, disabling legacy protocols, restricting application consent, reducing prompt volume and training the help desk cost almost nothing and remove most of what is actually happening. Multi-factor authentication is still the highest-return control in security. It just stopped being a box to tick.
Common Questions
Is an authenticator application better than text message codes?
Yes, meaningfully, because it removes the mobile operator and the number from the equation. It does not stop real-time phishing proxies, because the code is still a shared secret typed into whatever page asked for it.
Do we need hardware keys for everyone?
No. Start with administrators, finance approvers and executives. Extend to the general population as platform authenticators built into laptops and phones make it free, which is the direction the specifications are heading.
How do we stop push fatigue without removing push?
Reduce the number of prompts, add context so the user can tell what they are approving, and alert on repeated denials. If a user receives fifteen prompts a day, they are not evaluating any of them.
What should we expect over the next twelve months?
Expect the web authentication standard to appear in more platforms and browsers by default, and hardware key prices to keep falling. Expect phishing proxy tooling to become a commodity component of ordinary criminal campaigns rather than a researcher's demonstration. Expect regulators, particularly in financial services, to start distinguishing between strong and weak second factors rather than treating all multi-factor authentication as equivalent. And expect more attacks aimed at the recovery path and the help desk, because that is where the remaining weakness will be once the factors get stronger.
MFA Hardening Review — we find the accounts your second factor is not actually protecting, close the legacy protocols nobody remembers enabling, and put unphishable credentials where compromise would be unrecoverable.