Passkey rollout guide for banks

A passkey is a key pair created on the customer’s device. The private half is held in the device’s secure hardware and cannot be exported. The bank holds the public half against the customer record. Signing in means the bank issues a challenge and the device returns a signature, released only after the customer authorises with a face, fingerprint or device PIN.

Three properties matter to a bank. There is no shared secret, so there is nothing for a customer to disclose and nothing on your servers worth stealing. The credential is bound to your origin, so it cannot be exercised against a lookalike domain. And the signature can cover the transaction detail, not merely the session, which is what makes it usable for payment authorisation rather than only for login.

Enrolment rate is the single number that decides whether the programme delivers. A technically perfect integration with eight percent enrolment changes nothing about your fraud exposure.

The moment that works is immediately after a successful authentication by the existing method. The customer has just proved who they are, they are already holding the device, and the ask is one biometric prompt. Offer it there, explain it in one line in terms of what the customer gets — faster sign-in, no codes to wait for — and make declining possible but not the default path.

What does not work: burying enrolment in a security settings menu, presenting it as a security upgrade the customer must evaluate, or asking during onboarding when the customer is already carrying several other steps.

Recovery is the hardest part of a passkey programme and the part most often deferred. The scenario to design for is a customer with no access to any enrolled device.

Two things reduce the volume before you get there. Platform passkeys sync through the customer’s platform account, so a replacement handset of the same platform typically restores the credential with no involvement from you. And encouraging a second enrolled device — a tablet, or the web on a laptop — turns a total loss into an ordinary re-enrolment.

For genuine total loss, the recovery flow must be at least as strong as the credential it restores, or it becomes the attack path. Whatever identity proofing you already trust for a high-risk change is the right bar. What you must not do is let recovery collapse back to an SMS code, because that reinstates precisely the weakness the passkey removed.

The mobile app is the straightforward case: a platform authenticator on the device the app runs on. The other channels each need a decision.

• Web. A passkey already on the customer’s phone can authenticate a desktop browser session through a cross-device flow: the browser shows a QR code, the phone scans it, and proximity is confirmed before the signature is released. No separate credential is needed.
• ATM. The same cross-device pattern applies — the machine presents a challenge, the customer approves on their handset. This is where cardless withdrawal and passkeys converge, and it removes card skimming from the flow entirely.
• 3-D Secure. Card-not-present authentication can use the same credential through Secure Payment Confirmation, where the signed challenge includes the merchant, amount and currency shown to the customer.

Planning all four from one credential at the outset avoids the common outcome: a passkey login on mobile, and an OTP still propping up every other channel.

Passkeys remove credential theft. They do not remove a customer being manipulated into performing an action themselves, and your policy has to reflect that.

Decide which actions require a fresh signature rather than an existing session: adding a beneficiary, raising a limit, changing contact details, and payments above a threshold are the usual set. For money movement, bind the signature to the transaction detail so the approval cannot be transplanted onto a different instruction.

Risk signals still apply on top. A first-time device, an unusual location or an unusually large amount should still be able to force additional verification, exactly as they would have before.

Across the markets covered here, passkeys are assessed against four recurring expectations: multi-factor authentication on digital channels, resistance to interception, binding an authorisation to a specific transaction, and where credential data resides. Passkeys answer the first three by construction; residency is a deployment decision rather than a protocol one. Per-market wording and references are on the compliance pages.

Days 1–30 — integrate and decide.

• Integrate registration and authentication in the mobile app behind a feature flag.
• Decide and document the recovery flow, and who may run it.
• Agree the step-up policy and which actions require transaction binding.
• Confirm logging and residency against your market’s requirement.

Days 31–60 — pilot.

• Enable enrolment for a staff or volunteer cohort; measure enrolment and fallback rates.
• Run the recovery flow end to end with real support staff, not in a test harness.
• Brief the contact centre and give them a script for “it asked for my face”.

Days 61–90 — widen.

• Open enrolment to the retail base post-authentication.
• Make passkey the default path on enrolled devices, OTP as recovery.
• Extend to web via the cross-device flow.
• Review fallback rate per channel and plan the first OTP retirement.

FortAuth provides the enrolment, recovery, step-up and cross-device flows described here as built components rather than as a specification to implement, across mobile, web, ATM and 3-D Secure from one credential, with native SDKs for iOS, Android, web and Flutter plus a REST API.