---
url: 'https://www.corbado.com/blog/psd2-passkeys'
title: 'PSD2 Passkeys: Phishing-Resistant PSD2-Compliant MFA'
description: 'Are passkeys the best form of phishing-resistant MFA that is compliant with PSD2 and SCA requirements? This blog post answers all the questions. '
lang: 'en'
author: 'Vincent Delitz'
date: '2023-02-07T00:00:00.000Z'
lastModified: '2026-08-28T12:01:23.800Z'
keywords: 'psd2, psd2-compliant'
category: 'Passkeys Strategy'
---
# PSD2 Passkeys: Phishing-Resistant PSD2-Compliant MFA
## 1. Introduction
In digital [banking](https://www.corbado.com/passkeys-for-banking), security and user experience no longer have
to be at odds. Passkeys merge the two factors introducing a
[phishing](https://www.corbado.com/glossary/phishing)-resistant MFA that aligns with PSD2 and SCA requirements.
Passkeys are the most secure and most user-friendly form of authentication that can be
implemented across [financial services](https://www.corbado.com/passkeys-for-banking). This leap forward comes at
a crucial time, as the banking industry grapples with implementing the **Revised Payment
Services Directive (PSD2)** - a regulatory framework designed to enhance the security and
competitiveness of the European [banking](https://www.corbado.com/passkeys-for-banking) sector.
**Passkeys** emerge in this context as not just a compliance solution but also as a great
form of innovation, promising to **deliver on PSD2's stringent requirements without
compromising on UX**. In this blog post, we analyze the nuances of PSD2 and its mandate
for **Strong Customer Authentication (SCA)** : it becomes clear that passkeys represent
the future of [phishing](https://www.corbado.com/glossary/phishing)-resistant MFA in
[banking](https://www.corbado.com/passkeys-for-banking).
## 2. What is PSD2?
PSD2 is a piece of legislation introduced by the European Union to revolutionize the
[payment](https://www.corbado.com/passkeys-for-payment) services and banking landscape in Europe. Its primary
**goals are to increase competition, enhance consumer protection, and foster innovation**
in the digital [payments](https://www.corbado.com/passkeys-for-payment) space. By mandating **open access** to
customer financial information to **approved third parties** (with the customer's
consent), PSD2 paves the way for a more integrated, efficient, and user-friendly financial
ecosystem. However, with great power comes great responsibility, and PSD2 addresses this
through its **focus on security** , particularly through the lens of **authentication
protocols**.
> PSD2 is a regulation that aims to transform EU [payments](https://www.corbado.com/passkeys-for-payment) by
> boosting competition, security, and innovation.
## 3. What is SCA?
At the heart of PSD2's security measures is the requirement for Strong Customer
Authentication (SCA), a protocol designed to drastically **reduce fraud and enhance the
security of electronic payments**. SCA is built on the principle that electronic
[payments](https://www.corbado.com/passkeys-for-payment) should not only be **seamless but also secure** enough
to withstand various threats. This authentication framework is **mandatory** for
[payment](https://www.corbado.com/passkeys-for-payment) service providers, banks, and electronic
[payment](https://www.corbado.com/passkeys-for-payment) gateways operating within the purview of PSD2.
> SCA is the authentication standard in the European banking sector.
### 3.1 Requirements of SCA
The implementation of SCA under PSD2 is defined by several critical requirements:
#### Multi-Factor Authentication (MFA)
Authentication must involve at least two elements from the following categories:
- **Knowledge:** Something only the user knows, such as a password or PIN.
- **Possession:** Something only the user possesses, like a mobile device,
[smart card](https://www.corbado.com/glossary/smart-card), or hardware token.
- **Inherence:** Something inherent to the user, including biometric identifiers like
fingerprints, facial recognition, or voice patterns.
#### Dynamic Linking
For each transaction, a unique authentication code must be generated that dynamically
links the transactions specific details, such as the amount and the recipients account
number.
#### Periodic Reauthentication
Users are required to re-authenticate at intervals, typically every 90 days, to maintain
access to online banking services. However, this requirement has been revised to optimize
the balance between security and convenience.
#### Transaction-Specific Authentication
SCA must be applied to all electronic transactions, ensuring the authentication is
specific to the amount and the payee, creating a unique signature for every transaction.
#### Risk-Based Analysis
Payment service providers should use a risk-based approach to apply SCA, where lower-risk
transactions may be exempted from SCA to streamline the payment process without
compromising security (notice the link to passkeys here already?).
#### Auditability
The entire authentication process must be traceable and auditable, with records maintained
to prove adherence to SCA requirements.
By introducing SCA, PSD2 has significantly raised the standard for transaction security in
the banking sector. In the following, we will focus on the different factors involved in
Multi-Factor Authentication (MFA). These factors have also impact on the
Transaction-Specific Authentication requirement (read more below).
### 3.2 Evolution of Banking Authentication
In the following, we'll present the different evolution stages of authentication in the
banking sector.
#### 3.2.1 PINs and TANs (since 1990s)
The authentication journey in the bank industry began with the use of **Personal
Identification Numbers (PINs)** and **Transaction Authentication Numbers (TANs)**.
Customers would receive a list of TANs, each to be used once for transaction verification.
This method, while revolutionary at the time, had its drawbacks, including the risk of TAN
lists being stolen or misused.
#### 3.2.2 Electronic and Mobile TANs (since 2000s)
As technology advanced, banks introduced **electronic TANs (eTANs)** and **mobile TANs
(mTANs)** , where TANs were generated and sent to the customer's mobile device via SMS.
This method improved security by linking the TAN to the device, but it also introduced new
[vulnerabilities](https://www.corbado.com/glossary/vulnerability), such as the **risk of SMS interception** and
the **inconvenience** of having to wait for and manage these messages. Until the
introduction of passkeys, SMS OTP still are considered the most comfortable
[2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication) option available for
banking from a UX point of view.
#### 3.2.3 Smart Cards and Token Devices (since 2000s)
To further enhance security, banks adopted **smart cards** and **token devices** that
generated unique codes for authentication. These hardware-based solutions offered a higher
level of security but also **added complexity and inconvenience** for customers, who now
had to carry an additional device.
#### 3.2.4 Biometrics and Mobile Banking Apps (since 2010s)
The latest evolution in
[banking authentication](https://www.corbado.com/blog/turkey-financial-regulations-authentication) includes
[**biometrics**](https://www.corbado.com/blog/passkeys-biometric-authentication)(fingerprint or facial
recognition) and **mobile banking apps** with built-in security features. These methods
aimed to balance security with convenience by leveraging the user's unique biological
traits and the ubiquity of smartphones. However, they also require customers to go through
the process of download and setting up an app for every bank separately that the user
uses.
| Authentication Method | Type | Description |
| --------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Passwords/PINs | Something the user knows | Traditional secret knowledge that can be easily implemented and widely understood. |
| SMS OTP (One-Time Password) | Something the user has | A temporary passcode sent to the user's phone, representing a possession factor. |
| Hardware Tokens | Something the user has | Physical devices that generate a one-time passcode for the user. Requires a native iOS / Android app by the bank. |
| Mobile App OTP | Something the user has | A passcode generated within a banking or authentication app, often secured with device binding. Requires a native iOS / Android app by the bank. |
| Biometrics | Something the user is | Use of fingerprint, facial recognition, or iris scanning usually as "shortcut within the app of the bank as local biometric unlock (e.g. Face ID). Requires a native iOS / Android app by the bank. |
| Push Notifications | Something the user has | Approval of transactions or login attempts through a mobile app notification. Requires a native iOS / Android app by the bank. |
### 3.3 Current Auth Challenges and Customer Struggles
Despite these advancements, customers still face significant inconvenience and frustration
with current [banking authentication](https://www.corbado.com/blog/turkey-financial-regulations-authentication)
methods and are at risk being targeted by fraudsters:
- **Complexity and Inconvenience:** The layering of multiple authentication steps, while a
boost for security, often translates to a cumbersome process for users. This complexity
is not just a minor inconvenience; it can deter customers from engaging with digital
banking services or other secure environments like
[call center security](https://supportyourapp.com/blog/call-center-security-best-practices/),
undermining the very purpose of digital transformation.
- **Device and Platform Dependency:** The shift towards mobile and
[biometric authentication](https://www.corbado.com/blog/passkeys-biometric-authentication) ties users closely
to their devices. This dependency creates a fragile link in case of theft. Also,
technical failures can render banking services inaccessible, leaving customers stranded.
- **Phishing Vulnerabilities:** Despite advancements, the phishability of authentication
factors remains a [vulnerability](https://www.corbado.com/glossary/vulnerability) which is not addressed by
SCA. Traditional factors like PIN, password, SMS OTPs, email OTPs can be compromised
through sophisticated [phishing](https://www.corbado.com/glossary/phishing) schemes, putting customer data and
finances at risk.
Until today, banks, especially traditional ones, continue to warn customers about the
significant risk of phishing.
> The most probable attack vector is not the theft of credentials or devices, but rather
> customers willingly giving up either both or the first authentication factor to
> fraudsters.
In the following section, we will explain how this works using a real example.
## 4. Phishing is Banking's Biggest Security Issue
[Phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed) have long been a significant threat to
the security of the banking sector, exploiting human psychology (social engineering) and
technological [vulnerabilities](https://www.corbado.com/glossary/vulnerability) to gain unauthorized access to
sensitive financial information. As banks have evolved their authentication, fraudsters
have adapted, devising sophisticated schemes to bypass security measures. Understanding
how phishing works, especially in the context of these commonly used authentication
methods, is crucial to recognizing the**urgency for non- phishable authentication
solutions like passkeys**.
### 4.1 Theory Behind Phishing Attacks
At its core, phishing involves tricking individuals into disclosing sensitive information,
such as login credentials or financial information, under the guise of legitimate
communication from their bank. This is typically achieved through the following steps:
1. **The Initiation:** Fraudsters send messages (often via email or SMS) that mimic
official bank communications, complete with logos and language that appear trustworthy.
These messages usually create a sense of urgency, claiming that immediate action is
required to resolve an issue or prevent account closure.
2. **The Deception:** The message contains a link to a fraudulent website that closely
resembles the bank's official online banking portal. Unaware of the deception, the
victim is led to believe they are accessing their bank's legitimate website.
3. **The Capture:** Once on the phishing site, the victim is prompted to enter their
authentication details, such as their PIN or to confirm a transaction with an OTP sent
via SMS. Believing they are interacting with their bank, the victim complies,
unwittingly handing over their credentials to the attackers.
4. **The Exploitation:** Armed with these details, fraudsters can then access the victim's
bank account, perform unauthorized transactions, or commit identity theft.
### 4.2 Real-World Example: Deutsche Bank Phishing Attack
Consider a scenario where a customer of Deutsche Bank receives an SMS alerting them that
their account will be deactivated. The message includes a link to a website to verify the
customers identity having deutschebank as parot of the URL including a matching SSL
certificate. This site, a precise replica of Deutsche Bank's login page (as you can see in
the screenshots below), prompts the customer for their online banking PIN and afterwards
asks for an SMS OTP in real-time (not visible in the screenshots due to security reasons).
Unbeknownst to the customer, entering this information on the phishing site allows
attackers to gain full access to their Deutsche Bank account and potentially transfer huge
sums of money to other accounts.
This is the phishing SMS with the prompt to regain access to the bank account (German
screenshots only available):
This is the phishing website by the attackers
([https://deutschebank-hilfe.info](https://deutschebank-hilfe.info)):
This is the original website for reference
([https://meine.deutsche-bank.de](https://meine.deutsche-bank.de)) that the attackers
copied almost perfectly (they only left the phishing warning on the bottom out):
Customers who are accustomed to logging in through this identical UI and using SMS OTP as
an authentication factor can easily fall victim to such attacks. There exists a
substantial ecosystem of open-source suites designed to focus on
[phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed) targeting OAuth or banking systems
(e.g., [https://github.com/gophish/gophish](https://github.com/gophish/gophish)) for
security research purposes. However, these systems can easily be adapted for malicious
purposes.
**Phishing in the banking sector becomes increasingly precise** with every data leak on
the dark web. Typically, payment information such as IBANs is also part of these leaks.
Although this information cannot be used to directly steal money, it can be utilized in
spear-phishing approaches where the attacker knows that the target is actually a customer
of the bank.
### 4.3 The Importance of Non-Phishable Authentication Factors
The critical flaw in the scenario above lies in the phishability of the authentication
factors: **both the PIN and the SMS OTP can be easily solicited** from the customer under
false pretenses. This [vulnerability](https://www.corbado.com/glossary/vulnerability) underscores the necessity
for authentication methods that cannot be compromised through social engineering or
[phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed).
**Non-phishable authentication factors, such as those enabled by passkeys** , offer a
robust defense against such schemes. Since passkeys do not rely on shared secrets that can
be disclosed, tricked out of a user, or intercepted, they fundamentally change the
security landscape. With passkeys, the authentication process involves cryptographic proof
of identity that cannot be replicated by fraudsters, eliminating the most common attack
vector in phishing.
> Passkeys are limited to be used only on the exact domain they have been registered with
> ([relying party](https://www.corbado.com/glossary/relying-party) ID). It is technically impossible to use them
> on a phishing domain or to send passkeys to an attacker.
### 4.4 How to Combat Phishing?
To effectively counter phishing threats, the banking sector must adopt a multi-faceted
approach that includes:
1. **Educating Customers:** Banks should continuously inform their customers about the
risks of phishing and how to recognize fraudulent communication.
2. **Implementing Non-Phishable Authentication:** Transitioning to authentication methods
that do not rely on information that can be solicited or intercepted, thereby closing
the door on many phishing attempts.
3. **Enhancing Fraud Detection Systems:** Utilizing advanced analytics and machine
learning to detect and prevent unauthorized transactions, even if phishers obtain some
form of authentication data.
While phishing remains a significant threat to the banking sector, the adoption of
non-phishable authentication methods like passkeys represents a critical step forward in
securing online banking against fraudsters. **By removing the weakest link the
phishability of authentication factors banks can significantly enhance the security of
their customers' assets and personal information.**
Until this day, the European Central Bank and local banking supervisory authorities (e.g.,
BaFin) have not taken a stance on whether
[passkeys, as a whole, would be classified as 2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
or how banks should use them.
In the next section, we aim to explain why we believe passkeys are PSD2 compliant.
## 5. Are Passkeys PSD2 Compliant?
In discussions with [stakeholders](https://www.corbado.com/blog/passkeys-stakeholder) from the payment, fintech,
and banking sectors, a recurring question surfaces: **Are passkeys PSD2-compliant, and can
they serve as the sole form of authentication in banking scenarios?** The relationship
between passkeys and the Revised Payment Services Directive (PSD2) in the European Union
is nuanced and demands a detailed exploration. To elucidate, passkeys are usually
categorized int two types: **Synced Passkeys (Multi-Device)** and **Non-Synced Passkeys
(Single-Device)** , each with distinct characteristics regarding PSD2 compliance:
| | Synced Passkeys | Non-Synced Passkeys |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
| **Device availability** | Multi-Device | Single-Device |
| **Managed by** | Operating System | Extra software necessary |
| **Private Key** | Uploaded to operating system cloud account
(e.g. iCloud Keychain, Google Password Manager) or 3rd party password manager
(e.g. 1Password, Dashlane) | Stays on the user's device |
| **Device Binding** | No | Yes |
| **Backed up** | Yes | No |
| **Traditional opinion on PSD2 Compliance** | No (?) | Yes |
Adhering to compliance is very important for regulated entities such as banks and
[insurance](https://www.corbado.com/passkeys-for-insurance) companies. However, policies on compliance can take a
long time to change. In the case of passkeys, **the major security advantage is their
non-phishability,** as customers cannot inadvertently disclose this information to
attackers.
## 6. Why Synced Passkeys are not a Risk
While passkeys significantly enhance security by being non-phishable, they do shift some
of the risk to the customer's cloud account, such as Apple
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain). This makes the cloud account a more
attractive target for attackers. However, **services like Apple iCloud have robust
security measures in place** , particularly for features that support passkeys.
Firstly, iCloud passkeys are contingent on
[two-factor authentication (2FA)](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
being enabled on the account, adding an extra layer of security. This means that even if
an attacker knows the customer's iCloud password, they would still require access to a
trusted device or phone number to receive the
[2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication) code.
Apple, and similarly Google for their accounts, invest substantial resources into securing
these cloud services. The security protocols for accounts that support passkeys in the
cloud are rigorous, rendering it**nearly impossible for unauthorized users to break in**.
This high security standard is maintained through constant updates and security patches
(and they also have introduced passkeys for their accounts, see this blog post).
Moreover, the theft of devices or cloud accounts, while a potential risk, is not the most
common vector of attack for banking applications. In the event of heightened security
needs, such as for suspicious transactions, banks could continue to use SMS OTPs as an
additional factor. By **replacing the PIN / password with passkeys** , the first
authentication factor becomes unphishable, significantly reducing the risk of successful
phishing attacks. A**third factor could be introduced for transactions** that are flagged
as suspicious, ensuring a robust security stance.
> While the attack surface may shift, the **overall security posture is strengthened**,
> making passkeys a compelling choice for regulated entities such as banks and
> [insurance](https://www.corbado.com/passkeys-for-insurance) companies seeking to enhance customer security
> without sacrificing usability.
## 7. How Neo-Banks Force the Hand of Regulators
Contrary to traditional (risk-averse) views on PSD2 compliance,
[Finom](https://www.corbado.com/blog/finom-passkeys) and [Revolut](https://www.corbado.com/blog/revolut-passkeys) have decided that
**protecting customer data is more important** and are therefore using passkeys, despite
the lack of a public European decision on how banking supervision should treat passkeys
with regard to PSD2 compliance. Neo-banks and fintechs like [Finom](https://www.corbado.com/blog/finom-passkeys)
and [Revolut](https://www.corbado.com/blog/revolut-passkeys) are challenging the status quo and, in doing so, are
influencing the regulatory landscape regarding the authentication measures prescribed by
PSD2.
By prioritizing the security and integrity of customer data, these fintech pioneers are
adopting passkeys even in the absence of explicit regulatory guidance from European
authorities. This proactive stance places the**onus on regulators to reassess their
compliance frameworks** in light of technological advancements that offer superior
security solutions.
[Finom](https://www.corbado.com/blog/finom-passkeys) and [Revolut's](https://www.corbado.com/blog/revolut-passkeys) bold move to
implement passkeys highlights a critical aspect of
[regulatory compliance](https://www.corbado.com/blog/cybersecurity-frameworks) it should not be about adhering to
standards rigidly but rather about achieving the underlying goals of those standards,
which, in this case, is the **utmost security of customer data and transactions**. By
choosing to prioritize data protection over a strict adherence to traditional compliance
models, these neo-banks are setting new benchmarks for the industry.
> By forcing the hand of regulators, these neo-banks are advocating for a paradigm shift
> in which compliance must evolve in tandem with emerging technologies that safeguard
> consumer interests more effectively.
## 8. What Regulatory Changes are Needed?
From a regulatory perspective, there is a pressing need for clarity and adaptation to
accommodate advancements like passkeys within the framework of PSD2 compliance. **We urge
the EU to take a definitive stance on passkeys,** recognizing them as a superior form of
multi-factor authentication (MFA) that aligns with the core objectives of PSD2 to fortify
security and reduce fraud in the digital payments ecosystem.
**Passkeys, by design, offer a robust, phishing-resistant authentication factor that
surpasses the security capabilities of most traditional MFA methods.** This not only
enhances security but also simplifies the user experience, addressing two critical aspects
of PSD2 compliance.
The EU's stance should evolve to reflect the technological advancements that redefine what
constitutes effective and secure authentication. By embracing innovations like passkeys
and incorporating them into the regulatory fabric, the EU can demonstrate its commitment
to both protecting consumers and fostering a forward-looking digital finance environment.
As the financial industry continues to innovate, it is upon regulators to provide clear,
progressive guidance that not only keeps pace with technological change but also
anticipates future developments. Neo-banks are currently leading the charge, but it is
ultimately the responsibility of regulatory bodies to ensure that the financial sector as
a whole can move forward securely and confidently into the future of digital banking.
## 9. Recommendation for Banks and Fintechs
The adoption of passkeys in the banking and fintech area stands out as a prime example of
innovation that significantly enhances both security and user experience. Throughout our
article, weve established the potential of passkeys as a forward-thinking authentication
solution that aligns with the stringent security demands of PSD2 while mitigating
prevalent threats such as phishing. Neo-banks / fintechs like Finom and
[Revolut](https://www.corbado.com/blog/revolut-passkeys) have set a _precedent by integrating passkeys_ into
their security frameworks, demonstrating their efficacy and customer-centric approach.
A three-step action plan for traditional banks could look as follows:
1. **Engagement with Local Regulators:** Traditional banks should proactively engage with
their local regulatory bodies and banking supervision authorities to discuss the
implementation of passkeys. This dialogue should aim to clarify regulatory positions
and pave the way for integrating passkeys within the existing compliance structure. By
taking the initiative, banks can contribute to shaping a regulatory environment that
supports innovative authentication methods.
2. **Learning from Neo-Bank Best Practices:** It's imperative for traditional banks to
observe and learn from neo-banks that have successfully implemented passkeys. Studying
these best practices will provide valuable insights into the operational, technical,
and customer service aspects of passkey deployment. This knowledge transfer can assist
traditional banks in crafting their strategies for adopting passkeys.
3. **Strategic Transition to Passkeys:** With regulatory clarity and an understanding of
best practices, traditional banks can develop a comprehensive plan for transitioning
customers to passkey-based authentication. This plan should include customer education
campaigns to explain the benefits and usage of passkeys, phased rollouts to ensure a
smooth transition, and continuous evaluation to address any challenges promptly.
Optimized [passkey creation flows](https://www.corbado.com/faq/optimize-passkey-creation-flows-mobile-desktop)
with post-sign-in nudges and intelligent
[passkey login](https://www.corbado.com/blog/passkey-login-best-practices) flows are critical to achieving the
50%+ adoption threshold where passwords can be phased out.
## 10. How Corbado can help
Moving from theory to practice, banks need tooling that bridges the gap between PSD2/SCA
regulatory requirements and real-world passkey deployment. [Corbado Connect](https://www.corbado.com/connect)
provides a
[passkey intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
layer that sits on top of your existing identity stack, with no user migration required.
[Video: Passkey intelligence](https://www.corbado.com/videos/connect/passkey-intelligence.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))
### Device Trust and SCA Factor Coverage
A key challenge for banks is proving that their passkey implementation actually satisfies
SCA's two-factor requirement across their entire user base. Corbado's Device Trust
dashboard provides real-time visibility into how each authentication method maps to SCA
factors, success rates and step-up avoidance rates.
For example, [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) achieve 99.1%
success rates with 0% step-up requirements (the "passkeys as-is" approach), while synced
passkeys combined with cookie/session binding reach 98.4% with only 3.2% step-up rates.
This data-driven approach lets banks demonstrate SCA compliance to regulators with
concrete metrics rather than theoretical arguments.
### Trust Policies for PSD2 Compliance
Banks can configure granular trust policies that control when passkeys can be created and
when [step-up authentication](https://www.corbado.com/glossary/step-up-authentication) is required, which
addresses the PSD2 possession factor debate directly. For instance, synced passkeys on new
or unrated devices automatically trigger
[step-up authentication](https://www.corbado.com/glossary/step-up-authentication), while
[device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) on known devices are trusted
without additional friction.
This policy-based approach means banks don't have to choose a single SCA interpretation.
They can apply stricter controls (cookie/session binding or step-up) where the risk
profile demands it, while keeping the experience frictionless for trusted device-bound
scenarios. The result: PSD2 compliance that adapts to your institution's risk appetite
rather than a one-size-fits-all approach.
> **Corbado's Position on PSD2/SCA and Passkeys:** Passkeys (both device-bound and synced)
> can be SCA-compliant. Each institution must own its SCA risk assessment, but the
> evidence is clear: passkeys inherently provide two SCA factors, possession (private key
> in hardware security module or cloud keychain) plus inherence (biometric) or knowledge
> (PIN). The "possession" debate is nuanced but resolvable, and the industry is landing in
> three approaches: (1) **Passkeys as-is** (e.g. Revolut, Finom), inherence plus
> possession via device with private key, (2) **Passkeys + cookie/session binding** (e.g.
> [PayPal](https://www.corbado.com/blog/paypal-passkeys), Comdirect), an extra possession signal for a
> conservative interpretation, (3) **Cryptographic binding (DBSC/DPoP)**, hardware-bound
> proof of possession and the strongest guarantee. No single "correct" interpretation
> exists yet. An outcome-based approach to SCA is needed, focusing on demonstrable
> phishing resistance rather than rigid factor categorization.
> [Dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) remains a separate requirement for
> payments even with passkeys.