PRD Template for Two-Factor Auth
A complete product requirements template for building two-factor authentication. Pre-filled with examples for TOTP, passkeys, backup codes, enrollment flows, and admin enforcement.
What makes 2FA PRDs different
Two-factor authentication sits at the intersection of security and usability. Every security improvement (stronger verification) comes with a usability cost (more friction at login). A good 2FA PRD finds the right balance for your users — strong enough to prevent account takeovers, smooth enough that users do not disable it.
The most critical part of a 2FA PRD is not the verification flow — it is the recovery flow. What happens when a user loses their phone? If the answer is "contact support and wait 3 days," many users will never enable 2FA in the first place. If the answer is "reset via email link," you have undermined the security of the second factor. The template below addresses recovery with a three-tier approach that balances security with accessibility.
The template covers the full 2FA lifecycle: enrollment, daily use, recovery, admin enforcement, and the technical implementation details that affect both security and user experience.
Two-Factor Auth PRD template
Eight sections covering every aspect of two-factor authentication.
Problem Statement
Passwords alone are insufficient for account security. Credential stuffing attacks (using leaked passwords from other breaches) are the most common attack vector for SaaS applications. Two-factor authentication (2FA) adds a second verification step that stops 99.9% of automated attacks.
Example: "In the past 6 months, we detected 340 credential stuffing attempts against our login endpoint, 12 of which succeeded because the user reused a password from a breached service. This resulted in unauthorized access to 12 customer accounts, 4 data exfiltration incidents, and 2 customers churning due to security concerns. Our enterprise security questionnaire asks whether we support 2FA — we currently do not, which has been flagged in 8 of our last 10 enterprise security reviews."
Tips
- Document credential stuffing attempts and successful account takeovers
- Count enterprise security reviews that flagged missing 2FA
- Survey users about their willingness to enable 2FA
- Analyze competitor 2FA support as market expectation
Goals and Objectives
2FA goals must balance security (preventing unauthorized access) with usability (not creating excessive friction for legitimate users).
Example: "Primary: Offer 2FA via TOTP authenticator app and passkeys. Security: Zero successful account takeovers for accounts with 2FA enabled. Adoption: 60% of active users enable 2FA within 6 months (20% through voluntary enrollment, 40% through admin enforcement). UX: 2FA adds no more than 10 seconds to the login flow. Enterprise: Admins can enforce 2FA for their entire organization."
Tips
- Set adoption targets with separate goals for voluntary and admin-enforced enrollment
- Include a zero-takeover target for 2FA-enabled accounts
- Define UX targets: how much friction does 2FA add to login
- Include admin enforcement as a requirement, not just optional enrollment
User Stories
2FA user stories span enrollment (setting up 2FA), daily use (logging in with 2FA), recovery (lost device), and admin management (enforcing 2FA for the organization).
Example: "As a user, I want to set up 2FA using my authenticator app (Google Authenticator, Authy, 1Password) so that my account is protected even if my password is compromised. Acceptance criteria: the setup flow shows a QR code I can scan with any TOTP-compatible app; I must enter a code to verify the setup works before it is enabled; the system provides 10 backup codes for recovery; the entire setup takes under 2 minutes."
Tips
- Write stories for enrollment, daily login, device loss/recovery, and disabling 2FA
- Include an admin story: "As an admin, I want to require 2FA for all users in my organization"
- Cover the backup codes story: generating, storing, and using recovery codes
- Add a passkey story for the latest passwordless authentication standard
Functional Requirements
2FA requirements must specify supported methods, enrollment flow, verification flow, recovery mechanisms, and admin enforcement. The recovery flow is the most critical — a user who loses their 2FA device and cannot recover their account will churn.
Example: "FR-1: The system must support TOTP (RFC 6238) via any authenticator app that generates 6-digit codes with a 30-second window. FR-2: The system must support passkeys (WebAuthn) as a 2FA method. FR-3: On enrollment, the system must generate 10 backup recovery codes. FR-4: Each backup code is single-use. FR-5: Admins must be able to enforce 2FA for their organization with a grace period (7 days to enroll). FR-6: Admins must be able to reset 2FA for a user who has lost their device (after identity verification)."
Tips
- Support TOTP as the primary method — it works with all authenticator apps
- Include passkeys as a modern alternative to TOTP
- Generate backup codes during enrollment and make them downloadable
- Define admin controls: enforcement, grace periods, and user 2FA reset
Non-Functional Requirements
2FA verification must be fast (users do it at every login) and reliable (false rejections lock users out). The TOTP implementation must account for clock skew between client and server.
Example: "NFR-1: TOTP verification must accept codes within a 1-step time window (previous, current, and next 30-second period) to account for clock skew. NFR-2: 2FA verification must add no more than 500ms to login latency. NFR-3: TOTP secrets must be encrypted at rest with a key separate from the main database encryption key. NFR-4: Backup codes must be hashed (bcrypt) — never stored in plaintext. NFR-5: Rate limiting must be applied to 2FA verification: 5 failed attempts trigger a 15-minute lockout."
Tips
- Accept TOTP codes within a 1-step window to handle clock skew
- Encrypt TOTP secrets at rest with dedicated key management
- Hash backup codes — they are equivalent to passwords
- Rate limit 2FA verification to prevent brute-force attacks on 6-digit codes
Success Metrics
2FA success is measured by adoption (percentage of users protected), security (account takeover reduction), and usability (users can still log in without friction).
Example: "Metric 1: 2FA adoption rate. Target: 60% of active users within 6 months. Metric 2: Account takeover incidents for 2FA-enabled accounts. Target: 0. Metric 3: 2FA-related support tickets (locked out, cannot verify). Target: under 10/month. Metric 4: Average login time with 2FA. Target: under 10 seconds added. Metric 5: Backup code usage rate (indicator of device loss). Monitor, no target."
Tips
- Track adoption rate as percentage of active users with 2FA enabled
- Monitor account takeover attempts on 2FA vs. non-2FA accounts
- Track 2FA lockout support tickets as a usability indicator
- Monitor backup code usage to understand device loss patterns
Technical Considerations
2FA implementation involves TOTP secret management, WebAuthn/passkey support, backup code generation and hashing, and session management that distinguishes between password-authenticated and fully-verified sessions.
Example: "TOTP implementation uses the TOTP algorithm (RFC 6238) with SHA-1, 6-digit codes, and a 30-second step. Secrets are generated as 160-bit random values, encoded as base32 for QR code display. Secrets are encrypted at rest using AES-256-GCM with keys managed via AWS KMS. Passkey support uses the WebAuthn API with the platform authenticator (Touch ID, Windows Hello) as the default. After password verification, the session is marked as 'pending_2fa' — API access is restricted until the second factor is verified."
Tips
- Use the standard TOTP algorithm (RFC 6238) for broad authenticator app compatibility
- Implement WebAuthn for passkey support — the API is well-documented and browser support is broad
- Use a two-phase session: password-verified but 2FA-pending has restricted access
- Store TOTP secrets encrypted with a dedicated key, separate from database encryption
Risks and Mitigations
2FA risks include user lockout (losing the 2FA device with no recovery), adoption resistance (users finding it inconvenient), and implementation bugs (accepting invalid codes).
Example: "Risk: A user loses their phone and has not saved their backup codes, permanently losing access to their account. Likelihood: Medium. Impact: Critical (account inaccessible). Mitigation: Require users to download backup codes during enrollment (gate 2FA enablement on backup code acknowledgment). Offer admin-initiated 2FA reset with identity verification. Risk: Clock skew causes valid TOTP codes to be rejected. Likelihood: Medium. Impact: Medium. Mitigation: Accept codes within a 1-step time window (90 seconds total)."
Tips
- Force backup code download during enrollment to prevent lockouts
- Provide admin 2FA reset with identity verification for account recovery
- Test TOTP with deliberate clock skew to verify the acceptance window
- Include a migration plan for existing users when 2FA enforcement is enabled
Related templates
Frequently asked questions
Generate your 2FA PRD from real data
Connect your security logs and codebase. Vantage generates a 2FA PRD with actual attack data and requirements mapped to your auth stack.
Free to start. No credit card required.