Does a FIDO2 biometric on a smartphone satisfy PSD2 SCA factor independence?

It can, but only if the biometric matching occurs in a hardware-isolated environment such as a Trusted Execution Environment or Secure Element, and the device carries a relevant security certification. The EBA's position is that a single device can provide both possession and inherence factors provided those factors are processed by independent hardware components. Server-side biometric matching does not satisfy this requirement.

How do you implement dynamic linking with a WebAuthn assertion?

The bank computes a SHA-256 hash of a canonical transaction object containing the payment amount, payee IBAN and timestamp, then embeds that hash in the WebAuthn challenge before requesting the assertion. The authenticator signs the challenge as part of the client data, cryptographically binding the authentication act to the specific transaction parameters. The relying party must verify both the assertion signature and the challenge content server-side.

What is the 90-day SCA exemption and how does FIDO2 affect it?

The RTS on SCA allows account information service providers to omit re-authentication for read-only access if the user performed SCA within the prior 90 days and gave explicit consent. Under a FIDO2 deployment, the session token must record the specific credential ID and AAGUID from the original assertion. If the user registers a new FIDO2 credential, for example after device replacement, the exemption clock restarts for that new credential.

What is DPoP and why does it matter for FIDO2 and open banking APIs?

DPoP (Demonstrating Proof of Possession) is an OAuth 2.1 mechanism that cryptographically binds an access token to a specific public key held by the client, preventing token theft attacks in third-party API integrations. When a bank issues access tokens after a FIDO2 SCA step, binding those tokens via DPoP ensures the token cannot be replayed by a different client. This pattern is recommended in the FAPI 2.0 Security Profile that underpins European open banking security requirements.

How should banks maintain FIDO2 attestation compliance over time?

Banks should maintain a verified device registry that maps AAGUID values to FIDO Alliance certification status, sourced from the FIDO Alliance Metadata Service (MDS3). This registry must be refreshed at least quarterly because authenticator models can lose certification status. When a credential type loses certification, existing sessions tied to those credentials may require re-evaluation under the EBA's factor independence requirements.

PSD2 SCA and FIDO2: Passwordless Banking Compliance

PSD2 Strong Customer Authentication reshaped how European banks think about identity verification. The Regulatory Technical Standards published under PSD2 defined a precise three-factor model and a dynamic linking requirement that most banks initially solved with SMS OTPs and hardware tokens. In 2026, the question is no longer whether FIDO2 can satisfy SCA. It is whether banks are implementing the interaction correctly.

This article examines the technical intersection of PSD2 SCA requirements and FIDO2/WebAuthn standards, with particular attention to dynamic linking, session management under exemptions and the open banking API surface where most of the implementation risk lives.

The SCA Baseline: What PSD2 Actually Requires

Article 97 of the revised Payment Services Directive requires payment service providers to apply strong customer authentication whenever a payer accesses a payment account online, initiates an electronic payment transaction or carries out any action through a remote channel that may imply a risk of payment fraud.

The Regulatory Technical Standards on SCA and Common and Secure Open Standards of Communication (commonly called the RTS on SCA) specify that authentication must use at least two independent elements drawn from three categories: knowledge (something only the user knows), possession (something only the user has) and inherence (something the user is). The elements must be mutually independent, meaning a breach of one must not compromise the other.

That independence requirement is where many early FIDO2 deployments introduced compliance risk. A WebAuthn credential stored on a device satisfies the possession factor. A biometric verification on the same device satisfies inherence. But if the biometric check is performed entirely in software without a Trusted Execution Environment or a certified Secure Element, the EBA has historically questioned whether the two factors are genuinely independent. The hardware attestation model in FIDO2 is the answer to that concern, and it is worth understanding precisely why.

FIDO2 and WebAuthn Architecture in Banking Contexts

FIDO2 is the umbrella specification published by the FIDO Alliance. It encompasses two components: the Client to Authenticator Protocol (CTAP) which defines how an authenticator communicates with a client platform, and WebAuthn, which is a W3C standard that defines how relying parties (banks, TPPs) interact with the authenticator through a browser or native app.

From a compliance engineering perspective the relevant properties of FIDO2 are as follows.

