Two-factor authentication in UAE organisations fails less often because of weak passwords and more because attackers steal the second factor in transit or steal the session that comes after it. SMS one-time codes fall to SIM swap, push notifications fall to prompt bombing, and even correctly entered OTPs fall to adversary-in-the-middle phishing proxies that relay the login in real time. The factor type you choose matters more than whether MFA is switched on.
- Phishing-resistant factors (FIDO2 security keys, passkeys, certificate-based Windows Hello for Business) stop the attacks that SMS and app-based OTP cannot.
- Session token theft after a successful MFA login bypasses the control entirely, so token protection matters as much as the factor itself.
- Assessors testing MFA in UAE environments look for number matching, conditional access scope, and legacy authentication blocking, not just whether MFA is enabled.
- Regulatory guidance in the region is outcome based: evidence that MFA actually resists common bypass techniques on privileged and remote access, not a checkbox on a form.
How MFA actually gets bypassed
Every 2FA method combines something you know (a password), something you have (a phone, a token, a key), or something you are (a fingerprint, a face). Attackers rarely attack the cryptography behind these factors. They attack the weakest link in how the factor is delivered and verified, and in most UAE deployments that weak link is the human approval step or the network path the code travels over.
SMS OTP and push notifications are the weakest factors
SMS one-time codes and mobile app push approvals are the most common 2FA methods in the region because they are cheap and familiar. They are also the easiest to bypass.
Push fatigue
Microsoft Authenticator, Duo, and similar apps send a push notification asking the user to approve or deny a login. An attacker with a valid password sends repeated push requests, sometimes at odd hours, until a tired or distracted employee taps approve just to make the notifications stop. This is not a sophisticated exploit. It relies entirely on the fact that a plain approve or deny prompt gives the user no information about what they are approving. Number matching, where the user must type a code shown on the login screen into the app, closes most of this gap because it forces the user to look at the sign-in attempt rather than react to a notification.
SIM swap and porting fraud
SMS OTP depends on the attacker not controlling the phone number. SIM swap and number porting fraud, where an attacker convinces a telco or an insider to move a victim's number onto a new SIM, defeats this completely. It is slower to execute than push fatigue but far more damaging when it targets a finance or operations account, because the attacker also intercepts calls and other SMS-based recovery flows on the same number.
Adversary-in-the-middle phishing steals the session, not just the password
The bypass that should worry UAE security teams most is the reverse-proxy phishing kit, the type built on tools like Evilginx. Instead of hosting a static fake login page, the kit sits between the victim and the real identity provider, relaying every request and response. The victim enters their real password and their real OTP or approves their real push notification. The kit captures the session cookie issued after that successful, fully legitimate MFA login and replays it to take over the account without ever knowing the password or needing to defeat MFA a second time. This is why a clean MFA audit log, with no failed attempts, is not proof that an account is safe. Token binding, sign-in risk detection, and short session lifetimes for privileged roles matter as much as the MFA method itself once this technique is in play.
Legacy protocols and forgotten paths skip MFA entirely
MFA policies get applied to the web login screen and left off everything else. Legacy authentication on Exchange (IMAP, POP, older SMTP auth), API access using long-lived tokens, VPN clients that still support username-and-password fallback, and break-glass accounts created during a project and never revisited are common paths that never see the MFA prompt at all. A conditional access or identity policy review needs to check every protocol and every application registration an organisation exposes, not just the browser sign-in flow, because a single legacy path is enough to make the rest of the MFA rollout pointless.
What actually resists these attacks
FIDO2 security keys and platform passkeys are origin-bound: the cryptographic challenge is tied to the exact domain the user is authenticating to, so a phishing proxy sitting on a lookalike domain cannot complete the handshake even if the victim is fooled into visiting it. Certificate-based authentication through Windows Hello for Business works the same way. None of this is new technology, and none of it is exotic. The barrier to adoption in most UAE organisations is operational: hardware key procurement and loss handling, and legacy applications that only support the older, weaker methods. Conditional access policies in a platform like Microsoft Entra ID let an organisation require phishing-resistant authentication for admins and finance while keeping a lower-friction method for lower-risk users, which is usually the practical way to move without a disruptive all-or-nothing rollout.
What UAE assessors actually check
A VAPT engagement that tests MFA properly does more than confirm a code is requested at login. It tests whether the number-matching or push-approval flow can be automated against, whether legacy protocols bypass the policy, whether session cookies survive IP or device changes, and whether privileged accounts sit inside the same conditional access scope as regular users or get an exception nobody remembers granting. Regulatory frameworks referenced in UAE audits, including NESA controls and CBUAE expectations for banks, generally call for multi-factor authentication on remote access and privileged accounts without prescribing a specific factor. What assessors actually ask for is evidence: policy configuration exports, conditional access coverage reports, and a list of exclusions with a business reason attached to each one. A privileged access management layer, covered in more detail in the PAM overview, is where most of the exclusion sprawl actually lives, since break-glass and service accounts are the ones most often carved out of MFA policy.
Getting the factor choice right
Treat MFA as a decision with tiers rather than a single switch. Phishing-resistant methods for admins, finance approvers, and anyone with standing access to production systems. Number-matching push or authenticator app OTP, never SMS, for the general workforce. A documented, time-boxed exception process for the legacy systems that cannot yet support modern authentication, reviewed on a fixed schedule rather than left in place indefinitely. None of this requires a large budget. It requires someone to go through the exclusion list and ask why each entry is still there, which is the single most productive hour a UAE security team can spend on identity this quarter. Coverage of the wider access model, including how MFA fits into a broader zero trust and identity and access management programme, is worth reading alongside this before setting the tiers.
