PSD2 Strong Customer Authentication is a regulatory authentication requirement that asks for at least two independent factors from knowledge, possession, and inherence for many electronic payments and account access events. It is used in payment security to reduce fraud and relies on factor combinations rather than a single password.
What Strong Customer Authentication Means in Practice
PSD2 Strong Customer Authentication is not just “use MFA”. It is a payments-specific regulatory rule that changes how access and payment approval are proven, with a focus on independence between factors and on reducing fraud at the point of transaction or account access. That makes it a control requirement, not simply an authentication method choice.
In practice, SCA matters because payment journeys often involve step-up authentication, delegated access, exemptions, and evidence that the chosen factor combination satisfies the regulation. For a deeper treatment of the rule set, exemptions, and the PSD3 transition context, see the PSD2/PSD3 Strong Customer Authentication Guide.
Why the “Two Independent Factors” Requirement Matters
The security value of SCA comes from combining categories that do not fail in the same way, such as knowledge, possession, and inherence. If one factor is phishable, reused, or intercepted, the second factor should still raise the attacker’s cost. That is why SCA is stronger than a password-only model, but also why weak implementations can still be bypassed through relay attacks, social engineering, or poor recovery flows.
The same logic underpins modern customer authentication programs: the control is only as strong as the independence of the factors and the integrity of the transaction binding. NHIMG’s Customer IAM (CIAM) Guide and Passwordless and Passkeys Guide are useful adjacent references when you are deciding how to meet that standard with phishing-resistant authentication.
Where PSD2 SCA Shows Up in Payment Flows
SCA is most visible where a payment provider or bank must decide whether an event needs stronger user verification, whether an exemption can apply, and how to record the result. The operational question is not only “did the user log in?” but also “did this specific payment, access event, or delegated action meet the regulatory test?”
That means the same customer may experience different authentication paths depending on amount, risk signals, device context, merchant type, or whether a trusted flow already exists. In broader financial-services environments, the control sits alongside identity governance, fraud prevention, and third-party access management. The Financial Services Identity Security Guide helps place SCA inside the wider control environment that banks and payments firms operate.
Evidence, Exemptions, and Operational Dependencies
Because SCA is regulatory, organisations need evidence that the control was correctly applied, not just that a login succeeded. That evidence often includes authentication logs, transaction context, exemption handling, and audit trails showing why a specific path was accepted. The operational challenge is to keep the control strong without creating excessive friction or false declines.
Dependencies matter as well. If fraud systems, identity providers, mobile authenticators, or recovery processes are weak, the strongest SCA policy can still be undermined. Payment teams therefore need to review how authentication interacts with transaction risk analysis, step-up prompts, and fallback paths. For payment-specific mechanics and fraud trade-offs, the Payment Fraud Guide provides a practical companion perspective.
Risk and Threat Considerations
SCA reduces fraud, but it also creates a clear target for attackers: if they can steal a factor, relay an approval, or abuse account recovery, they can still reach payment authority. Weak exemptions, legacy login paths, and over-permissive fallback flows are common places where the intended protection erodes.
Failure mechanism: An attacker bypasses the second factor by using MFA fatigue, real-time phishing, session theft, or a weak recovery route that re-establishes access without satisfying the intended factor independence.
Impact: The result can be unauthorised payments, account takeover, fraudulent access to banking or wallet sessions, and loss of trust in the payment channel’s control design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IA-5 — Authenticator Management | SCA depends on managing authenticators and factor use for digital identity verification. |
| Recommendation — Use authenticator management to govern factor issuance, binding, rotation, and recovery for SCA flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SCA is an authentication control that verifies who is acting before payment or access approval. |
| Recommendation — Enforce strong identification and authentication before allowing payment-authority actions. | ||
| PCI DSS v4.0 | 8.6 — System and Application Accounts with Interactive Login | Payment environments need strong authentication controls over accounts used to access sensitive systems. |
| Recommendation — Restrict interactive use of sensitive accounts and require strong authentication for payment-system access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SCA is an access-control decision for payment and account events governed by policy. |
| Recommendation — Define and enforce access rules that require stronger verification for payment-authority events. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SCA is a control around granting and verifying access to protected payment functions. |
| Recommendation — Apply access control management to restrict payment functions to verified users and approved flows. | ||
Practitioner Guidance
Why practitioners should care: PSD2 SCA is not a generic authentication policy, it is an auditable payments control. Teams should align product, fraud, and security ownership so that exemptions, recovery, and delegated access do not quietly become exceptions that defeat the control.
What to watch for: Pay close attention to login paths that look “strong” in isolation but weaken at the handoff into transaction approval, account recovery, or third-party access. Those are the places where compliance and fraud risk usually converge.
Practitioner takeaway: Treat SCA as an end-to-end payment assurance design, not a single authentication event, and validate the whole journey from factor proofing through transaction decisioning.
Related resources from NHI Mgmt Group
- How should organisations implement strong customer authentication for PSD2?
- Who is accountable when a payment provider fails to meet PSD2 strong customer authentication requirements?
- How should merchants prepare for PSD2 strong customer authentication without sacrificing too much conversion?
- Why does strong customer authentication sometimes create friction in open banking and PSD2 compliance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org