How to test multi-factor authentication in banking software

Banking multi-factor authentication testing checks that a banking application requires and verifies the intended combination of independent authentication factors, and enforces that decision across sign-in, sensitive actions and recovery. It covers successful and rejected challenges, factor enrolment, session handling, service failures and the controls around retries, so testers can verify that a customer cannot reach a protected action without the required proof.

Banking multi-factor authentication testing scope

Start with the authentication policy and map each protected journey to its required factors. A factor may be something the customer knows, has or is. Two passwords remain one factor type; a password and a code from a registered device represent different types. Record which actions require step-up authentication, such as adding a beneficiary or confirming a payment, and what happens when the customer changes device or loses access to a factor.

Include each channel and relevant integration: web and mobile clients, identity services, one-time password (OTP) delivery providers, push notification services and banking APIs. Confirm that the server enforces authentication state. A hidden or disabled button in the user interface does not protect an API operation if a request can still reach it without a valid, completed challenge.

Design the test conditions

Use dedicated test accounts and non-production systems. Configure controlled OTP or push test services where possible, and avoid sending real messages to customers or using production credentials. Keep test secrets out of source control, screenshots and routine logs. Agree in advance how to reset accounts and clear challenges after a run.

Build cases from the policy and its state transitions: unauthenticated, challenge issued, challenge passed, challenge expired, factor rejected and session revoked. Cover positive paths alongside invalid, missing, expired, repeated and out-of-order responses. Check expected behaviour at boundaries, including the exact expiry point and the configured retry limit.

A useful test set includes:

• Correct and incorrect factors, with a check that a failed challenge grants no protected access.
• Expired, already-used or session-mismatched codes, each rejected as intended.
• Repeated submissions and delivery requests, verifying rate limits and lockout or delay rules without creating an easy denial-of-service condition.
• Factor enrolment, replacement, removal and recovery, including whether an existing session or factor can authorise an unauthorised change.
• Transaction step-up, checking that the challenge relates to the customer’s current action and that changing relevant payment details invalidates or refreshes confirmation as specified.
• Failure or delay in an external authentication service, checking the documented fail-closed or controlled fallback behaviour.

Verify enforcement and failure handling

Test the complete customer journey, then make authorised API-level checks against the same protected operations. Verify that an incomplete challenge cannot create a fully authenticated session or authorise a payment. Check that a challenge is bound to the intended customer, session and action, and that replaying a successful response does not authorise another action.

Inspect audit events for challenge issue, success, failure, factor change, recovery and lockout. Events should support investigation while masking OTPs, passwords, recovery codes and other authentication secrets. Check customer-facing messages for useful guidance without exposing whether a particular account exists or revealing sensitive policy details.

Treat fallback routes as part of the security boundary. If a customer can switch from a stronger factor to a weaker recovery method, test the eligibility checks, notifications, delays and limits defined by the bank. Verify that support or administrative processes cannot silently bypass the customer’s authentication policy.

Worked example: adding a beneficiary

Assume policy requires a password at sign-in and a registered-device approval when a customer adds a beneficiary. Create a test customer with a known device and a test beneficiary. Sign in, start the add-beneficiary flow and approve the challenge. Confirm that the beneficiary is created once and that the audit trail records the decision without recording the approval secret.

Repeat with a rejected approval, an expired challenge and an approval submitted from a different session. In each case, verify that no beneficiary is created. Then change the beneficiary details after the challenge is issued and confirm that the application requires a new approval for the updated action. Check the equivalent server-side operation so the result does not depend on client-side controls.

Record expected results, account state, environment and relevant event identifiers. This makes failures reproducible and helps distinguish an authentication defect from test data, notification delivery or environment drift.