Attestation: During registration, the authenticator produces a signed attestation statement proving its model and certification level. For banking SCA, FIPS 140-2 Level 2 or FIDO2 Level 2 certified authenticators with bound biometric verification provide the hardware-level isolation the EBA requires for factor independence.
Origin binding: WebAuthn credentials are cryptographically bound to the relying party origin (the bank domain). Credential phishing is structurally prevented because the key material cannot be exercised on any other origin.
Resident keys: FIDO2 resident credentials (discoverable credentials) stored in authenticator secure memory remove the need for a username enumeration step, reducing attack surface before authentication begins.
User verification: The UV flag in the authenticator data structure signals whether the authenticator itself verified the user biometrically or via PIN before releasing the private key. Relying parties must assert userVerification: "required" in their PublicKeyCredentialRequestOptions to enforce this.

Fintech engineers deploying WebAuthn for banking must configure the authenticator selection criteria to require platform authenticators with user verification and attestation conveyance set to "direct" or "enterprise" so that the bank retains the attestation certificate chain for audit and for EBA compliance evidence.

Dynamic Linking: The Hardest SCA Requirement to Satisfy Passwordlessly

Article 5 of the RTS on SCA introduces dynamic linking. For payment transactions, the authentication code generated must be specific to the amount and the payee that the payer agreed to at the time of initiation. If either the amount or the payee changes, the authentication code must be invalidated.

This is the most technically demanding SCA requirement and the one most often implemented incorrectly in FIDO2 deployments.

Standard WebAuthn assertions sign the client data hash, which includes the challenge sent by the relying party and the origin. The challenge is the mechanism through which dynamic linking is implemented. The bank must embed a cryptographic commitment to the transaction amount and payee IBAN directly in the challenge before requesting the WebAuthn assertion. When the authenticator signs the assertion, it is signing over a challenge that encodes the specific transaction parameters.

A compliant implementation looks like this at a high level:

The bank constructs a canonical transaction object: {amount: "120.00", currency: "EUR", payee_iban: "DE44500105175407324931", timestamp: "2026-03-14T10:22:00Z"}
The bank computes a SHA-256 hash of the canonical transaction object.
That hash is incorporated into the WebAuthn challenge sent to the client.
The client passes the challenge to the authenticator via the WebAuthn API.
The authenticator signs the client data, which contains the challenge.
The bank's relying party verifies the signature and also verifies that the challenge encodes the correct transaction parameters for this session.

What must not happen is the separation of authentication from transaction authorization. If the bank issues a general WebAuthn assertion to confirm user identity and then separately records transaction consent without tying the two cryptographically, dynamic linking fails. This architecture mistake was common in early open banking implementations and remains a finding in PSD2 compliance audits.

Session Management Patterns Under SCA Exemptions

The RTS on SCA includes transaction risk analysis (TRA) exemptions and a 90-day re-authentication exemption for account information services. These exemptions create session lifecycle complexity that intersects with how WebAuthn credentials are managed.

The 90-day exemption for account information access allows a payment service provider to omit SCA for read-only account access if the user has performed SCA within the prior 90 days and provided explicit consent. The practical implication is that the bank must maintain a session token or authorization grant linked to a specific WebAuthn credential assertion that occurred within the 90-day window.

Session tokens in this context must carry the authenticator AAGUID and the credential ID from the original FIDO2 assertion so that the bank can verify, on any subsequent access, that the exemption was established by a specific certified authenticator. If the user registers a new FIDO2 credential (for example after a device replacement), the prior exemption period is invalidated for that new credential.

For TRA exemptions, the bank must maintain real-time fraud scoring that processes behavioral signals, device fingerprinting and transaction history. This is where federated fraud intelligence and privacy-preserving machine learning become relevant: banks participating in shared fraud detection networks can improve TRA model accuracy without exposing raw transaction data. The principles around consent-based data sharing explored at ownmydata.ai apply directly here, since TRA data sharing between banks implicates both GDPR and PSD2 data minimization obligations.

EBA Opinions and Regulatory Interpretation of FIDO2

The European Banking Authority has issued several opinions and Q&. A clarifications that directly address biometric and FIDO2-based SCA implementations. Key positions as of 2026 include the following.

The EBA confirmed that a biometric element qualifies as an inherence factor only if it meets reliability thresholds: false acceptance rates must be sufficiently low to resist spoofing attacks and the biometric matching must occur in a protected environment. FIDO2 platform authenticators with TEE-backed biometric matching on certified devices satisfy this requirement. Server-side biometric matching, where a biometric template is transmitted and verified remotely, introduces channel risk and weakens the independence argument.

