product
Test MFA without reaching for your phone
Pair a virtual authenticator with your test user, generate fresh TOTP codes, and verify enrollment and sign-in from Selenium, Playwright, or your API tests.
An automated login test should prove that the second factor works, including the step after enrollment. Manually reading an authenticator code interrupts a test run, while a hard-coded code stops working as soon as its time window closes.
MailSlurp gives your tests programmable TOTP authenticators. Pair a device with the secret issued to your test user, request a current code through the API, and submit it in Selenium, Playwright, Cypress, or your own test runner. Keep the same paired device for that user's later sign-in checks.
TOTP codes are generated from a shared secret and time. For codes delivered in a message, use email OTP testing or SMS testing. MailSlurp supports each path so you can test the factor your application actually asks for.
Built for IT Departments
Use virtual authenticators to exercise your identity provider's enrollment, login, and step-up authentication flows with dedicated test users. Your tests can complete a real challenge and check the protected application screen that follows it.
QA & Testing Teams
Pair a separate device with each test user's enrollment secret. Check that enrollment succeeds, sign out, start a new login, and assert access only after the second-factor challenge succeeds. This catches a flow that accepts setup but fails on the next visit.
See Selenium Java Test example
DevOps & Engineering Teams
Call the MFA API from your existing test runner and keep device IDs with their test-user fixtures. Fetch codes close to submission, keep the application's clock synchronized, and isolate enrollment secrets in your CI secret store. Use your account's device allowance when planning parallel suites.
Product & IT Operations
Exercise the customer paths that change MFA state: first enrollment, later login, device replacement, and recovery. Record the outcome and test-user reference without recording secrets, QR enrollment data, or current codes in shared reports.
Powerful APIs and functions
The API supplies the authenticator; your test drives the application and checks the result. Follow the complete TOTP setup and code examples for SDK calls and request formats.
Pair a device with the test user's enrollment
Read the Base32 secret or otpauth:// URI from the user's actual enrollment flow, then create the MailSlurp device with that value. A QR code contains enrollment data; use the provider's supported manual setup value or decode the QR image when necessary. Save the returned device ID with the correct test user.
An unrelated generated secret will not match the identity provider. When the user resets MFA, create a pairing from the new enrollment rather than reusing the old device's code.
Generate OTP codes
Request a code from the paired device immediately before filling the authenticator field. Keep it as a string so a leading zero survives. Submit it, then assert the application's authenticated state instead of treating a generated code as a successful login.
Two requests in one TOTP time period can return the same code. Separate enrollment and login checks according to the provider's replay and timing policy. The Selenium Auth0 example walks through enrollment and a subsequent sign-in; the Playwright example shows browser-based enrollment.
Check both accepted and rejected challenges
Successful login is one part of an MFA test. Use controlled test accounts to cover failures without locking out real users:
| Scenario | What the application should demonstrate |
|---|---|
| Correct code for the enrolled user | Enrollment or the current sign-in challenge completes and the intended user reaches the protected page. |
| Deliberately invalid code | Access remains blocked; the session does not become authenticated. |
| Expired code | A code outside the provider's accepted time window is rejected. |
| Reused code | Behavior matches the provider's documented replay policy. |
| Replacement enrollment | The new pairing works and the retired factor follows the application's removal policy. |
Define the accepted time window and failure policy before writing these assertions. Choose a negative-test code outside the target user's currently accepted codes; a different user's code can coincidentally match. A fixed sleep does not establish expiry unless it exceeds that configured window. Retain useful failure diagnostics while redacting the secret and code.
Keep evidence for security reviews
Save the test case, application version, expected outcome, and observed authentication result. Those records help your team review whether its MFA control behaves as intended. Keep compliance assessment tied to the full application and its operating controls rather than a single successful authenticator test.
Get started
Start using MFA devices today free, by creating an account.