How to Test Two-Factor Authentication (2FA) Flow

2FA adds a second factor (something you have) to the password (something you know). It raises security significantly — also the likelihood of user friction. Testing 2FA well covers enrollment, authent

2FA adds a second factor (something you have) to the password (something you know). It raises security significantly — also the likelihood of user friction. Testing 2FA well covers enrollment, authentication, recovery, and backwards compatibility. This guide is the matrix.

Types of 2FA

1. TOTP (authenticator app) — Google Authenticator, Authy, 1Password
2. SMS — one-time code via text
3. Email — code via email
4. Push — approval on another device (Google prompts)
5. Hardware key — YubiKey, FIDO2 / WebAuthn
6. Backup codes — recovery if primary lost

Enrollment

TOTP

1. User sees QR code + manual entry string
2. User scans QR with authenticator app
3. User enters first code to confirm enrollment
4. Backup codes generated and shown / downloadable
5. Option to re-generate backup codes anytime

SMS / email

1. User enters phone / confirms email
2. Verification code sent
3. User enters code to confirm enrollment

Hardware key

1. Browser/app prompts for key insertion
2. User taps key to register
3. Key associated with account (public key registered)

Authentication

TOTP

1. After password, prompt for 6-digit code
2. Code accepted within 30s of generation
3. Clock skew tolerated (±30s / 1 period)
4. Wrong code → error, retry allowed
5. Rate limit on retries (prevent brute force)

SMS / email

1. Code sent on login
2. Code valid 5-10 minutes
3. Resend option
4. Rate limit

Push

1. Prompt on enrolled device
2. Approve / deny
3. Denial blocks login
4. Timeout (often 60s)
5. Expiration message clear

Hardware key

1. Tap key on browser/app prompt
2. Key responds quickly (<1s)
3. Wrong key → rejected
4. Cross-device (use key on phone for web login)

Recovery

Lost device / phone

1. Recovery code flow: user enters backup code
2. Backup code uses consume one code
3. Backup codes can regenerate after use
4. Account recovery via email / SMS as fallback
5. Identity verification for high-security accounts (ID upload)

Device reset

1. After factory reset, TOTP gone; user uses backup or recovery flow
2. Can disable 2FA with both factors (password + 2FA code)

Edge cases

1. Clock skew >30 seconds → code rejected; message clear
2. Multiple devices enrolled (user can have authenticator on phone + tablet)
3. Enrollment while logged in on another device → session preserved or invalidated per policy
4. SMS delivery failure → clear message, alternative flow
5. Email delivery delay → user waits, retries
6. Push notification missed / ignored → login times out
7. Hardware key broken → user falls back to backup
8. User on airplane mode during TOTP lookup → no internet needed for TOTP (local secret)
9. Travel to different timezone → TOTP still works (uses absolute time)

Security

1. 2FA secret (TOTP) encrypted at rest
2. Secret never shown after enrollment
3. Backup codes hashed server-side (like passwords)
4. Rate limit on 2FA attempts
5. Too many wrong attempts → account lock
6. Attempt log visible to user ("3 failed 2FA attempts from Chicago")
7. 2FA bypass via "trusted device" option, if offered, works correctly
8. Hardware key FIDO2 supported (passwordless potential)

Usability

1. Code input auto-focuses next digit (for 6-digit code)
2. Paste code from SMS works (auto-fill)
3. Paste split-up SMS ("Your code is 123456") extracts digits
4. Keyboard is numeric for code entry
5. Clear countdown until code expires
6. Resend button enables after timer expires

Accessibility

1. Code input accessible (keyboard, screen reader)
2. Error state announced
3. QR code has manual-entry alternative
4. Backup codes copyable / downloadable

Admin / account management

1. User can view enrolled methods
2. User can disable 2FA (with password confirmation)
3. User can change enrolled methods
4. Admin-forced 2FA for organization
5. 2FA-required feature gates (e.g., financial actions require 2FA re-verification)

Testing approach

Manual

• Full enrollment, authentication, recovery cycle
• Lost device scenario (with backup codes)
• Clock skew test (set device time ±5 minutes)
• Multi-device (TOTP on two authenticators)
• All methods (TOTP, SMS, email, push, key)
• Edge cases (airplane mode, expired code, rapid retries)

Automated

• TOTP via pyotp in tests
• Backend: validate secret rotation, secret invalidation
• End-to-end with test authenticator

import pyotp
def test_login_2fa(page, totp_secret):
    # login with password
    page.fill("#password", "correct-horse")
    page.click("text=Login")
    # prompt for code
    code = pyotp.TOTP(totp_secret).now()
    page.fill("#totp", code)
    page.click("text=Verify")
    expect(page.locator("#home")).to_be_visible()

How SUSA handles 2FA

SUSA accepts TOTP secret at run time and generates codes via pyotp:

susatest-agent test myapp.apk --username test@example.com --password ... --totp-secret JBSWY3DPEHPK3PXP

The adversarial persona stresses the retry limits and attempts bypass.

Common production bugs

1. Backup codes displayed but not regenerable — user cannot rotate if compromised
2. Rate limit too strict — honest user locked out from typos
3. Rate limit too lenient — brute-force viable
4. 2FA code valid for minutes, not 30 seconds — replay window
5. Push notification delay > timeout — user cannot approve in time

2FA is high-stakes UX. Test every flow, every method, every fallback. Users who fail here lose account access.