Biometric authentication and strong customer authentication (SCA) in digital transactions

The fundamentals of strong customer authentication

The second Payment Services Directive (PSD2) requires strong customer authentication (SCA) when a payer accesses their payment account online, initiates an electronic payment transaction or carries out any action through a remote channel that may imply a risk of fraud. Strong authentication is based on at least two elements from three categories:

Knowledge – something only the user knows, such as a PIN or password.
Possession – something only the user has, such as a device or an app bound to it.
Inherence – something the user is. Article 4(30) of PSD2 defines this category as part of strong authentication.

The elements must be independent of one another: the compromise of one must not weaken the reliability of the others. The technical details are set out in Commission Delegated Regulation (EU) 2018/389, commonly referred to as the SCA regulatory technical standards (RTS). Its Article 5 requires dynamic linking for remote payments: the authentication code must be tied to a specific amount and payee.

Biometrics have become part of everyday strong authentication, because fingerprint or face recognition on a smartphone is fast and familiar to users. Technically, however, it is essential to understand what biometric recognition actually proves and how it is combined with the possession element.

The EBA interpretation of authentication elements

On 21 June 2019 the European Banking Authority (EBA) published an Opinion on the elements of strong customer authentication. The Opinion gives examples of which methods may satisfy the requirements of each category and which do not.

Category	Examples that may satisfy the requirement	Examples that do not satisfy the requirement
Inherence	Fingerprint, face geometry, voice, iris and retina recognition, keystroke dynamics and behavioural traits such as the angle at which a device is held	Information transmitted via the EMV 3-D Secure protocol as such
Possession	Binding an app or browser to a device by means of a security chip or private key, one-time code generators and device-generated signatures	A mere app installed on a device without reliable binding, printed card details
Knowledge	Password, PIN, memorised swiping path	Email address or username

Two points from the Opinion are particularly important in practice. First, simply installing an app on a device does not make it a possession element; possession must be reliably verifiable, for example by means of a cryptographic key bound to the device. Second, a memorised swiping path counts as a knowledge element, even though it is entered on a touchscreen.

How on-device biometrics work

On modern phones and computers, biometric recognition usually takes place entirely within the device. The biometric template – the reference data derived from a fingerprint or face – is stored in the device's protected hardware, such as a dedicated security processor or a TPM chip. The template never leaves the device and is not made available to the service provider.

When the user authenticates, the device compares the captured feature with the stored template. A successful match does not in itself send any biometric data to the service provider; instead, it unlocks a private key stored in the same protected environment. The key is used to sign a challenge sent by the service provider, and the service provider verifies the signature using a previously registered public key.

In this model a single user gesture combines two elements: biometric recognition acts as the inherence element and the device-bound private key as the possession element. The independence of the elements rests on the fact that using the key requires both the physical device and a successful biometric match.

Biometric matching is always probabilistic. Authenticator settings balance false acceptances against false rejections: a strict threshold reduces the risk of misuse but increases the number of situations in which the genuine user is not recognised. Biometrics may also be targeted by spoofing attempts, such as replicated fingerprints or photographs. Modern authenticators counter these with presentation attack detection, which aims to distinguish a live user from an imitation. Because biometric recognition can fail, devices usually offer a PIN or password as a fallback. It is important for the service provider to know that in this case the key is unlocked with a knowledge element rather than an inherence element. This does not weaken strong authentication as long as two independent elements are satisfied.

Architecture note

The service provider cannot see which method the user employed to unlock the key. It is therefore important to check the user verification information returned with the signature and, where necessary, the attestation describing the characteristics of the device.

FIDO2 and WebAuthn

FIDO2 is a set of open standards consisting of the W3C Web Authentication specification (WebAuthn) and the FIDO Alliance Client to Authenticator Protocol (CTAP). WebAuthn defines how a web service and the browser communicate about authentication, and CTAP defines how the browser or operating system communicates with an authenticator, such as a phone or a security key.

The key security properties of FIDO2 are:

