What is the difference between strong customer authentication and ordinary MFA?

Ordinary MFA proves a user supplied multiple factors at login, but Strong Customer Authentication also requires the factors and the approval flow to support the payment context. Under PSD2, the transaction itself must be protected, which is why dynamic linking and recipient confirmation matter as much as the login step.

Why This Matters for Security Teams

Strong customer authentication is not just “more MFA.” It is a payment-security control that ties proof of authentication to the transaction being approved, so the user is not only logging in but also authorising a specific payment. That distinction matters because attackers increasingly bypass generic login checks and target the approval step, where ordinary MFA can be too broad or too reusable. Under PSD2, the security objective is transaction integrity, not only identity proof.

That is why dynamic linking and recipient confirmation are central to SCA. A push approval that does not cryptographically bind the amount and payee can still leave room for fraud even if the login looked strong. Current guidance suggests thinking in terms of context-aware authorisation, not just factor count. The same lesson appears in NHI governance, where Ultimate Guide to NHIs — What are Non-Human Identities shows how identity controls fail when they are not matched to the action being taken, and NIST Cybersecurity Framework 2.0 reinforces the need to align controls to risk and business context.

In practice, many security teams encounter payment fraud only after a valid login has already been converted into an unauthorised transaction, rather than through intentional approval design.

How It Works in Practice

Ordinary MFA answers a narrow question: did the user satisfy the authentication gate? SCA answers a broader one: did the user authenticate in a way that is appropriate to this specific payment and did the approval reflect that payment context? In practical terms, SCA usually combines possession and knowledge or inherence factors with a transaction-bound approval flow. The payment details should be visible to the approver and cryptographically linked to the authorisation so a transfer cannot be silently altered after approval.

For payment teams, the difference shows up in the control design. Ordinary MFA may be enough for application sign-in, but it is not automatically enough for regulated payment approval. SCA often requires stronger step-up verification, device binding, and dynamic linking so the payment amount and payee are part of the authentication event. That is why a generic “approve” button is weaker than a signed transaction confirmation. NIST’s guidance on risk-aligned control selection in NIST Cybersecurity Framework 2.0 is useful here, even though PSD2 sets the regulatory bar rather than NIST.

• MFA validates identity at login; SCA validates identity plus transaction approval.
• MFA can be reused across unrelated actions; SCA should be bound to a single payment event.
• SCA typically adds dynamic linking, so amount and payee are part of the approval.
• Recipient confirmation reduces the risk of push-style payment redirection and account takeover abuse.

There is a useful parallel in the Microsoft Midnight Blizzard breach, where identity compromise became dangerous because access was not constrained tightly enough to the actual action and environment. These controls tend to break down when legacy payment flows cannot support transaction binding because the approval experience and the backend audit trail are not designed together.

Common Variations and Edge Cases

Tighter payment approval controls often increase friction, so organisations have to balance fraud reduction against user experience and abandonment risk. That tradeoff is why current guidance is still evolving on how best to implement SCA across every channel and device class. In mobile apps, for example, device binding and biometric confirmation may satisfy the spirit of SCA when paired with transaction details, but browser-based flows often need a different design to preserve both usability and auditability.

There is also an important exception for non-payment contexts: MFA may be perfectly appropriate for admin portals, internal tools, and general account access, even when the same user later encounters SCA in a payment journey. The two controls are related but not interchangeable. SCA is a regulated transaction-security model, while ordinary MFA is a broader access-control technique.

One more nuance is that “MFA” marketing language can hide weak implementations. A push notification without transaction details, a reusable one-time code, or a challenge that does not show the recipient can still satisfy a login policy while failing the payment-intent test. The Ultimate Guide to NHIs — What are Non-Human Identities is relevant here because the same governance mistake appears in machine access: proof of identity alone is not enough when the action itself carries risk. Practitioners should treat SCA as a transaction-integrity control, not a stronger synonym for MFA.

Related resources from NHI Mgmt Group

• What is the difference between API authentication and API authorization in MCP environments?
• What is the difference between compliance-ready MFA and phishing-resistant MFA?
• What is the difference between initial authentication and continuous authorization?
• What is the difference between strong client authentication and least privilege?