PSD2 compliance and passwordless authentication for payment access

At a glance

What this is: This is a compliance analysis of PSD2 and the authentication controls needed to meet EU payment requirements, with passwordless MFA positioned as a way to satisfy Strong Customer Authentication.

Why it matters: IAM and NHI practitioners should pay attention because payment workflows increasingly depend on machine-mediated authentication, transaction binding, and device-bound identity rather than passwords alone.

By the numbers:

• The article says PSD2 compliance became mandatory for businesses doing work in the EU after the December 31, 2020 deadline.
• The article says 3D Secure 2.0 can provide up to 150 data points to banks for transaction legitimacy checks.

👉 Read Beyond Identity's explanation of PSD2 compliance and passwordless authentication

Context

PSD2 is a payment authentication and access-control problem, not just a compliance checkbox. For organisations that operate in the EU or serve EU payment flows, the practical question is whether their identity controls can prove who or what is initiating a transaction, bind that proof to the payment details, and do so without weakening the checkout path. That is an NHI governance issue because payment applications, devices, tokens, and APIs all participate in the authentication chain.

The article frames passwordless authentication as one way to satisfy Strong Customer Authentication while reducing reliance on passwords and legacy MFA flows. That claim matters because modern payment systems are increasingly distributed across apps, devices, and third-party services. For background on how NHI governance maps to access, lifecycle, and control design, see the Ultimate Guide to NHIs.

Key questions

Q: How should organisations implement PSD2 controls without adding too much checkout friction?

A: Use passwordless or phishing-resistant authentication where it can satisfy Strong Customer Authentication, then bind the approval to the transaction details so the user confirms the amount and payee once. The goal is to replace repeated prompts with a single, high-assurance event that is harder to phish and easier to complete.

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

A: 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.

Q: Why does PSD2 matter to NHI and IAM teams outside banking?

A: PSD2 shows how identity controls, third-party access, and transaction authorisation converge in modern digital systems. Any environment that depends on tokens, APIs, devices, or autonomous workflows faces similar governance issues, especially when reusable secrets and standing access remain in place.

Q: Should teams prefer passwordless authentication for regulated payment flows?

A: They should prefer it when the implementation gives clear device binding, local user verification, and strong recovery controls. Passwordless reduces phishing risk, but it only improves assurance if the organisation can govern device enrollment, revocation, and fallback paths with the same discipline as credentials.

Technical breakdown

Strong Customer Authentication and transaction binding

PSD2’s Strong Customer Authentication requires at least two of three factor types: knowledge, possession, and inherence. In practice, this is not just about logging a user in. The authentication event must also be bound to the payment amount and payee so that a valid code cannot be reused for a different transaction. That is why simple password checks or static one-time codes are not enough on their own. The control objective is to prevent credential replay, transaction tampering, and unauthorised payment substitution.

Practical implication: teams should verify that authentication is tied to the transaction itself, not only to the session.

Passwordless authentication as device-bound identity

Passwordless authentication replaces shared or replayable secrets with a device-bound private key and local user verification, such as biometrics or another inherence factor. The security value is that the private key stays tied to a specific device, so the identity proof is harder to phish or reuse elsewhere. In a payment context, this shifts part of the trust boundary from memorised credentials to managed endpoints and local authenticators. The result is better resistance to account takeover, but only if device enrollment, recovery, and revocation are controlled tightly.

Practical implication: treat the device as an identity asset and govern enrollment, recovery, and revocation with the same care as credentials.

Open banking access and third-party exposure

PSD2 also requires financial institutions to expose account data through APIs to authorised third parties. That creates a governance problem because access is no longer limited to the primary bank and end user. API credentials, consent tokens, and application entitlements become part of the non-human identity surface. If those artefacts are over-scoped, long-lived, or poorly revoked, the payment ecosystem inherits the same risks seen in other NHI environments: unauthorized access, weak auditability, and difficult offboarding.

Practical implication: review third-party API access as an NHI lifecycle problem, not just a partner integration task.

Threat narrative

Attacker objective: The attacker aims to initiate or alter payment transactions while bypassing transaction-level authentication controls.

1. Entry occurs when attackers target password-based checkout flows, phished credentials, or weak recovery paths to gain a foothold in payment accounts.
2. Escalation follows when stolen sessions, reusable secrets, or over-privileged API access let the attacker move from login access to transaction execution.
3. Impact is realised when the attacker initiates or modifies payments without strong transaction binding, causing account takeover fraud or unauthorised transfers.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PSD2 is really an NHI governance problem disguised as a payments rule. The directive is written for human customers, but the control surface includes devices, API credentials, payment tokens, and third-party integrations. That means teams must manage identity lifecycle, access scope, and transaction binding together rather than as separate programmes. Practitioners should treat payment authentication as a governed identity flow, not a front-end UX decision.

