Passkeys in banking: what replaces the password, and what does not

When a customer registers a passkey, the authenticator generates a key pair for that one service. The W3C Web Authentication recommendation, a W3C Recommendation since April 2021, states that the credential private key is bound to a particular authenticator and is expected never to be exposed to any other party, while the public key goes to the relying party, which stores it. At login the service sends a challenge, the authenticator signs it, and the service verifies the signature against the stored public key.

The consequence for a bank is a database that is no longer worth breaching for credentials. A stolen table of public keys authenticates nobody. Compare that with a password file, where the whole value of the breach is that the stored material is the same material the customer presents, and you see why the FIDO Alliance describes the move as removing the shared secret instead of protecting it better.

Two specifications meet in one login. WebAuthn is the browser-facing API: the bank's web application calls it, and the browser handles the ceremony. CTAP, the Client to Authenticator Protocol from the FIDO Alliance, is how the browser talks to an authenticator that is not built into the device, a security key over USB or NFC for instance. The W3C specification references CTAP in its dependencies and requires the CTAP2 canonical CBOR encoding form, which is the seam between the two.

A platform authenticator, the phone or laptop's own secure element, is reached through the same WebAuthn call without the external protocol. For an engineering team that means one integration covers both cases, which is a real difference from the era when every token vendor shipped its own middleware. For a security team it means the questions about the authenticator move from the integration to the device.

The credential is scoped to a relying party identifier, and the W3C specification is explicit: a public key credential can only be used for authentication with the same entity, identified by that RP ID, it was registered with. The browser tells the authenticator which origin is asking, and an authenticator presented with an origin that does not match simply has no credential to offer.

Hold that against a one-time code. A customer on a convincing fake page reads the code aloud or types it in, the attacker relays it to the real bank within its validity window, and the control has been defeated by a customer who followed instructions. The passkey cannot be relayed, because the attacker's domain is not the registered one, and no amount of persuading the customer changes that. The BSI describes this class of credential as phishing-resistant for exactly this reason.

A device-bound passkey stays on the authenticator that created it. Lose the device and the credential is gone, which is clean for a security argument and hard on a support line. A synced passkey is backed up through the customer's platform account and appears on their other devices, which is why adoption works at all: a customer who replaces a phone does not have to register again with every bank.

The question a bank has to answer is what the syncing does to the possession factor it is relying on. If the credential can appear on a new device because someone signed into a platform account, then the thing the bank possesses evidence of is partly that platform account. The EBA sets the factor requirements that this argument runs into, and strong customer authentication covers the rule and its categories. The practical answer most institutions reach is to accept synced passkeys for low-risk access and require something else for the operations that move money.

A customer will lose the authenticator, and whatever you do then becomes your real security level. If the recovery path is a phone call to a help desk that asks for a date of birth, the attacker who cannot phish the passkey will phone instead, and the whole investment reduces to the quality of that conversation. NIST SP 800-63B treats authenticator binding and the replacement of a lost authenticator as part of the authentication design, not as an operational afterthought.

The designs that hold up share a shape: register more than one authenticator while the customer still has access, so a loss is a routine event instead of a crisis, and make the recovery path at least as strong as the credential it replaces. The BSI guidance on authentication points the same way. If recovery is weaker, state that plainly in the risk assessment, because an auditor will find it.

In a delegated model, a merchant or a wallet performs the authentication and the issuer accepts the result, instead of putting the customer in front of their own bank. For the customer that removes a jarring handover in the middle of a purchase; for the issuer it means relying on a check someone else ran, under a contract that says what the check had to be.

This is where a passkey already held at the merchant becomes interesting to the issuer, and it is also where the liability conversation starts, since the party that performed the check and the party that carries the loss are no longer the same. Card payments in Germany covers the commercial side and PSD3 and the PSR the legislative direction.

Customer login is the half everyone discusses; employee access is where an account takeover does the most damage, because an administrator's credential opens more than a customer's. The same FIDO2 credential works there, and it removes the attack that most often starts an incident: an employee persuaded to authenticate on a page that is not the bank's.

DORA puts access rights and identity management among the ICT protection duties a European financial entity owes, so this is a regulated area and not a hygiene project. Zero trust in banking covers the architecture that assumes a credential will be stolen anyway, and machine identity in banking covers the credentials no employee ever logs in with.

It can be, when unlocking the authenticator requires a biometric or a PIN: the registered device is one element and the fingerprint or PIN that releases the key is a second. Whether a supervisor accepts a particular implementation as two independent elements depends on how the key is held and synced, which is why the synced-versus-device-bound question is not academic. The rule and its categories are on strong customer authentication.

With a device-bound passkey, that credential is gone and the customer needs the recovery path. With a synced passkey, it reappears on the next device the customer signs their platform account into, which is why synced keys carry adoption and also why a bank has to think about what that platform account is worth to an attacker. Either way, a second registered authenticator turns the loss into a minor event.

The credential cannot be, but the customer can. A passkey stops the attacker from capturing something reusable at login; it does nothing about a caller who persuades the customer to make a payment themselves. Those are different controls, and fraud prevention in Germany covers the payment side.

Yes. A platform authenticator built into a phone or laptop is reached through the same WebAuthn call, so most customers never hold a separate key. External keys over USB or NFC use CTAP and remain useful where the credential has to be separable from the device, which is a common choice for administrator access.