Public-key cryptography. Only the public key is stored on the server. A data breach on the server reveals nothing that could be used to authenticate as the user.
Origin binding. A key pair is created for a specific web service, and the browser binds the signature to the service's origin. As a result, authentication cannot be relayed through a counterfeit website, which makes the method phishing-resistant.
User verification. The authenticator response includes information on whether the user was verified, for example biometrically or with a PIN.
Device attestation. At registration, the authenticator can provide an attestation that allows the service provider to assess the authenticator type and its level of protection.

FIDO2 involves two ceremonies. During registration, the authenticator creates a new key pair for the service and returns the public key, which the service provider associates with the user's account. During authentication, the service provider sends a random challenge, the authenticator signs it with the private key and the service provider verifies the signature. Registration should take place only after the user has been strongly authenticated with an existing method, so that the new authenticator does not end up in the wrong hands.

Passkeys and the possession element

Passkeys are FIDO-based credentials designed to replace passwords. There are two main types:

Device-bound passkeys, whose private key never leaves a single device or security key.
Synced passkeys, which are copied between the user's devices via the platform's cloud service.

A device-bound key clearly corresponds to the EBA description of a possession element in which an app or browser is bound to a device by means of a private key. Synced passkeys are more complex, because the same key may be available on several devices. Whether a synced passkey satisfies the requirements of the possession element is a matter of interpretation that the payment service provider assesses on the basis of its own risk assessment and, where necessary, together with its supervisor. Synced keys are often complemented by device binding or other risk signals.

Dynamic linking and payment confirmation

Authentication alone is not enough for a remote payment. Under Article 5 of the SCA RTS, the payer must be made aware of the amount and the payee, the authentication code must be linked to them, and any change to the amount or payee invalidates the code.

With WebAuthn, dynamic linking can be implemented by having the service provider construct a challenge that is bound to the payment details, such as the amount, currency and payee. When the authenticator signs the challenge, the signature applies to that specific payment. If someone attempts to use the signature for a different amount or a different payee, verification fails.

The W3C Secure Payment Confirmation specification extends this idea: before signing, the browser displays the payment details to the user in its own view, independent of the web page, and the payment details are included in the signed data. In card payments, comparable principles are applied within the EMV 3-D Secure framework. Read more about authentication flows in the technology area Secure authentication protocols.

What the Payment Services Regulation changes

The forthcoming Payment Services Regulation (PSR) moves the rules on strong authentication into a directly applicable regulation. Based on the compromise text published in April 2026, the changes concern accessibility and outsourcing in particular:

Payment service providers must offer several free-of-charge authentication methods that are also suitable for persons with disabilities, limited digital skills or no smartphone.
Authentication must not depend on a single device or technology unless the user has agreed to this.
A combination of two inherence elements is accepted, provided their independence can be demonstrated to the competent authority.
A payment service provider must conclude a written agreement with any technical service provider that performs strong authentication on its behalf.

The final obligations and dates of application depend on the formal adoption and publication of the Regulation. A broader overview of the reform is available in the guide PSD3 and open banking.

Data protection, accessibility and an implementation checklist

Under Article 9 GDPR, biometric data constitute a special category of personal data where they are processed for the purpose of uniquely identifying a person. In the on-device model, where matching takes place on the user's device and the service provider does not receive the biometric template, the service provider's own processing of biometric data is minimal or absent altogether. The assessment must nevertheless be made case by case, and a data protection impact assessment is recommended for large-scale processing. See also the guide Financial data privacy in open banking.

Accessibility is an equally important design question. Not all users are able or willing to use biometrics, and biometric recognition may fail, for example because of a disability or environmental conditions. Every biometric path therefore needs an equivalent alternative.

Bind keys to the device and check the user verification information on every authentication.
Include the amount, currency and payee in the signed challenge and display them to the user before approval.
Define a position on synced passkeys and document the risk assessment.
Offer at least one authentication method that does not require a smartphone.
Design a controlled recovery path for lost or replaced devices.
Carry out a data protection impact assessment and record where biometric matching takes place.
Conclude written agreements with technical service providers involved in authentication.

Sources and further reading

Disclaimer

This guide has been prepared carefully from public sources, but regulation and service features change. Always check current information from official sources and the providers' own documentation. Corrections: support@brevixoo.com.