Multi-Factor Authentication (MFA) requires a second proof of identity beyond a password — something you have, like a phone or hardware key, or something you are, like a fingerprint — before an account grants access. Indian businesses still get MFA wrong in three repeatable ways: relying on SMS OTP as the only second factor, leaving admin panels and cloud consoles completely unprotected, and treating MFA as a one-time checkbox instead of a control that needs periodic hardening. Password-only authentication fails because credentials get reused, phished through fake login pages, and traded in bulk on criminal marketplaces — one leaked password is often enough for an attacker to walk into a business email account, a cloud console, or a customer database. This guide covers how MFA methods differ in strength, where Indian SMBs consistently misconfigure authentication, and how phishing-resistant standards like FIDO2/WebAuthn close the gaps SMS OTP leaves open.
Why Password-Only Authentication Fails
A password is a single, static secret. Once it leaks — through a phishing page, a breached third-party site where an employee reused it, a keylogger, or a brute-force credential-stuffing attempt — anyone holding that password has the same access as the legitimate user, until it's changed. Attackers don't need to be sophisticated: automated tools test millions of leaked username-password pairs against business login pages every day, betting on password reuse across services.
MFA breaks this single point of failure by requiring a second, independent factor a remote attacker typically doesn't possess even after stealing the password. NIST's Digital Identity Guidelines (SP 800-63B) formalize this model, defining authenticator categories and discouraging SMS-delivered one-time codes as a standalone factor beyond low-risk use cases — a distinction most Indian businesses haven't caught up to yet.
What Multi-Factor Authentication Actually Means: TOTP, Push, Hardware Keys, and SMS OTP
"MFA" is not one control — it's a category covering methods with very different real-world resistance to attack:
SMS OTP. A one-time numeric code sent by text message. It's better than nothing, but it depends on the security of the telecom network and handset, not just the account. SIM-swap fraud — where an attacker social-engineers a telecom operator or retail SIM agent into porting a victim's number onto an attacker-controlled SIM — defeats SMS OTP completely, and India has seen this fraud pattern used repeatedly against banking and business accounts.
TOTP authenticator apps. Time-based One-Time Password apps (Google Authenticator, Microsoft Authenticator, and similar) generate a six-digit code locally on the device every 30 seconds from a shared secret set up once. TOTP doesn't depend on telecom infrastructure, so it's immune to SIM swap, but a user can still be tricked into typing the code into a real-time phishing proxy that relays it to the attacker within the same window.
Push notification approval. The login attempt sends an "Approve / Deny" prompt to a registered device instead of a code to type. It's convenient and removes typo errors, but it introduces "MFA fatigue" risk — an attacker who already has a valid password can spam approval requests until a tired employee taps Approve.
Hardware security keys and passkeys (FIDO2/WebAuthn). A physical USB/NFC token or a platform-bound passkey performs cryptographic origin-binding: the challenge is tied to the exact domain the user is logging into, so a phishing site on a look-alike domain cannot obtain a valid response even if the user is fooled into trying. This is the category OWASP and CISA both point to as the practical ceiling for phishing resistance today.
The diagram below traces a single login attempt through these branches — showing exactly where SMS OTP still lets an attacker through via SIM swap, and where a FIDO2 key stops the same attacker cold.
Common Indian SMB Mistakes
Most Indian SMB authentication gaps fall into a small, repeatable set of patterns — none of them require a sophisticated attacker to exploit.
SMS-only OTP as the sole second factor. It's the default many SaaS and banking-adjacent tools ship with, so businesses accept it and stop there, even for high-privilege accounts. It's an improvement over no MFA, but it's the weakest tier available, not the finish line.
No MFA on admin panels or cloud consoles. Founders and IT staff routinely enable MFA for customer-facing logins while leaving AWS root accounts, GitHub organization owners, Google Workspace admin consoles, and CRM admin panels protected by password alone — precisely the accounts an attacker wants most, guarded the least.
Shared or generic admin logins. A single shared "admin@company" account used by several staff members can't cleanly support per-person MFA, so it often ends up with none — and no one can tell afterward who actually logged in.
Treating MFA setup as a one-time IT task. MFA gets configured during onboarding and never revisited: former employees' registered devices stay active, backup codes are never rotated, and no one audits which accounts still lack a second factor months later.
WhatsApp or email-based "OTP" used as if it were MFA. A code sent to the same inbox or device already logged into an account isn't an independent factor — if that device is compromised, the "second factor" is compromised in the same breach.
| MFA Method | How It Works | Phishing Resistant | SIM Swap Risk | Best Used For |
|---|---|---|---|---|
| SMS OTP | Code sent via text message | No | High | Legacy fallback only, never primary |
| TOTP App | Time-based code generated on device | Partial | None | General staff logins |
| Push Notification | Approve/Deny prompt on registered phone | Partial | Low | Convenience-first rollouts with fatigue controls |
| Hardware Security Key (FIDO2) | USB/NFC token, origin-bound cryptographic challenge | Yes | None | Admin, cloud console, and privileged accounts |
| Passkey (FIDO2/WebAuthn) | Platform-bound cryptographic credential | Yes | None | Workforce and customer logins at scale |
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanPhishing-Resistant MFA: FIDO2 and WebAuthn
FIDO2 and its web-facing standard WebAuthn solve the specific weakness every code-based method shares: the user can be tricked into typing or approving something in the wrong place. A FIDO2 credential — whether a physical hardware key or a device-bound passkey — cryptographically signs a challenge that includes the exact origin the request came from. A look-alike phishing domain cannot produce a valid signed response, even with a perfect visual clone of the real login page.
CISA's guidance explicitly recommends phishing-resistant MFA — FIDO/WebAuthn-based authentication — as the standard organizations should move toward for accounts that matter, precisely because code-based methods (SMS, TOTP, push) remain vulnerable to real-time phishing proxies that relay a valid code or approval within seconds of interception.
The chart below shows the relative phishing-resistance of each MFA method on a simple illustrative scale — not an adoption percentage, but a way to compare how much real protection each method buys against a motivated attacker.
Rollout Strategy for Indian Organizations
A phased rollout protects the highest-risk accounts fastest without stalling on a company-wide project:
- Inventory every login surface first. List every admin panel, cloud console, SaaS tool, and email account your business uses, and mark which ones currently have zero MFA. This list is usually longer than founders expect.
- Protect privileged accounts with phishing-resistant MFA first. Cloud root/admin accounts, source control organization owners, domain registrar logins, and payment/finance tools should move to FIDO2 hardware keys or passkeys before anything else.
- Move general staff off SMS OTP onto TOTP apps or passkeys. TOTP apps are free, work offline, and remove SIM-swap exposure entirely — a low-friction upgrade most SaaS tools already support.
- Eliminate shared admin logins. Move every shared account to individual, named logins so MFA and audit logs can actually be tied to a person.
- Set an MFA-enforcement policy, not just an option. Where the platform supports it, make MFA mandatory rather than opt-in — opt-in MFA consistently under-enrolls in practice.
- Review and rotate quarterly. Revoke MFA devices for offboarded staff immediately, and audit which accounts still lack a second factor every quarter.
- Document the control for compliance. Under India's DPDP Act, demonstrating reasonable security safeguards around personal data matters during incident response and audits — MFA is a foundational safeguard reviewers expect to see. Teams tracking these obligations can review DPDP compliance requirements alongside their rollout.
Where MFA Fits Into a Broader Security Program
MFA closes one specific door — credential theft leading to account takeover — but it doesn't tell you whether your applications, APIs, or infrastructure have exploitable weaknesses an attacker could use instead of logging in at all. That's a separate discipline: vulnerability assessment and penetration testing across your external attack surface. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated VAPT scans that flag missing or weak authentication controls — including MFA gaps on exposed admin interfaces — alongside broader application and infrastructure findings, so teams see both classes of risk in one place. If you want a current picture of where your authentication and external systems stand, a free VAPT scan is a fast way to start. More practical guides are available on our blog.
Further reading: CISA's guidance on phishing-resistant MFA, NIST's Digital Identity Guidelines (SP 800-63B), and the OWASP Multifactor Authentication Cheat Sheet cover the technical detail behind these recommendations.