MFA and 2FA Test Cases That Prove the Challenge Belongs to the Right User and Session

The Minimum MFA Smoke Test

When release time is limited, begin with these ten cases.

The smoke set verifies the transaction boundary. It does not replace provider integration tests, protocol conformance, penetration testing or full session-management coverage.

Define the MFA Acceptance Contract First

The phrase “MFA succeeded” is too vague to produce reliable tests. Define the contract before writing cases.

Example MFA acceptance contract

Model MFA as a Challenge Lifecycle

MFA is a stateful transaction. Model its transitions before selecting test data.

1. Primary authentication evaluated
2. MFA required
3. Challenge issued
4. Challenge delivered or presented
5. Proof submitted
6. Proof validated
7. Challenge consumed
8. Intended session or action elevated
9. Protected state reached

Alternative outcomes

• Challenge denied
• Challenge expired
• Challenge superseded
• Challenge rate-limited
• Factor unavailable
• Recovery required
• Factor replacement pending

Prohibited transitions

MFA Trigger and Pre-Challenge State Test Cases

OWASP recommends reviewing every authentication method and checking that the second stage cannot be skipped through force-browsing or direct API requests.

Enrollment and Factor Binding Test Cases

Challenge Issuance and Delivery Test Cases

OTP and TOTP Verification Test Cases

The validity window must be an explicit system policy. RFC 6238 recommends a 30-second TOTP step as a security/usability balance and requires a verifier not to accept a successfully used OTP again. NIST also requires one-time acceptance during the validity period and rate limiting for short authentication secrets.

Push Approval and Transaction-Binding Test Cases

Backup Code and Trusted-Device Test Cases

Recovery and Factor-Replacement Test Cases

OWASP treats MFA recovery and factor replacement as high-risk flows. Recovery should not become an easier bypass, and changing a factor should require suitable reauthentication rather than relying only on an active session.

Step-Up Authentication and Session-Elevation Test Cases

The Most Important MFA Failure Patterns

The second step is visible but not enforced

A browser may show an MFA screen while a direct protected URL, API endpoint, alternative login flow or backend route accepts the pre-MFA session. Verify enforcement at the resource boundary, not only the visible navigation.

A code for User A verifies User B

This is a challenge-binding failure. Record the account and challenge identifiers before submission and assert the final identity after verification.

Resend creates several valid challenges

Multiple simultaneously valid proofs enlarge the attack and race-condition surface. Define whether resend supersedes the old challenge or whether a bounded set remains valid, then test both orders.

The proof is accepted twice

A one-time proof must be consumed atomically. Parallel or repeated submissions should not elevate two sessions or operations.

The session is elevated before verification

Primary credentials may create a restricted transaction, but protected routes and privileged APIs must still recognise that MFA is unresolved.

A trusted-device cookie survives a security change

Remembered-browser state can become a durable bypass after password changes, factor replacement, device revocation or suspected compromise unless explicit invalidation rules exist.

Recovery is weaker than the factor it replaces

A simple email link, generic security question or support shortcut can nullify stronger MFA. Test recovery as an authentication flow, not as an account-settings convenience.

Step-up verification elevates the wrong action or session

Successful verification for one transfer, tenant, browser tab or admin operation must not authorise unrelated actions.

Choose the Right MFA Test Environment

The correct automation method depends on what the test needs to prove. Do not use one bypass for every case.

Do not build a hidden MFA bypass. Use explicit test-only providers, isolated fixtures or prepared states that cannot exist in production. A query parameter, magic header, hard-coded account or undocumented endpoint that skips MFA is a security defect, not a testing strategy.

What Each Testing Layer Can Prove

Automating MFA and 2FA Test Cases

Separate the reusable browser journey from the factor source and expected security state.

1. Open {{AUTH_ENTRY_URL}}
2. Complete primary authentication as {{USER}}
3. Assert {{MFA_REQUIRED}}
4. Assert {{PRE_MFA_ACCESS}}
5. Capture {{CHALLENGE_ID}}
6. Acquire proof from {{FACTOR_SOURCE}}
7. Submit {{FACTOR_PROOF}}
8. Assert {{MFA_RESULT}}
9. Assert {{CHALLENGE_STATE}}
10. Assert {{SESSION_ASSURANCE}}
11. Assert {{PROTECTED_RESULT}}

Positive dataset

{
  "name": "current_totp_elevates_only_intended_session",
  "user": "[email protected]",
  "factor": "totp",
  "challengeContext": {
    "tenant": "test-workspace",
    "operation": "login"
  },
  "proof": {
    "source": "seeded-totp",
    "timeOffsetSeconds": 0
  },
  "expected": {
    "mfaResult": "accepted",
    "challengeState": "consumed",
    "sessionAssurance": "mfa-complete",
    "protectedRouteAccessible": true
  }
}

Replay dataset

{
  "name": "consumed_totp_cannot_elevate_second_session",
  "user": "[email protected]",
  "factor": "totp",
  "proof": {
    "source": "previously-consumed-proof"
  },
  "expected": {
    "mfaResult": "rejected",
    "secondSessionElevated": false,
    "protectedRouteAccessible": false
  }
}