The EBA also addressed the question of whether a single device can satisfy both possession and inherence simultaneously. The authority's position is that it can, provided the two factors are processed by independent components within the device (for example a Secure Element handling key storage separately from the biometric sensor and matching logic) and the device carries a relevant security certification.

For engineers this means the attestation certificate chain from the FIDO2 authenticator is not just a nice-to-have. It is the auditable evidence that the device meets the EBA's requirements for factor independence. Banks should maintain a verified device registry mapping AAGUID values to certification status and refresh this registry against the FIDO Alliance Metadata Service (MDS3) periodically.

Implementation Patterns for Compliant Passwordless SCA

Bringing together the regulatory requirements and the FIDO2 technical model, a compliant passwordless SCA implementation for a European bank or third-party payment provider has the following structural characteristics.

Registration Flow

Require attestation conveyance "direct" or "enterprise" during credential creation.
Verify the attestation certificate chain against FIDO Alliance MDS3 at registration time.
Store the AAGUID, credential ID, public key and certification level in the user's credential record.
Enforce authenticator selection: authenticatorAttachment: "platform" for mobile SCA, with userVerification: "required".
Record the registration timestamp for the 90-day exemption clock.

Authentication and Payment Authorization Flow

For account access: issue a standard WebAuthn challenge, verify the assertion and check that the credential was registered with a certified authenticator.
For payment transactions: embed the SHA-256 commitment of the canonical transaction object in the challenge before issuing it. Verify both the assertion signature and the challenge content on the server side.
Log the full assertion (client data JSON, authenticator data, signature) for audit purposes under PSD2 Article 16 record-keeping obligations.

Credential Lifecycle

Implement credential revocation endpoints that invalidate all FIDO2 credentials on confirmed device compromise reports.
Support CTAP 2.1 credential management so users can enumerate and delete credentials from the bank's application without going through a full re-registration flow.
Re-validate AAGUID certification status quarterly against MDS3 to catch credential types that lose certification status.

Open Banking APIs and WebAuthn Token Binding

Open banking under PSD2 introduces third-party providers (TPPs) that access bank APIs on behalf of users. The SCA obligation remains with the account servicing payment service provider (ASPSP), but the authentication user experience often occurs within the TPP's interface, redirecting to the bank for an SCA step.

WebAuthn token binding, which cryptographically binds an access token to a specific TLS session or public key, offers a mechanism to prevent access token theft in TPP integration flows. Though token binding at the TLS layer was deprecated in some browser contexts, the conceptual model survives in DPoP (Demonstrating Proof of Possession) under OAuth 2.1, which is the binding mechanism favored in current Open Banking specifications including the UK Open Banking Standard and Berlin Group's NextGenPSD2 framework.

A bank implementing FIDO2 SCA alongside open banking APIs should design the authorization server to issue DPoP-bound access tokens when a WebAuthn assertion is the SCA mechanism. The private key used for DPoP can be the same FIDO2 credential key if the implementation uses a FIDO2 credential for the OAuth assertion, or it can be a separately generated ephemeral key held in the same secure enclave. The latter approach is cleaner from a key separation perspective.

Implementation guidance from the OpenID Foundation's Financial-grade API (FAPI) 2.0 Security Profile, which is the basis for most European open banking security requirements, recommends this DPoP binding pattern for high-security API access. Engineers integrating FIDO2 SCA with open banking pipelines should align their authorization server implementation with FAPI 2.0 Message Signing and the corresponding JARM response mode to achieve full regulatory alignment.

For teams building or evaluating data portability and consent management layers on top of PSD2 APIs, the consent receipts and data flow audit tools described at mydatakey.org provide a practical reference for how FIDO2-authenticated sessions interact with user-controlled data access grants across TPP relationships.

PSD2 SCA compliance in 2026 is not a checkbox exercise. It is a distributed systems problem that spans cryptographic attestation, session lifecycle, fraud modeling and API security binding. FIDO2 and WebAuthn provide the right technical primitives. Getting the dynamic linking, the attestation audit trail and the DPoP token binding correct is what separates a compliant deployment from one that passes a surface-level review and fails under adversarial conditions.

PSD2 Strong Customer Authentication in the FIDO2 Era: Passwordless Compliance for European Banking