Testing MFA factors and edge cases
MFA paths that run rarely, such as recovery, factor removal and clock drift, are where a locked-out user or an attacker finds the gaps.
Research desk, cybersecurityqavendors.com. Published 2026-11-11.
Short answer
Test each factor's normal path, then its edges: TOTP codes at the limits of the drift window, reuse of a code already accepted, push approvals that arrive late or repeatedly, enrollment and recovery, lockout, step-up prompts and factor removal. Ask a QA vendor which of these cases its past identity work automated and how it controlled time and devices in tests.
TOTP codes, drift and replay
MFA in an IAM1 product adds a second check after the password. A TOTP code is derived from a shared secret and the current time step, and the server accepts a small window of steps around its own clock to allow for drift on the user's device.
Submit a code from each step inside the configured window, and from the first step outside it on each side. The outside codes must be refused. Run the same cases with the server clock moved, not only the device clock, because a server with a drifting clock refuses valid codes for every user.
Replay tests submit a code that was just accepted. A second use within the same window must be refused, from the same session, from another browser and as two parallel requests sent at the same moment. The parallel case catches a race between checking a code and recording it as used.
Automate TOTP by giving the test the shared secret and a clock it controls, so it generates codes itself. Do not relax validation in a test build to make automation easier, because the tests then cover a different product.
Push approvals
Test approval, denial, expiry and a late approval on an enrolled device. Expiry means no answer until the request times out. The late approval must not complete the login.
Push fatigue is the case where a user receives repeated prompts until one is approved by mistake. Test the product's limit on prompts per period, any number matching or sign-in context shown on the device, and that each denied prompt appears in the admin log.
Test push with the device offline, with the app reinstalled and with the user enrolled on two devices. Record which device receives the prompt and whether an approval on one cancels the prompt on the other.
Enrollment, recovery and removal
- Enroll. Enroll each factor type from a fresh account, including security keys and platform credentials for passwordless sign-in, then abandon an enrollment halfway and confirm the half-registered factor cannot be used. For passwordless credentials, register two for one user, remove one and confirm that only the other still signs in.
- Add a second factor. Require a current factor before another is added, so a stolen password alone cannot register an attacker's device.
- Recover. Use each recovery path: backup codes, an admin reset and any self-service flow, including for a user whose only factors are passwordless. Confirm each backup code works once and that a reset invalidates the old factors.
- Remove a factor. Remove a factor from the user settings and from the admin console. Confirm it stops working at once in every open session and that removal asks for re-authentication.
- Remove the last factor. Record what the product does when a user removes the only factor under a policy that requires MFA, and compare it with the documentation.
- Audit. Check that each enrollment, recovery and removal writes an audit entry with the actor, the user and the factor type.
Lockout and step-up
Submit wrong codes up to the limit, then a correct code, which must be refused while the lock lasts. Test that the failure counter resets after a successful login and that the lock expires at the documented time. Record whether someone who knows only a username can lock that user out.
Step-up authentication asks for a factor again before a sensitive action. Test the action with a fresh step-up, with a step-up older than the policy allows, and from a session created through SSO. In the SSO case, check which claim the product trusts as proof that MFA happened at the identity provider, and that it refuses an assertion without that claim.
Session and token cases around SSO are in testing SSO and SCIM.
What to ask a QA vendor
Request a case on an MFA, SSO or passwordless product and the list of edge cases its automation covered. Each answer lines up with a dimension of the methodology:
- Dimension 1, evidence depth. A published case on an MFA or passwordless product counts here; one naming the factor types and recovery paths tested shows how far the work went. A penetration test report on an identity product is not QA evidence for this ranking.
- Dimension 3, test-type depth. Ask whether clock control, device simulation and parallel replay requests were automated or run by hand.
- Dimension 4, engagement longevity. Factor types and enrollment flows are added over several releases, so ask which factors the vendor's longest engagement saw added and whether its test suite grew with them.
- Dimension 6, security posture. TOTP shared secrets and enrolled test devices leave your control during the engagement. Ask for the vendor's ISO 27001 certificate reference and how secrets are stored and destroyed at exit.
Questions for the full vendor request are in RFP questions for a QA vendor, and factor cases belong in the identity section of the security product QA checklist.
- 1 IAM: The practice of managing user identities in an organization and deciding which roles and access privileges each person or account gets. Source
Questions buyers ask
How do you automate MFA testing?
Give the test the factor's shared secret and a controllable clock so it can generate TOTP codes, simulate the push device with a test client, and run recovery and lockout cases as API tests. Keep validation in the test build identical to production.
How do you test passwordless and security key enrollment?
Enroll a security key or platform credential from a fresh account and abandon one enrollment halfway. Register two credentials for one user, remove one and confirm that only the other still signs in, then run recovery for a user whose only factors are passwordless.
How do you test TOTP clock drift?
Submit codes from each step inside the configured window and from the first step outside it on each side, first with the device clock moved and then with the server clock moved. Codes outside the window must be refused.
How do you test that a used MFA code cannot be replayed?
Submit an accepted code again within the same window from the same session, from another session and as parallel requests sent at the same moment. Every repeat must be refused and logged.
What should MFA recovery tests cover?
Each backup code working once, admin resets that invalidate old factors, self-service recovery that asks for proof beyond the password, and an audit entry for every recovery.
What is step-up authentication testing?
Checking that sensitive actions ask for a factor again, that a step-up older than the policy period is refused, and that SSO sessions are stepped up when the identity provider did not perform MFA.
What MFA work should a QA vendor show before we hire it?
A published case on an MFA, SSO or passwordless product that names the factors tested and states whether the cases were automated. The identity facet page lists ranked vendors with verified identity work.