Cross-user binding dataset

{
  "name": "user_a_code_rejected_for_user_b_challenge",
  "challengeUser": "[email protected]",
  "proofOwner": "[email protected]",
  "expected": {
    "mfaResult": "rejected",
    "authenticatedIdentity": null,
    "challengeState": "pending-or-failed"
  }
}

Use scenario names that state the business and security condition. Avoid names such as mfa_test_3, otp_negative_7 or 2fa_case.

What Browser Automation Should Not Claim

• TOTP or OTP secrets are generated with sufficient entropy and stored securely
• the SMS carrier, email provider or push infrastructure is secure against every attack
• hardware-backed private keys cannot be extracted
• biometric false-accept and false-reject rates meet platform requirements
• WebAuthn attestation and authenticator conformance are correct
• all MFA bypass paths are absent across the complete architecture
• rate limiting remains effective under distributed production-scale attacks
• support agents follow identity-recovery procedures correctly
• trusted-device tokens cannot be forged
• all phishing and social-engineering attacks are prevented

Browser automation remains valuable because it can prove the user-visible and session-visible transaction: the correct challenge appeared, the selected proof produced the expected decision, and only the intended protected state became available.

MFA Testing Checklist

• every intended authentication entry point enforces MFA consistently
• primary credentials alone do not create fully protected access
• the challenge is bound to the intended user, session, factor and operation
• enrollment is inactive until the first proof confirms possession
• partial or cancelled enrollment does not leave a usable factor
• delivery destinations are correct and masked
• resend and concurrent challenge rules are explicit and tested
• new proof generation does not silently reset failed-attempt policy
• valid OTP and TOTP values are accepted within the configured window
• leading zeroes and exact formatting are preserved
• expired, out-of-window, malformed and incorrect proofs are rejected
• successful proof is consumed and cannot be replayed
• cross-user and cross-session proof is rejected
• parallel submissions cannot create two successful consumptions
• push deny, timeout, stale prompt and notification-spam cases are covered
• transaction details or number matching correspond to the intended action
• backup codes are single-use and old sets follow the regeneration policy
• trusted-device state is account-specific, expires and can be revoked
• recovery is not weaker than the MFA control it replaces
• factor replacement requires suitable reauthentication and creates an audit event
• the old factor stops working after replacement
• administrator reset follows explicit revocation and notification rules
• step-up success elevates only the intended session, tenant or operation
• failed or cancelled step-up leaves the protected action blocked
• browser, API, provider, identity and session evidence are used where appropriate
• test fixtures are isolated from production and do not create a hidden bypass

Final acceptance criterion. Do not accept: “The correct OTP opened the dashboard.” Accept: “The intended factor satisfied the intended challenge once, invalid and cross-context proof remained outside the protected state, and only the intended session or action received elevated access.”

Frequently Asked Questions

What are the most important MFA test cases?

Verify consistent triggering, pre-MFA access restrictions, account and session binding, valid proof, expiry, replay rejection, cross-user rejection, recovery strength, trusted-device revocation and correct session elevation.

What is the difference between MFA and 2FA testing?

2FA uses exactly two different factors. MFA is the broader category and may use two or more factors. One page can cover both search intents when the tested lifecycle and expected evidence are the same.

How should OTP expiry and replay be tested?

Control issue time and server time, test the configured boundary and drift window, consume one valid proof, then repeat it in the same and another transaction. The duplicate must not elevate access.

Can MFA testing be automated?

Yes. TOTP can be generated from a test secret, email/SMS can use controlled providers, and challenge APIs can expose test fixtures. Real-device or manual runs are still needed for some push, biometric and hardware-backed paths.

Should automated tests bypass MFA?

Unrelated authenticated tests may reuse prepared post-MFA state. Tests of MFA itself must exercise the real application decision. Never create a hidden production-capable bypass to make automation easier.

Does this guide completely test passkeys and hardware keys?

No. It covers their place in the MFA lifecycle and browser-visible outcomes, but complete WebAuthn, authenticator and hardware conformance requires dedicated protocol and device testing.

Automate the Repeatable MFA Journey

WrightTest lets teams record the browser part of an MFA flow, replace fixed accounts and proofs with named datasets, run scenarios independently, and inspect screenshots, step results, errors and Playwright traces.

1. Which user started the transaction
2. Which challenge appeared
3. Which factor proof was supplied
4. Whether the proof was accepted or rejected
5. Whether the challenge was consumed
6. Which session or action was elevated
7. Where a failed journey stopped

The browser checks can be exported to Playwright .spec.ts files when they need to move into an existing repository or CI pipeline.

Use controlled factor sources, provider sandboxes or explicit manual checkpoints for the parts that a browser cannot safely reproduce. Combine browser results with API, provider, factor-store, session and security evidence for the complete MFA contract.

Continue with Authentication Testing

MFA is one part of the complete authentication lifecycle. Use the Authentication Testing guide to plan coverage across primary login, additional factors, session management and logout.