Analysis of PSD2 & SCA Requirements (SCA & Passkeys II)

Overview: Strong Customer Authentication with Passkeys#

• Device-Bound vs. Synced Passkeys
• What SCA Requirements Mean for Passkeys
• PSD3 / PSR Implications for Passkeys

1. Introduction: Analysis of PSD2 and SCA Requirements#

After having analyzed the historical development and technical foundation of passkeys in the previous part of our 4-part series around passkeys and their SCA compliance, we now analyze the regulatory side and look into existing legal requirements here.

We start by taking a look at the legal foundation and learn how SCA has been updated and extended continuously over time.

2. Legal Foundation of PSD2, RTS, SCA and Dynamic Linking#

PSD2, or Directive (EU) 2015/2366, sets the legal groundwork for stronger payment security in the EU, introducing Strong Customer Authentication (SCA) and dynamic linking to protect electronic payments. The technical details for implementing these concepts were outlined in Commission Delegated Regulation (EU) 2018/389, with updates provided by Delegated Regulation (EU) 2022/2360. While the EU Directive establishes the law with decision of the European Parliament and the European Commission specifies technical standards, the European Banking Authority (EBA) ensures consistent application across member states. Through its officially released opinions, guidelines, recommendations, and notably, the Single Rulebook Q&A, the EBA helps national regulators across EU member states in interpreting and applying these laws consistently. While EBA's outputs are not directly legally binding, they are instrumental in achieving a harmonized regulatory approach, offering detailed insights and clarifications that guide the practical implementation of PSD2's mandates on SCA and dynamic linking by market participants and national regulators.

3. Strong Customer Authentication (SCA)#

The introduction of Strong Customer Authentication (SCA) by the EU places the responsibility for unauthorized payments primarily on financial institutions rather than consumers. Under SCA, if a payment service provider does not employ SCA, the provider must cover any financial losses, barring fraudulent action by the payer. Similarly, if a payee or their payment service provider does not support SCA, they must compensate the payer's provider for any resulting damages. SCA is crucial for various transactions, including credit card and bank transfers, and is also required for user login to banking services. Dynamic linking is an additional requirement when payment transactions are initiated and signed but will not be part of this discussion. We will start with a small overview of the layers of governmental bodies.

What are the different layers of governmental input for SCA?

There are four layers that from 1 to 4 get more specific providing detailed insights how

gray areas and ambiguities should be handled. We will now go deeper into the background of SCA and go through the definitions and sources of regulations for SCA layer by layer.

3.1 Directive (EU) 2015/2366 (PSD2)#

The first layer of definition is the actual Directive: Article 97 Authentication of Directive (EU) 2015/2366 (PSD2) defines:

“Member States shall ensure that a payment service provider applies strong customer authentication where the payer:

• (a) accesses its payment account online;
• (b) initiates an electronic payment transaction;
• (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses”

and lays out in Article 98 that EBA shall:

• “develop draft regulatory technical standards addressed to payment service providers as set out in Article 1(1) of this Directive”

In addition within the definitions in Article 4, three important words are laid out:

As we can see in the table above Strong Customer Authentication by means of interpreting the Directive itself does not require two factors from different categories but rather two in total. In terms of “Multi factor classification”, this could therefore be interpreted as 2SV (and not 2FA) when only reading the directive.

3.2 Delegated Regulation (EU) 2018/389: Regulatory Technical Standards on SCA#

The second layer of definition was set into place by the Commission in the Delegated Regulation (EU) 2018/389 which released regulator technical standards on SCA.

3.3 European Banking Authority Opinion 2018 (EBA-2018-Op-04)#

The EBA's opinion from 13.06.2018 EBA-2018-Op-04 on the RTS for strong customer authentication and secure communication acts as a third layer of definition. While these EBA guidelines offer recommendations and serve as guidance for national regulators, they do not have the force of law. However, their guidelines are often treated as highly authoritative, making them "de facto law" in practice for the implementation of regulatory standards.

With this additional requirement EBA lifted up the SCA requirements to true 2FA requiring both factors to be from distinct categories (before it was merely 2SV).

3.4 European Banking Authority (EBA) Opinion 2019 (EBA-Op-2019-06)#

Because of increasing uncertainty among market participants, the EBA released another opinion specifically targeting only strong customer authentication under PSD 2 on 21.06.2019 EBA-Op-2019-06:

It is observable that rules have become increasingly stringent with every additional opinion from the EBA. However, commentary indicates that many implementations within Europe, under various regulators, are considered by the EBA to be non-compliant. Despite this, the EBA does not exert pressure to change the situation.

3.5 European Banking Authority (EBA) Single Rulebook Q&A#

Moreover, the fourth layer are the Q&As which can be asked via the Single Rulebook Q&A site of the EBA. Most of the questions that were asked before the publication of the last opinion in 2019 have been integrated into the publication. Nevertheless, there are some interesting Q&As that shed some light on the thinking process of the regulators:

Are SMS OTPs RCA compliant (2018_4039)?

Yes, the possession is not the SMS itself, but rather typically the SIM-card associated with the respective number.

Can username/password login and SMS OTP be on the same device (phone) and be SCA compliant (2019_4637)?

Yes, as there is sufficient risk protection and mitigation due to “different execution environments”

Are native app push notifications RCA compliant (2019_4984)?

Yes, as long as sufficient measures are taken against unauthorized parties and possession of device evidenced by OTP generated or perceived is fulfilled (which is also covered by #EBA2019.25).

Even though there is obviously a lot of guidance, opinions or Q&As, no statement regarding WebAuthn or passkeys as SCA factor can be found so far.

4. How Corbado maps PSD2/SCA Requirements to real Passkey Deployments#

The regulatory layers analyzed above — from PSD2 to the RTS to EBA guidance — create a complex compliance landscape for banks deploying passkeys. Corbado translates these requirements into operational tooling that gives banks both visibility and control.

SCA Factor Coverage Monitoring#

Corbado's Device Trust dashboard maps each authentication method to its SCA factors in real time, providing the evidence banks need for regulatory discussions. The dashboard shows exactly which factor combination each method provides (knowledge, possession, inherence), actual success rates, and whether the method is phishing-resistant — the key criteria from the RTS analysis above.

This operational data directly addresses the EBA's requirements for multi-factor authentication independence and helps banks demonstrate compliance with the RTS security standards for their specific passkey deployment approach.

Trust Policies that implement your SCA Interpretation#

The EBA Single Rulebook leaves room for interpretation on how passkeys satisfy SCA factors. Corbado's configurable trust policies let banks implement their specific regulatory interpretation: whether that's treating device-bound passkeys as sufficient (no step-up), requiring additional verification for synced passkeys on new devices, or blocking passkey creation on shared/kiosk devices entirely.

These policies implement the dynamic, risk-based approach that the RTS exemption framework envisions — adapting authentication requirements to the actual risk profile of each login scenario.

Frequently Asked Questions#

What are the technical standards for SCA in the RTS?#

The Regulatory Technical Standards (RTS) for SCA under PSD2 establish key security requirements:

• Multi-factor authentication: At least two independent factors from knowledge, possession and inherence categories.
• Dynamic linking: Each payment transaction must be cryptographically linked to its amount and recipient details, with explicit user approval.
• Replay attack protection: Authentication data cannot be intercepted and reused; passkeys naturally comply since private keys never leave the device.
• Secure authentication elements: Mechanisms must be resistant to phishing, credential theft, and unauthorized access, encrypted and protected by hardware security modules.
• Low-risk exemptions: Transactions below €30, recurring payments, trusted beneficiaries, and low fraud-risk payments may be exempt from SCA.

Passkeys align with all RTS requirements through built-in multi-factor authentication, public-key cryptography, phishing resistance, and hardware-backed security.

How does the EBA Single Rulebook Q&A clarify SCA ambiguities?#

The EBA Single Rulebook Q&A provides official interpretations of PSD2's SCA requirements, clarifying: (1) MFA factor independence (2) exemptions and how Transaction Risk Analysis applies for low-risk payments, (3) dynamic linking requirements confirming cryptographic signatures must link transaction details to authentication, (4) that biometrics must be combined with another factor for SCA compliance and (5) that SCA must be applied uniformly across EU member states.

What are best practices for PSD2-compliant passkey integration?#

Key best practices include: implementing MFA, ensuring dynamic linking through WebAuthn signatures binding transaction details, using WebAuthn origin verification for phishing protection, storing passkeys in hardware security modules (Secure Enclave, TPM, TEE), implementing Transaction Risk Analysis for low-risk exemptions and ensuring cross-platform compatibility via iCloud Keychain, Google Password Manager or third-party managers.

What is SCA and why is it essential under PSD2?#

Strong Customer Authentication (SCA) is a PSD2 requirement mandating multi-factor authentication for electronic payments to enhance security and reduce fraud. It requires at least two of three factors: knowledge (password/PIN), possession (smartphone/security key) and inherence (biometrics). SCA is required for online payments, bank account access and high-risk actions.

Why are enterprises using passkeys for payment authentication?#

Enterprises adopt passkeys for payment authentication because they provide strong protection against phishing and credential-based fraud through public-key cryptography, enhance user experience with faster biometric-based checkouts (reducing cart abandonment), support dynamic linking through WebAuthn signatures binding authentication to transaction details, lower costs compared to SMS-based OTP authentication and work seamlessly across devices and platforms.

5. Conclusion#

We have taken a deep look how the definitions, specification and market opinions about SCA authentication methods have evolved and what the standpoint of the regulators are to understand what ruleset we have to apply to find out how what the SCA requirements mean for passkeys in our third pard of the series.

Here are the links to the other parts of our series:

• Part 1 “Device-Bound vs. Synced Passkeys (SCA & Passkeys I)"
• Part 3 "What SCA Requirements Mean for Passkeys (SCA & Passkeys III)
• Part 4 "PSD3 / PSR Implications for Passkeys (SCA & Passkeys IV)"