Device-bound identity reduces password risk, but it does not eliminate trust debt. Passwordless controls remove one of the weakest authenticators, yet they replace it with assumptions about device integrity, local verification, and recovery processes. If those assumptions are not auditable, the organisation has simply shifted the trust problem. The control model is stronger only when enrolment, revocation, and fallback paths are explicit and monitored. Practitioners should govern the device and recovery layer as part of the identity perimeter.

Dynamic linking is the most useful PSD2 concept for broader NHI security. The requirement that a code be bound to amount and recipient is a practical example of contextual authorisation. That idea extends beyond payments into service accounts, workflow automations, and AI agents, where the action should be tied to purpose, scope, and time. This is where NHI programmes need to mature from static access grants to action-specific authorisation. Practitioners should apply the same thinking to every high-risk automated workflow.

Open banking expands the NHI attack surface faster than most IAM teams expect. Third-party API access turns partners into persistent access holders unless consent, expiry, and offboarding are enforced. That creates the same governance failure mode seen in broader NHI sprawl: too many identities, too much standing access, and too little visibility. The lesson is not that open banking is unsafe, but that it must be managed as a high-volume identity ecosystem. Practitioners should inventory and control partner credentials with the same discipline used for internal machine identities.

The market signal is clear: authentication is moving from secret-centric to proof-centric design. PSD2 compliance pressure has pushed payment teams toward mechanisms that prove device possession and local user presence rather than relying on shared knowledge factors. That direction aligns with where NHI governance is heading more broadly, including workload identity and agentic systems. Practitioners should expect future control models to reward verifiable proof over reusable secrets.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many payment and API environments still lack a complete identity inventory.
• For a broader lifecycle view, Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs helps teams turn access review into an operational control.

What this signals

Dynamic linking is a useful model for broader identity governance. If the approval must be tied to the amount and recipient, then identity controls can no longer be treated as generic session checks. That same principle applies to service accounts, partner tokens, and AI-driven workflows, where scope and purpose should travel with the action. Teams that are modernising IAM should treat contextual authorisation as a design requirement, not an exception.

With 91.6% of secrets still valid five days after notification, the operational lesson is that revocation is only real when it is fast and enforced across every credential type. Payment systems that rely on reusable tokens or fallback secrets will inherit the same lag unless ownership, rotation, and offboarding are measured as service-level controls.

For regulated payment environments, the next governance step is to unify customer authentication, API consent, and third-party entitlement review into one control plane. That makes it easier to see where standing access persists and where transaction approval can be strengthened with device-bound proof. The same pattern will matter as autonomous agents begin to trigger financial actions.

For practitioners

• Map every payment path to factor requirements Document where knowledge, possession, and inherence are used across checkout, recovery, and third-party payment flows. Confirm that every in-scope transaction can demonstrate at least two factors and that those factors are not both knowledge-based. Use this mapping to identify fallback paths that silently bypass Strong Customer Authentication.
• Bind authentication to transaction details Verify that the amount and recipient are included in the approval step and that any change invalidates the prior authentication code. This reduces replay and substitution risk in line with dynamic linking requirements. Treat the payment object, not the session, as the unit of authorisation.
• Govern device enrollment and recovery as identity controls Require enrollment, reset, and revocation processes for device-bound credentials, especially where passwordless authentication replaces legacy MFA. Lost devices, account recovery, and help desk resets are common weak points, so they need approval, logging, and timely revocation. For broader identity guidance, align these controls with the Ultimate Guide to NHIs.
• Inventory third-party API access and consent lifecycles Treat open banking integrations as non-human identities with explicit ownership, scope, and expiration. Review who can call the API, what data they can reach, and how quickly access is revoked when consent changes or a partner is offboarded. Tie this review to your NHI lifecycle processes.

Key takeaways

• PSD2 pushes payment security toward context-bound authentication, not just login assurance.
• Passwordless controls help only when device trust, recovery, and revocation are governed as identity assets.
• Open banking and payment APIs should be managed as non-human identities with full lifecycle control.

Key terms

• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Dynamic Linking: A transaction integrity control that binds authentication to the payment amount and payee. If either changes, the authentication code is no longer valid, which helps stop substitution attacks and prevents a legitimate approval from being reused for a different transfer.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• Open Banking Access: A model in which authorised third parties can access banking data through APIs with the customer’s consent. It expands the identity surface because partner credentials, consent tokens, and application entitlements must be governed as non-human identities.

Deepen your knowledge

PSD2 Strong Customer Authentication and passwordless authentication are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls for payment workflows or API-driven access, it is worth exploring.

This post draws on content published by Beyond Identity: PSD2 Compliance Requirements and Passwordless Authentication. Read the original.