Two factor authentication is no longer optional. Users expect it, compliance frameworks require it, and attackers have proven repeatedly that passwords alone are not enough. The question is not whether to add 2FA to your product. The question is how to do it without creating a terrible user experience that drives abandonment.
We have implemented 2FA across dozens of products, from early stage startups to platforms with hundreds of thousands of users. Here is what we have learned about doing it right.
Why 2FA Is Non Negotiable in 2026
Over 80% of data breaches involve compromised credentials. Phishing attacks are more sophisticated than ever, password reuse is rampant, and credential stuffing tools are freely available. A single compromised account can expose your entire user base if that account belongs to an admin.
If your product handles any form of sensitive data, payments, personal information, health records, or business documents, 2FA is a baseline security requirement. Frameworks like SOC 2, HIPAA, and PCI DSS either require or strongly recommend it. Even if you are not pursuing formal compliance today, building 2FA in from the start is dramatically cheaper than retrofitting it later.
For a broader look at security requirements before you ship, check out our web app security checklist.
The Four Main 2FA Methods
TOTP (Time Based One Time Passwords)
This is the authenticator app approach. Users scan a QR code with Google Authenticator, Authy, or 1Password, and the app generates a six digit code every 30 seconds. TOTP is the gold standard for most products. It is free to implement, does not depend on a third party service, and works offline.
Implementation involves generating a shared secret, encoding it as a QR code, and validating the time based codes on your server. The critical details: allow a one period clock skew (plus or minus 30 seconds) to account for time drift, rate limit verification attempts to prevent brute forcing, and never store the shared secret in plain text.
SMS Codes
Send a six digit code via text message. Users are familiar with this flow, but SMS has well documented weaknesses. SIM swapping attacks let attackers intercept messages, SS7 vulnerabilities allow network level interception, and delivery reliability varies by carrier and country.
We recommend SMS as a fallback, not a primary method. It is better than nothing, and for some user bases (less technical audiences, regions with low smartphone penetration), it may be the only practical option. If you do use SMS, pair it with rate limiting and short expiration windows (5 minutes maximum).
Email Codes
Similar to SMS but delivered via email. Slightly more secure than SMS (email accounts are harder to hijack than phone numbers), but introduces its own issues: email delivery delays, spam filters eating codes, and the fact that if someone has compromised the user's email, they have compromised this factor too.
Email codes work well as a secondary recovery option. We do not recommend them as the primary 2FA method for security focused products.
Passkeys and WebAuthn
The newest option and the future of authentication. Passkeys use public key cryptography tied to a device biometric (fingerprint, face scan) or hardware security key. They are phishing resistant by design because the cryptographic challenge is bound to the specific domain.
Passkey adoption is growing fast, but support is still inconsistent across devices and browsers. For most products, we recommend offering passkeys as an option alongside TOTP, rather than requiring them exclusively.
Implementation Architecture
The Database Layer
At minimum, you need to store: the 2FA method type, the encrypted shared secret (for TOTP), backup codes (hashed, not plain text), whether 2FA is enabled for the account, and a timestamp of when it was last verified.
Backup codes are critical. Generate 8 to 10 single use recovery codes when the user enables 2FA. Hash them like passwords. Display them exactly once and instruct the user to store them safely. Without backup codes, users who lose their phone are permanently locked out, which creates support nightmares.
The Authentication Flow
The standard flow works like this: user enters email and password, server validates credentials, server checks if 2FA is enabled, if yes, server issues a short lived partial session token, user enters their 2FA code, server validates the code and upgrades to a full session.
The partial session token is important. It should expire in 5 minutes, should not grant access to any protected resources, and should only be valid for completing the 2FA step. Do not make the mistake of authenticating the user fully and then asking for the 2FA code as an afterthought. That defeats the purpose.
Enforcement Strategy
Decide early whether 2FA is optional, recommended, or required. Most products start with optional, recommend it via in app prompts, and eventually require it for privileged roles (admins, users with billing access). Some products, particularly B2B SaaS, let organization admins enforce 2FA for their entire team.
Whatever you choose, make the enrollment flow dead simple. Show the QR code, provide clear instructions, verify the first code before saving, and display backup codes prominently. The difference between 20% adoption and 80% adoption is entirely in the UX.
Common Mistakes We See
Storing TOTP secrets in plain text. If your database is compromised, attackers can generate valid 2FA codes. Encrypt secrets at rest using a key stored outside the database.
No rate limiting on code verification. A six digit code has one million possible values. Without rate limiting, an attacker can brute force it in minutes. Lock the account after 5 failed attempts and require a cooldown period.
Skipping 2FA for API access. If your product has an API, you need API tokens or OAuth flows that respect the user's 2FA status. Issuing long lived API keys that bypass 2FA creates a backdoor.
Not handling the lost device scenario. If a user loses their phone and you have no recovery flow, you will spend hours on support tickets manually verifying identity. Backup codes, recovery email flows, and admin override capabilities are all necessary. Plan for this on day one.
Treating 2FA as an afterthought in your system architecture. 2FA touches authentication, session management, API security, admin tooling, and customer support workflows. It is not a feature you bolt on in a sprint. Architect it as a core part of your auth system.
TOTP Implementation Checklist
Here is the practical checklist we follow when adding TOTP to a product:
- Generate a 160 bit shared secret using a cryptographically secure random number generator
- Encode the secret as a QR code using the otpauth:// URI scheme
- Require the user to verify a code before enabling 2FA (proves they scanned correctly)
- Store the secret encrypted at rest, not in plain text
- Generate and display 8 to 10 hashed backup codes
- Allow plus or minus one period clock skew (30 seconds each direction)
- Rate limit verification to 5 attempts per 5 minutes
- Log all 2FA events (enabled, disabled, verified, failed) for audit trails
- Add admin tooling to reset 2FA for locked out users with identity verification
- Test the entire flow on both web and mobile if you support both platforms
For mobile specific considerations, our mobile app security guide covers additional concerns like secure storage of tokens on device.
What This Costs to Build
For a straightforward TOTP implementation on an existing auth system, expect 2 to 3 weeks of engineering time. That covers the enrollment flow, verification flow, backup codes, admin tooling, and testing. SMS adds another week for carrier integration and delivery monitoring. Passkeys add 1 to 2 weeks depending on the platforms you support.
If you are building a new product, this is one of the areas where getting it right from the start saves significant money. Retrofitting 2FA into an existing system with established session management, API patterns, and mobile apps can easily take twice as long.
We build authentication systems as part of our full stack development engagements, and we strongly recommend including 2FA in the initial scope rather than treating it as a future enhancement.
Moving Forward
Two factor authentication is a solved problem from a technical perspective. The challenge is implementation quality, covering edge cases, building recovery flows, and creating an enrollment experience that users will actually complete. The products that get this right see adoption rates above 60% without making it mandatory.
If you are building a product that handles sensitive data and need 2FA done right from the start, reach out to our team. We will scope it properly and build it into your authentication architecture from day one.