Organisations should map transaction risk to authentication strength and prove that the factors used are independent and appropriate for the payment action. The control is not simply MFA at the login screen. It is assurance that the authenticated identity, device, and transaction context together satisfy the PSD2 requirement before payment execution.
Why This Matters for Security Teams
PSD2 strong customer authentication is often reduced to “add MFA,” but that misses the operational point: the control must bind the person, the device, and the payment action together before execution. The risk is not only account takeover. It is fraudulent payment initiation under conditions that appear legitimate at the login layer but are not sufficiently authenticated for the transaction itself. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that effective controls must map to business risk, not just identity events.
For payment teams, the difficult part is proving factor independence and maintaining that assurance as channels, devices, and customer journeys change. The authentication design has to withstand phishing, session hijacking, social engineering, and transaction manipulation without creating unusable friction. NHI Management Group notes that many organisations still struggle to govern authentication material consistently, and the same discipline applies here when credentials, tokens, and device trust are part of the payment flow. See the Ultimate Guide to NHIs for broader lifecycle and control context. In practice, many teams discover PSD2 weaknesses only after a disputed payment or failed audit has already exposed the gap.
How It Works in Practice
Strong customer authentication under PSD2 works best when it is treated as a transaction control chain rather than a single login event. The organisation should first classify payment scenarios by risk, then require authentication factors that are demonstrably independent and suited to that risk. In practice, that usually means combining something the customer knows, possesses, or is, but validating those factors against the payment amount, beneficiary, channel, and device trust at runtime.
Operationally, that means implementing:
- Step-up authentication for higher-risk payments or new payees.
- Dynamic linking so the auth event is tied to the exact amount and recipient.
- Device and session risk checks before approving the transaction.
- Challenge flows that resist interception, replay, and phishing.
- Audit evidence showing which factors were used and why the decision passed.
Where organisations get this wrong is by treating the first successful login as sufficient proof for every later payment in that session. Current guidance suggests the stronger design is contextual and transaction-specific, with explicit evidence that the authentication response corresponds to the payment action itself. The Ultimate Guide to NHIs is useful here because it reinforces a broader principle: identity controls fail when they are not tied to lifecycle, visibility, and revocation. These controls tend to break down in fragmented banking journeys with multiple redirect hops, legacy mobile apps, or third-party payment initiation paths because the transaction context is lost between authentication and execution.
Common Variations and Edge Cases
Tighter authentication often increases customer friction, so organisations have to balance fraud reduction against conversion loss and support overhead. There is no universal standard for every journey, and PSD2 implementations vary depending on payment type, exemption strategy, and channel design.
One common edge case is delegated or third-party payment initiation, where the authenticator and the payment actor are not the same system. Another is low-risk or recurring payments, where exemption logic may reduce challenge frequency but still requires sound risk scoring and auditability. Best practice is evolving on how much behavioural telemetry should influence SCA decisions, especially when privacy, regional regulation, and model explainability intersect.
Security teams should also watch for weak factor independence in practice. A password plus OTP is not automatically strong if both are exposed through the same compromised channel. Likewise, push approvals can fail if the approval screen does not clearly display the exact transaction details. The control should be judged by whether it resists manipulation end to end, not by the number of prompts. Organisations that rely on legacy authentication stacks or outsourced payment journeys often find that their SCA design looks compliant on paper but fails under real fraud pressure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Access and authentication outcomes must map to payment risk and assurance. |
| NIST SP 800-63 | Digital identity assurance informs how factors are bound and trusted. | |
| EU AI Act | Only relevant where AI risk scoring materially affects SCA decisions. |
Use identity assurance principles to select independent factors and document the trust level for each payment flow.
Related resources from NHI Mgmt Group
- What do organisations get wrong about continuous authentication?
- How should organisations implement passwordless IAM without weakening recovery controls?
- How should organisations decide where to use biometric authentication?
- How do teams decide whether possession-based authentication is strong enough?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
