Multi Factor Authentication: WebAuthn, TOTP, and Beyond
Multi-factor authentication (MFA) requires users to provide two or more types of evidence before accessing an account: something they know (password), something they have (a device generating a code), and something they are (biometrics). TOTP (Time-based One-Time Passwords) is the most widely deployed second factor. WebAuthn is the modern standard that replaces TOTP with phishing-resistant hardware-backed authentication. Passkeys implement WebAuthn for consumer-friendly use. Each has different phishing resistance, implementation complexity, and user friction tradeoffs.
Written by Yashveer Singh, founder of Yashveer Labs.
What you need to know
- TOTP is widely deployed and provides meaningful protection against credential stuffing and password breaches. It is not phishing-resistant, but it blocks the majority of automated attacks.
- WebAuthn and passkeys are phishing-resistant by design. They are the correct direction for new MFA implementations in 2026.
- SMS-based OTP is the weakest MFA option and should not be the only second factor offered. SIM swapping attacks bypass it. TOTP or WebAuthn is the correct alternative.
- Enterprise customers increasingly require MFA enforcement as a condition of security questionnaire completion. Build MFA enforcement before the first enterprise deal closes.
- Auth providers (Clerk, Auth0, Supabase, WorkOS) handle TOTP and WebAuthn implementation. Building MFA from scratch is rarely justified.
The core argument
The MFA decision for B2B SaaS in 2026 is not whether to implement it but which method to prioritize and how to enforce it. The threat model has changed: password breaches from third-party services are so common that passwords alone are not a reasonable security baseline for any account that controls customer data or billing. Enterprise security questionnaires reflect this: they ask specifically about MFA support, enforcement policies, and whether admin accounts require MFA.
TOTP is the most broadly supported second factor because it works with every authenticator app (Google Authenticator, Authy, 1Password) and requires no hardware or browser support. The implementation via an auth library is straightforward, and user adoption is high for technical users who understand the value. The limitation is that TOTP codes can be phished in real time: an attacker who creates a convincing login phishing page can capture both the password and the TOTP code and use them immediately. This attack is less common against SaaS products with small attack surfaces but is a genuine concern for high-value accounts.
WebAuthn passkeys are the right direction for new MFA implementations. They require no code typing, authenticate with a biometric gesture, and are bound to the specific domain, making phishing impossible. The user experience is comparable to Face ID or Touch ID on a device: one tap or glance to authenticate. The implementation via a modern auth provider is handled automatically. The challenge is that not all users have passkey-compatible devices or understand the technology. The practical approach is to offer both TOTP and passkeys, allow users to register either or both, and recommend passkeys for new users while maintaining TOTP as a supported option for users on older devices or platforms.
Common mistakes
- Offering SMS OTP as the only MFA option. SMS OTP is better than no MFA but is the weakest option available. SIM swapping attacks bypass it. If SMS is offered, it should be presented as the fallback behind TOTP or WebAuthn, not the primary option.
- Not providing backup codes at MFA enrollment. A user who loses their authenticator device needs a recovery path. Backup codes generated at enrollment and stored securely by the user are the standard recovery mechanism. Without them, account lockout requires customer support involvement.
- Requiring MFA without adequate user notification. Turning on required MFA without a thirty-day notice period, in-app prompts, and email communication results in locked-out users and support tickets. Phase MFA enforcement with clear communication.
- Not enforcing MFA for admin roles while leaving it optional for standard users. The highest-risk accounts are admin accounts. If MFA enforcement is not universal, it must at least be required for accounts with admin or billing access.
- Building TOTP from scratch when an auth provider handles it. TOTP implementation involves secure secret storage, time-window validation, and backup code management. Auth providers like Clerk and Auth0 implement this correctly and maintain it. Custom implementation is unnecessary and introduces implementation risk.
Where to start
- Add TOTP support to the authentication flow using your current auth provider. Clerk, Auth0, and Supabase all have native MFA support. Enable TOTP for all accounts as an optional feature before making it required.
- Require MFA for all admin and billing roles immediately. These accounts have the highest value to attackers. Enforce MFA for privileged roles before enforcing it universally.
- Set a roadmap for WebAuthn passkey support. If your auth provider does not yet support passkeys, request it on their roadmap or evaluate providers that do. Plan to offer passkeys as an option alongside TOTP within the next two quarters.
Related reading
- JWT Best Practices in 2026: What Has Changed
- Mobile Authentication: Biometrics, Magic Links, and the Death of Passwords
- How to Sell to Enterprise Without a Full Compliance Stack
- OWASP Top 10 for SaaS Founders: What Actually Matters
Frequently asked
The work I take and why
I take work that compounds. I do not take work that is rework with extra steps. Yashveer Singh, founder of Yashveer Labs. If the topic on this page is what you are dealing with, the question is not whether it can be solved. It can. The question is whether you want to solve it once or four times. I am the person who solves it once.
Posts that line up with this one.
- Security, Auth, and Compliance
How to Sell to Enterprise Without a Full Compliance Stack
You do not need SOC 2 Type II and HIPAA certification before your first enterprise conversation. Here is what you actually need and how to close the deals while you build toward the rest.
- Security, Auth, and Compliance
Incident Response for Startups: A Playbook
A startup does not need an enterprise incident response program. It needs a simple, documented process that prevents the chaos that happens when something breaks at 2am and nobody knows who does what.
- Security, Auth, and Compliance
Insecure Direct Object References: The Bug Founders Underestimate
IDOR vulnerabilities let attackers access other users' data by changing an ID in a URL or API request. They are simple to introduce and expensive to miss. Here is how to find and prevent them.
- Security, Auth, and Compliance
ISO 27001 for Engineering Founders: A Practical Reading
ISO 27001 looks like a compliance bureaucracy but reads like an operational checklist for running a secure organization. Here is what engineering founders actually need to understand before starting the certification process.