Multi-Factor Authentication (MFA) is one of the most effective controls available against account takeover, payment fraud, and unauthorised access. By requiring users to present credentials from at least two distinct factor categories, MFA ensures that a single compromised secret — a leaked password, a guessed PIN — is never enough to grant access on its own. For merchants and payment professionals, understanding MFA is essential both for protecting customer accounts and for meeting regulatory obligations like PSD2 SCA.
How Multi-Factor Authentication (MFA) Works
Authentication factors are grouped into three categories: something you know, something you have, and something you are. MFA is satisfied when a user presents credentials from at least two of these categories in the same session. The verification steps happen sequentially — if the first factor fails, the second is never requested, limiting exposure.
User presents primary credential
The user enters their first factor — typically a password, PIN, or email address. This is the "something you know" factor. On its own, it provides no assurance that the person is who they claim to be if credentials have been leaked or phished.
System evaluates risk (adaptive MFA)
In risk-based or adaptive MFA systems, the platform assesses contextual signals — device fingerprint, IP reputation, transaction value, geolocation, and behavioural patterns — before deciding whether to challenge the user with a second factor or silently approve the session.
Second factor is requested
If the risk engine flags the session, or if MFA is always required, the system requests a second factor. This might be a one-time password sent by SMS or generated by an authenticator app, a push notification, a hardware key tap, or a biometric scan.
Second factor is validated
The server validates the second factor against its expected value — checking a TOTP code against the current time window, verifying a cryptographic signature from a hardware key, or confirming a biometric match from the device's secure enclave.
Access or transaction is authorised
Once both factors are verified, the session is authenticated and the user is granted access or the transaction is approved. The session token is issued with a bounded lifetime, after which re-authentication may be required.
Why Multi-Factor Authentication (MFA) Matters
Credential compromise is the leading entry point for payment fraud and account takeover. Usernames and passwords alone are demonstrably insufficient: billions of credential pairs are available for sale on darknet markets, and automated bots run credential-stuffing attacks at industrial scale. The business case for MFA is backed by consistent data across the industry.
Microsoft's 2023 identity security report found that MFA blocks more than 99.9% of automated account compromise attacks, including credential stuffing and password spray. This is because even when attackers have a valid password, they almost never have simultaneous access to the user's second factor. The Verizon Data Breach Investigations Report consistently identifies stolen or weak credentials as the top attack vector — involved in over 80% of hacking-related breaches — underscoring the scale of the problem MFA is designed to solve.
Financially, the impact is significant. The Association of Certified Fraud Examiners (ACFE) estimates that organisations with stronger authentication controls experience fraud losses roughly 50% lower than those relying solely on passwords. For ecommerce merchants, this translates directly to lower chargeback rates, reduced manual review costs, and stronger customer trust. Regulatory pressure reinforces the business case: strong customer authentication under PSD2 applies to most EU electronic transactions, and non-compliant merchants face liability shifts and potential fines.
SCA and MFA in Europe
PSD2's Strong Customer Authentication rules require two of three factor types — knowledge, possession, or inherence — for most online card payments above €30 in the European Economic Area. MFA is the mechanism that makes SCA technically possible.
Multi-Factor Authentication (MFA) vs. Two-Factor Authentication
The terms MFA and two-factor authentication are often used interchangeably, but there is a precise distinction. Understanding it matters when specifying compliance requirements or designing authentication flows.
| Attribute | MFA | 2FA |
|---|---|---|
| Factor count | Two or more | Exactly two |
| Scope | Broad — encompasses 2FA | Narrow — a specific case of MFA |
| Regulatory language | Used in PSD2, NIST SP 800-63 | Common in consumer product marketing |
| Example | Password + OTP + fingerprint | Password + OTP |
| Step-up capability | Supports adding a third factor for high-value transactions | Fixed at two factors |
| Common use cases | Enterprise, banking, high-assurance flows | Consumer login, checkout |
In practice, most consumer payment flows use exactly two factors — making 2FA the dominant real-world implementation of MFA. However, specifying MFA in policy documents gives organisations flexibility to add a third factor in high-risk scenarios without updating their security policies.
Types of Multi-Factor Authentication (MFA)
MFA covers a wide spectrum of technologies, each offering different trade-offs between security strength, phishing resistance, and user friction. Choosing the right method for a given context — customer checkout versus admin access — requires understanding what each type protects against.
Knowledge factors include passwords, PINs, and security questions. They are the weakest category because they can be phished, guessed, or leaked. On their own, they do not constitute MFA.
Possession factors include SMS OTPs, authenticator app TOTP codes (Google Authenticator, Authy), hardware security keys (YubiKey), and push notifications. Hardware keys implementing FIDO2/WebAuthn are phishing-resistant because the cryptographic response is bound to the specific origin domain.
Inherence factors encompass biometric authentication — fingerprint, face recognition, voice, and iris scanning. These are processed on-device in a secure enclave and never transmitted, making them highly resistant to remote interception.
Passkeys are a modern evolution that combines possession and inherence into a single, phishing-resistant credential. A passkey uses public-key cryptography tied to a specific device and domain, replacing passwords entirely while satisfying two factor categories simultaneously.
Location and behavioural factors are sometimes used as a fourth, implicit factor in adaptive systems — geolocation, typing cadence, and device fingerprinting can all contribute to a continuous risk score without requiring any explicit user action.
Best Practices
Strong MFA implementation requires different decisions depending on whether you are operating a merchant storefront or building payment infrastructure. Both perspectives matter for reducing fraud and achieving compliance.
For Merchants
Require MFA at account creation and on login from new devices or locations. Do not allow users to permanently skip MFA during checkout — instead, use risk-based logic to suppress the challenge only for low-risk, repeat transactions on trusted devices. Store MFA enrollment status per device and present a step-up challenge when the risk score changes. Clearly communicate why MFA is requested to reduce abandonment, and provide backup codes or recovery flows to prevent permanent lockout. Audit which customers have not yet enrolled and run targeted campaigns to increase adoption.
For Developers
Implement TOTP using well-maintained libraries (e.g., otplib for Node.js, pyotp for Python) and store secrets in encrypted form, never in plaintext. For the strongest protection, implement FIDO2/WebAuthn and support passkeys as a first-class option. Rate-limit OTP validation attempts (no more than five tries before a cooldown) to prevent brute force. Bind authentication tokens to the device and session — never issue long-lived tokens without MFA re-verification for sensitive actions such as changing payment methods. Emit structured audit events for every MFA challenge, success, and failure to support fraud investigations.
Common Mistakes
MFA is often implemented in ways that leave significant security gaps. These are the errors seen most frequently in payment and ecommerce contexts.
Relying exclusively on SMS OTP. SMS is the most common second factor but also the most vulnerable to SIM-swapping and SS7 attacks. Financial services regulators in several jurisdictions explicitly warn against SMS as the sole MFA mechanism for high-value transactions.
Not requiring MFA on account recovery flows. Password reset, phone number change, and email update are the most common bypass routes attackers exploit. If these flows are not themselves MFA-protected, the entire authentication system can be circumvented.
Treating MFA as a one-time setup. Devices get lost or compromised. Re-validating enrolled factors periodically — and prompting re-enrollment after a defined period of inactivity — reduces the window of exposure from stale or orphaned credentials.
Allowing indefinite session persistence. If a session token issued after MFA never expires, an attacker who steals the token can bypass MFA entirely. Tie session lifetime to risk level and require re-authentication for high-value or sensitive operations.
Ignoring MFA for internal and admin accounts. Many ecommerce breaches originate from compromised back-office or admin credentials, not customer accounts. All staff with access to payment data, order management, or customer PII should be enrolled in MFA with hardware key or passkey enforcement where possible.
Multi-Factor Authentication (MFA) and Tagada
Tagada is a payment orchestration platform that routes transactions across multiple payment service providers and acquirers. MFA is deeply embedded in the payment flows Tagada manages, particularly for merchants operating in the European Economic Area where SCA is a legal requirement.
MFA in Tagada's authentication flows
Tagada handles 3D Secure orchestration natively, routing each transaction through the appropriate SCA challenge based on the issuer's requirements, the transaction risk score, and applicable exemptions. This means merchants using Tagada automatically benefit from compliant MFA flows at checkout without building their own SCA logic. For high-value or out-of-exemption transactions, Tagada triggers the issuer's MFA challenge — knowledge, possession, or biometric — and surfaces the result back to the merchant in a structured response, enabling clean fallback and retry logic.
For merchants building on Tagada, this eliminates the need to maintain separate SCA/MFA integration code per acquirer or market. The platform abstracts issuer-side MFA variance while exposing a consistent API response that captures whether SCA was performed, which factors were used, and whether an exemption was applied — all the data needed for liability protection and dispute resolution.