Explore insights on SCA & PSD2 requirements & the EBA's role in enhancing payment security with dynamic linking by providing regulatory technical standards.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to keep you up to date on the latest developments in the industry.

Overview: Strong Customer Authentication with 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.

Become part of our Passkeys Community for updates and support.

Join

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?

#	Body	Document 2015/2366 (PSD2)	Content
1	EU Parliament	Directive 2015/2366 (PSD2)	Initial PSD2
2	EU Commission	Delegated Regulation 2018/389 (RTS)	Further specification of the law
3	European Banking Authority	Opinion 2018 Opinion 2019	Recommendations & guidelines for national regulators and market participants
4	European Banking Authority	Single Rulebook Q&A	Browsable Q&A of questions asked by market participants and answered by the EBA

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:

Word	Explanation
authentication	means a procedure which allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalized security credentials
strong customer authentication	means an authentication based on the use of two or more elements categorized as: knowledge (something only the user knows) possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data;
personalized security credentials	means personalized features provided by the payment service provider to a payment service user for the purposes of authentication

Word

Explanation

authentication

means a procedure which allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalized security credentials

strong customer authentication

means an authentication based on the use of two or more elements categorized as:

knowledge (something only the user knows)
possession (something only the user possesses)
inherence (something the user is)

that are

independent, in that the breach of one does not compromise the reliability of the others,
and is designed in such a way as to protect the confidentiality of the authentication data;

personalized security credentials

means personalized features provided by the payment service provider to a payment service user for the purposes of authentication

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.

SCA Factor	Regulatory Technical Standards (RTS) on SCA
RTS Article 6 Knowledge	Mitigate the risk that the elements are uncovered or disclosed to unauthorized parties Mitigation measures apply in order to prevent their disclosure to unauthorized parties
RTS Article 7 Possession	Adopt measures to mitigate the risk that the elements of possession are used by unauthorized parties Elements shall be subject to measures designed to prevent replication of the elements
RTS Article 8 Devices and Software linked to Inherence	Shall adopt measures to mitigate the risks that the elements categorized as inherence and read by access devices and software provided to the payer are uncovered to unauthorized parties (=meaning information about biometrics should be kept safe) At a minimum it shall be ensured that those devices and software have a very low probability of an unauthorized party being authenticated as the payer Elements shall be subject to measures ensuring that devices and software guarantee resistance against unauthorized use of the elements through access to the devices and the software
RTS Article 9 Independence	Elements of SCA above are ensured that the breach of one of the elements does not compromise the reliability of the other elements Adopt security measures when SCA elements or the final authentication code is used through a multi-purpose device to mitigate the risk which would result from this device being compromised For the purpose of the paragraph before the mitigation issues shall include separate execution environments a mechanisms to ensure that the software or the device has not been altered by the payer or by a third-party where alternations have taken place, bring mechanisms into place to mitigate consequences thereof

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.

SCA Factor	European Banking Authority (EBA) opinion regarding SCA
All	The EBA considers that the two factors need to belong to two different categories of authentication factors For instance, one element categorized as knowledge (such as a password) and one as inherence (such as fingerprints)

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:

SCA Factor	European Banking Authority (EBA) opinion regarding SCA (part of the recommendations therefore numbered)
Inherence	(#EBA2019.18) Biological and behavioral biometrics, relates to physical properties of body parts, physiological characteristics and behavioral processes created by the body, and any combination of these (#EBA2019.19) Inherence may include retina and iris scanning, fingerprint scanning, vein recognition, face and hand geometry (identifying the shape of the user’s face/hand), voice recognition, keystroke dynamics (identifying a user by the way they type and swipe, sometimes referred to as typing and swiping patterns), the angle at which the user holds the device and the user’s heart rate (uniquely identifying the user), provided that the implemented approaches provide a ‘very low probability of an unauthorized party being authenticated as the payer’
Possession	(#EBA2019.24) Possession does not solely refer to physical possession but may refer to something that is not physical (such as an app) Requirement to have adequate security features in place and provides examples of possession, such as algorithm specifications, key length and information entropy Requirement for provider to have mitigation measures to prevent unauthorized use and to have measures designed to prevent the replication of the elements. (#EBA2019.25) A device can be used as evidence of possession, will provided that there is a ‘reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device Evidence could, in this context, be provided through the generation of a one-time password (OTP), whether generated by a piece of software or by hardware, such as a token, text message (SMS) or push notification In the case of an SMS, and as highlighted in Q&A 4039, the possession element ‘would not be the SMS itself, but rather, typically, the SIM-card associated with the respective mobile number. (#EBA2019.26) Relying on mobile apps, web browsers or the exchange of (public and private) keys may also be evidence of possession, provided that they include a device binding process that ensures a unique connection between the PSU’s app, browser or key and the device. This may, for instance, be through hardware crypto-security, web-browser and mobile-device registration or keys stored in the secure element of a device. By contrast, an app or web browser that does not ensure a unique connection with a device would not be a compliant possession element.
Knowledge	(#EBA2019.32) Following elements could constitute a knowledge element: a password, a PIN, knowledge-based responses to challenges or questions, a passphrase and a emorized swiping path (#EBA2019.35) OTP that contributes to providing evidence of possession would not constitute a knowledge element for approaches currently observed in the market. Indeed, knowledge, by contrast with possession, is an element that should exist prior to the initiation of the payment or the online access
Combinations	(#EBA2019.42) Approaches in which device binding to an app is used in combination with a knowledge or inherence element (e.g. some mobile wallet approaches) is considered compliant (Interesting because the can be applicable to e-commerce apps with passkeys)

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.

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

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.

Why Are Passkeys Important For Enterprises?

Passkeys for Enterprises

Enterprises worldwide face severe risks due to weak passwords and phishing. Passkeys are the only MFA method that meets enterprise security and UX needs. Our whitepaper shows how to implement passkeys efficiently and what the business impact is.

Download the whitepaper

If you have questions, feel free to

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