Phishing-resistant MFA means an authentication method — like FIDO2/WebAuthn passkeys or hardware security keys — that cannot be relayed, replayed, or approved by mistake, because the credential is cryptographically bound to the real website and the user's device. SMS OTP and app-based one-time codes fail this test: attackers routinely steal them in real time through phishing proxies, SIM swap fraud, and MFA fatigue attacks. For any Indian business handling money, customer data, or admin access, migrating critical accounts to phishing-resistant MFA is now a baseline control, not an advanced one.
Multi-factor authentication was supposed to be the control that ended account takeover, and for automated, credential-stuffing attacks it largely has. But the specific factor matters. A six-digit code sent by SMS or generated by an authenticator app is still a shared secret that a human has to read and type. Anything a human can be tricked into typing, an attacker can be tricked into receiving. That single fact is why OTP-based MFA is now a known weak point, and why NIST, CISA, and the FIDO Alliance have spent the last several years pushing organizations toward authentication that removes the human from the trust decision entirely.
Why OTP and SMS Codes Are No Longer Enough
SIM swap fraud
SIM swap attacks target the mobile number itself, not the account. An attacker gathers enough personal information about a victim — often from a data leak or a social-engineering call to the telecom operator — to convince the carrier to reissue the victim's number onto a SIM the attacker controls. Every SMS OTP and every "forgot password" text now lands in the attacker's phone; the account owner typically finds out only when their number stops working. This is not theoretical in India: telecom fraud and SIM-swap-enabled banking fraud are recurring categories in RBI and law-enforcement advisories, and it is one reason RBI guidance has pushed banks toward stronger, non-SMS authentication for high-value transactions over the years.
Real-time phishing (adversary-in-the-middle)
The more dangerous shift is real-time phishing kits — sometimes called adversary-in-the-middle (AiTM) proxies. Instead of a crude fake login page that just harvests a password, these kits sit between the victim and the real website, relaying every field the victim submits, including the OTP, in real time. The victim logs into what looks like their real bank, email, or SaaS portal; the kit forwards the credentials and the code to the actual service within seconds and steals the resulting session cookie. Because the OTP is used within its own short validity window, the attacker gets in — and the victim never sees anything wrong. NIST and CISA guidance both call this out: OTP delivered over SMS or generated by an app is "phishable" because the human, not the browser, decides whether the destination is legitimate.
MFA fatigue (push-bombing)
A third pattern targets push-based approval instead of codes. Once an attacker has a valid username and password (bought, leaked, or brute-forced), they trigger repeated push notifications to the victim's phone — sometimes dozens in a row, sometimes at 2 a.m. Some victims approve one out of confusion or fatigue, especially if the attacker follows up with a spoofed IT-support call telling them to "approve it to fix the issue." This social-engineering variant — commonly called MFA fatigue or push bombing — has been used in several high-profile enterprise breaches and is explicitly flagged in CISA's phishing-resistant MFA guidance as a reason to move to number-matching or, better, to phishing-resistant methods entirely.
What "Phishing-Resistant" Actually Means
NIST Special Publication 800-63B defines phishing resistance as a property of the authentication protocol itself, not user vigilance. A phishing-resistant authenticator cryptographically verifies the origin — the actual domain — it is talking to before it will respond. If a user is tricked into visiting a lookalike domain, the authenticator simply refuses to authenticate: there is no code to steal and no session to relay, because the credential was never designed to work anywhere except the genuine site.
The current gold standard implementing this is the FIDO2/WebAuthn standard, maintained by the FIDO Alliance and the W3C. In practice it shows up in two forms:
- Passkeys — a FIDO2 credential stored on a phone, laptop, or password manager, unlocked by the device's own biometric or PIN, and synced (or not) depending on platform settings.
- Hardware security keys — physical USB/NFC/Bluetooth devices (FIDO2-certified) that hold the private key on dedicated hardware, never exposing it to the operating system or browser.
Relative Phishing Resistance by Method
Ranked qualitatively, from most phishable to most resistant, based on NIST 800-63B and FIDO Alliance guidance:
This is a relative ordering, not a measured statistic — no standards body publishes a precise "resistance percentage" for these methods. The direction is what matters: shared-secret codes sit at the bottom regardless of delivery channel, push approval improves only when paired with number matching, and FIDO2-based methods are the only category NIST classifies as resistant to verifier impersonation.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanComparing the Main MFA Options
| Method | How it works | Phishable via AiTM proxy | Vulnerable to SIM swap | Vulnerable to MFA fatigue | Typical use case today |
|---|---|---|---|---|---|
| SMS OTP | Code texted to phone, typed into site | Yes | Yes | No | Legacy default, banking OTP |
| Authenticator app (TOTP) | Time-based code from an app | Yes | No | No | Common SaaS second factor |
| Push notification | Approve/deny prompt on phone | Partially (fatigue attacks) | No | Yes | Enterprise SSO apps |
| Push with number matching | Approve prompt showing a code to match | Partially reduced | No | Reduced | Improved enterprise SSO |
| FIDO2 passkey | Device-bound cryptographic credential, biometric/PIN unlock | No | No | No | Modern consumer + enterprise logins |
| Hardware security key | Physical FIDO2 device, private key never leaves hardware | No | No | No | High-value admin, finance, developer accounts |
Migration Guidance for Indian Businesses
Moving an entire organization to phishing-resistant MFA overnight is unrealistic — most Indian SMBs run a mix of SaaS tools, legacy on-prem systems, and customer-facing logins that don't all support FIDO2 yet. A phased approach works better than an all-or-nothing mandate.
1. Inventory and rank accounts by blast radius. Start with systems that would cause the most damage if compromised: cloud admin consoles, domain registrar and DNS accounts, email/Workspace admin, code repositories, payment gateways, and any account with standing access to customer data. These get phishing-resistant MFA first, regardless of company size.
2. Enable FIDO2/passkey support wherever the provider already offers it. Most major identity providers, cloud platforms, and password managers support FIDO2 natively today — usually a settings toggle, not a project. Enable it for admins first, then extend to all staff.
3. Issue hardware security keys for the smallest, highest-risk group. For founders, IT admins, finance approvers, and anyone with wire-transfer or infrastructure access, a physical FIDO2 key removes even the "phone got compromised" failure mode.
4. Kill SMS OTP as a fallback, not just a primary. A common mistake is enabling passkeys but leaving SMS OTP as an account-recovery fallback — attackers simply target the weaker fallback path instead. Recovery flows need to be at least as strong as the primary factor.
5. Turn on number matching for any push-based MFA you can't replace yet. It's not phishing-resistant, but it raises the bar against blind MFA-fatigue approval and buys time during migration.
6. Train staff on the actual attack, not generic phishing advice. Most employees have never heard of an AiTM proxy or understand why typing a correct OTP into a fake site still compromises them. A short, specific explanation changes behavior more than a generic annual training module does.
Weak authentication rarely shows up as a single obvious flaw — it's usually a gap between what a security policy claims and what a real login flow actually enforces, including recovery paths, fallback factors, and session handling after login. This is exactly the kind of control that continuous vulnerability assessment and penetration testing is built to catch, because it tests the live authentication flow rather than a checklist. Bachao.AI runs automated VAPT that includes authentication and session-security checks as part of a continuous scan, and Dhisattva AI Pvt Ltd built the platform so Indian SMBs don't need an internal security team to find these gaps first. Organizations building out their DPDP Act compliance program can also review authentication controls as part of DPDP compliance readiness, since access control adequacy is directly assessed under the Act.
For more practical, India-specific security guidance, browse the Bachao.AI blog.