Passkeys and PSD2 Strong Customer Authentication

Strong customer authentication asks for two independent elements and, for payments, a cryptographic binding between the authorisation and the transaction it authorises. A passkey ceremony supplies the authentication half cleanly; the binding and the disclosure around it remain application work. This page covers where each requirement lands and what a compliant implementation actually has to build. It sits under Enterprise Policy and Compliance Controls.

Requirement Reference

Requirement Supplied by Still to build
two independent elements possession plus authenticator verification evidence that verification occurred
replay resistance single-use challenge atomic consumption and expiry
dynamic linking — transaction-derived challenge
user disclosure — amount and payee shown at approval
exemptions — policy and audit trail

The two empty cells in the middle column are the whole of the payments-specific work.

The three elements, and where a passkey sits A passkey supplies possession and, where the authenticator verifies a user, inherence or knowledge. Two elements from one ceremony — but the flag does not distinguish them possession the non-exportable private key held by the authenticator inherence a biometric verified by the authenticator, reported as the UV flag knowledge a device PIN, also reported through the same flag the gap the flag does not say which of the two was used

Root Cause Analysis

1. Treating the ceremony as sufficient. A passkey assertion proves someone with the credential approved something. Without a transaction-derived challenge it does not prove what they approved, which is exactly what dynamic linking exists to establish.

2. Deriving the challenge but not showing the transaction. The requirement has two halves: the authorisation must be bound to the amount and payee, and the user must be made aware of them. A cryptographic binding the user never saw satisfies one half of an obligation that has two.

3. Assuming the flag distinguishes biometric from PIN. It reports that the authenticator verified the user, not how. Where a framework distinguishes inherence from knowledge, the honest position is that the ceremony establishes one of them without saying which.

4. Ignoring the recovery path. An authentication regime satisfied at sign-in and bypassed by a weak recovery flow has not achieved what it set out to, and this is the area assessors probe hardest in payments.

Dynamic linking for a payment The challenge is derived from the transaction, so the assertion authorises that transaction and nothing else. The requirement is a binding plus a disclosure transaction amount and payee challenge derived and stored with them ceremony signs over that challenge authorisation valid for this payment only The user must also be shown the amount and payee at the moment they approve — binding the challenge is necessary but not sufficient.

Step-by-Step Resolution

Step 1 — derive the challenge from the transaction

Bind the amount, the payee and a transaction identifier into the value you issue, and store them on the challenge record. The assertion then authorises that transaction rather than a session.

Step 2 — show what is being approved

Amount and payee, in the interface, at the moment the ceremony is triggered. The platform prompt cannot carry your transaction details, so the disclosure has to be on your page immediately before it.

Step 3 — consume the challenge against the transaction

At verification, look up the challenge, confirm it corresponds to the transaction being executed, and consume it atomically. A challenge redeemable against a different transaction defeats the binding.

Step 4 — require user verification for payments

Request it, check the flag, and refuse the authorisation if it is clear. This is the element the regime depends on, and the check is server-side.

Step 5 — record the evidence

Transaction identifier, challenge, credential, verification result and timestamp, in one record. This is what an assessment will ask to see.

Step 6 — design the exemptions deliberately

Low-value and recurring-payment exemptions are policy decisions with their own audit requirements, and they belong in the same table as the assurance requirements rather than scattered through payment handlers.

What still needs designing Passkeys answer the authentication half cleanly and leave two requirements to the application. Half the problem is solved; the other half is yours the ceremony gives you possession, cryptographically verification, reported as a flag replay resistance from the challenge phishing resistance from origin binding you must still build transaction-derived challenges the amount and payee disclosure exemption handling a recovery path of equivalent strength Dynamic linking in particular is entirely an application concern and is where most implementations fall short.

Verification and Testing

Assert that an assertion issued for one transaction cannot authorise another. Create two payments, obtain a challenge for the first, and attempt to complete the second with it. The attempt must fail at the challenge lookup, and this single test is the one that proves dynamic linking is implemented rather than intended.

Assert that an unverified ceremony cannot authorise a payment, using a virtual authenticator configured without user verification.

Assert the evidence record exists and is complete after a successful authorisation, because the record is the deliverable an assessment consumes.

Pitfalls

1. A session-wide “approved” flag. Lets any subsequent payment ride on one ceremony, which is precisely what dynamic linking forbids.

2. Showing the transaction after the prompt. The disclosure has to precede the approval, or the user approved something they had not seen.

3. Treating the recovery flow as out of scope. It is the path an attacker will use, and it is in scope in every assessment.

Frequently Asked Questions

Does a passkey satisfy two elements on its own?

Where the authenticator verified the user, the ceremony combines possession of a non-exportable key with a verification the device performed, which is the standard argument for a single multi-factor authenticator. Confirm the reading with whoever owns compliance, because the framework’s wording rather than the technology decides it.

How do I bind a challenge to a transaction?

Generate the challenge as normal from a cryptographically secure source, and store it alongside the transaction identifier, amount and payee rather than encoding those values into it. The binding is the stored association plus the check at consumption; embedding data in the challenge adds nothing and constrains its entropy.

Can the platform prompt show the amount?

No. The prompt is owned by the operating system and shows the relying party, not your transaction details. The disclosure must be on your own page immediately before the ceremony, which is why the requirement is an interface obligation as much as a protocol one.

What about recurring payments?

They generally fall under an exemption rather than requiring a ceremony per instalment, but the initial mandate is the authorisation that matters and should carry the full binding. Record the mandate with the same evidence as any other authorisation.

Does the flag tell me whether a biometric or a PIN was used?

No, and it is not intended to. It reports that the authenticator’s user-verification method succeeded. Where a framework distinguishes inherence from knowledge, describe what the flag establishes rather than claiming the stronger of the two.

How does this interact with a fallback path?

Any fallback must reach the same standard, including the dynamic linking. A payment authorised through a weaker path than the primary one is the gap most likely to be found, and the usual remedy is to hold the fallback to the same requirements rather than to remove it.

Designing the Approval Screen

Because the platform prompt cannot carry your transaction, the screen immediately before it becomes a regulated surface rather than a design detail, and it is worth treating as such.

Show the amount and the payee in the same visual weight as the confirm action, not as supporting text beneath it. The obligation is that the user is made aware of what they are approving, and an amount rendered in small grey type below a large green button does not obviously discharge it.

Trigger the ceremony from the confirm control itself, in the same handler. Any intermediate step — a summary page, an await on a network call that fetches the challenge — risks the user activation lapsing, and it also opens a gap between what was displayed and what was authorised if the transaction can change in between.

Keep the challenge and the transaction immutable together. Once a challenge has been issued for a payment, neither the amount nor the payee may change; if the user edits either, issue a new challenge and discard the old one. A mutable transaction with a live challenge is the shape that makes the binding meaningless.

Handle the refusal path as an ordinary outcome. A user who dismisses the prompt has not failed authentication; they have declined to approve a payment, and the interface should return them to the transaction with both the confirm action and any alternative still available. Routing that into a generic authentication error is both a poor experience and a misrepresentation of what happened, which matters when the event ends up in an audit trail.

Related