Passkey Authentication for Banking: A Passwordless Migration Plan
Removing Passwords From a Bank Without Locking Anyone Out
Passkeys are the rare security improvement that customers actually prefer. Signing in with the same face or fingerprint that unlocks the phone is faster than typing a password and receiving a code, and the credential cannot be phished. The business case writes itself, and pilots consistently show both better conversion and lower support volume.
Then the programme meets reality. Some customers use browsers without good support, some share a household tablet, some lose the only device holding the credential, and every one of them needs a way in. So the password stays as a fallback, and the phishing route stays open along with it. Delivering passkey authentication banking value depends almost entirely on how you handle that fallback, not on the passkey implementation itself.
What is a passkey, technically?
A public key credential scoped to your service, held by an authenticator and unlocked locally by the customer.
The FIDO Alliance describes a passkey as an authentication credential based on FIDO standards, stored on a phone or computer, that lets a user sign in with the same biometric or PIN they use to unlock the device, and notes that passkeys are always strong and phishing-resistant because they use standard public key cryptography rather than shared secrets. Your server holds a public key. The private key stays with the authenticator. There is nothing on your side worth stealing and nothing on the customer's side that can be typed into a fake site.
What does the WebAuthn specification actually define?
Credential creation and use, attestation, user verification, and discoverable credentials.
The W3C Web Authentication Level 2 Recommendation, published in April 2021, defines asymmetric key pairs scoped to a specific relying party, with the public component returned to the service and the private component bound to the authenticator. It defines attestation to attest to the provenance of an authenticator and the data it emits, with several statement formats. It distinguishes user verification, the process by which an authenticator locally authorises the operation through a biometric, PIN, or equivalent, from simpler presence testing. And it supports both client-side discoverable credentials stored on the authenticator, usable without the service first identifying the user, and server-side credentials requiring the service to supply identifiers. Those four concepts are the vocabulary your design decisions will be expressed in, so agree them across security, product, and engineering before implementation starts.
Should you accept synced or device-bound passkeys?
Both, with different assurance levels attached to each.
FIDO distinguishes synced passkeys, backed up across a user's devices through platform services, from device-bound credentials including security keys that never leave one device and provide the highest level of assurance. Synced passkeys are what make mass adoption realistic, because they survive the device loss that would otherwise strand a customer. Device-bound credentials suit high-value corporate users and staff access. Record which type a credential is at enrolment, and let that inform your risk decisions rather than treating all passkeys as equivalent.
Are you planning a passkey rollout without deciding how synced and device-bound credentials will be treated differently?
What problems do passkeys solve, and what remains?
They eliminate phishing, credential reuse, and shared-secret theft. They do not address deception, recovery, or the call centre.
Credential stuffing stops working because there is no password to reuse. Phishing pages stop working because the credential will not respond to the wrong origin. Interception of one-time codes stops mattering where codes are no longer used. What remains untouched is a genuine customer being socially engineered into acting themselves, which is the intent problem covered in behavioural biometrics and device intelligence, and the recovery and human-channel paths that attackers pivot to once the front door closes, which is the chain analysed in account takeover prevention. Plan for that pivot as part of the programme rather than as a later surprise.
How should enrolment be designed?
Bound to an already-verified session, offered at a moment of natural friction, with the credential type recorded.
Only enrol a passkey from a session you already trust, since a passkey created during a takeover becomes the attacker's durable credential. Bind enrolment to a strongly authenticated session, and consider requiring step-up before creating the first credential. Then choose the moment carefully: the best conversion comes right after a customer has completed a successful login with the old method, particularly one involving a code they found tedious, because the value proposition is immediately obvious. Encourage a second credential on a second device from the start, as that single habit removes most future recovery cases. Presenting this well is a product design problem as much as a security one, and the adoption patterns in this guide to self-service portal design apply directly.
What should be recorded at enrolment?
Credential type, authenticator information where attestation is available, device context, and the session assurance that authorised it.
Store enough to make later risk decisions: whether the credential is synced or device-bound, what attestation reported if provided, the device and platform, and how strongly the enrolling session was authenticated. That record is what lets you require a device-bound credential for a high-value corporate action later, or treat a credential created during a low-assurance session with more caution. Without it, every passkey looks the same forever.
Why is fallback the whole problem?
Because your effective security level is set by the weakest path you still accept.
If a password and an SMS code remain available to every customer indefinitely, an attacker simply uses that path and your passkey rollout has improved user experience without improving security. That is the uncomfortable arithmetic of every passwordless programme.
How should fallback be narrowed over time?
By staging removal per segment, with a stronger alternative in place before each removal.
Start by hiding the password rather than removing it, so passkey becomes the default path for enrolled customers. Then restrict which actions a fallback session may perform, so a password login can view balances but not add a payee or change contact details. Then remove password access entirely for customers with two enrolled credentials on separate devices. Then work through remaining segments with supported alternatives, including hardware keys for those who want them and assisted routes for customers who cannot use any of it. Publish the sequence internally so product teams stop treating the password as permanent infrastructure. NIST's guidance is a useful anchor for the assurance reasoning here, particularly its insistence that biometrics are not secrets and must be used alongside a physical authenticator rather than alone.
How should account recovery work?
As re-proofing to the onboarding standard, with delay and notification, never as a convenience shortcut.
Recovery is the deliberate bypass, so hold it to a genuine evidence standard, add a delay before newly recovered access can perform sensitive actions, notify every previously known contact channel, and log the evidence chain. Offer a supported human or branch route for genuine customers who fail remote recovery, because a strict remote path without an alternative simply converts a security control into a complaints queue. This is also where decentralised and reusable identity approaches start to be genuinely useful, as explored in this guide to decentralised identity implementation.
Will your password remain available as a fallback indefinitely?
How do you handle device diversity and shared access?
By supporting multiple credentials per customer and designing explicitly for the awkward cases.
| Situation | Design response |
|---|---|
| Customer with one device only | Encourage second credential, offer hardware key, keep supported recovery route |
| Household or shared device | Multiple credentials on one device, clear per-user verification, never assume one device equals one person |
| Corporate users | Device-bound credentials, administrator-managed enrolment, separation from personal credentials |
| Older or unsupported platforms | Retain a defined alternative path with restricted capability rather than blocking |
| Device replacement | Synced credentials carry over, device-bound require re-enrolment from a trusted session |
| Device loss or theft | Immediate credential revocation, then recovery as re-proofing |
Support several credentials per customer from day one. Single-credential designs look simpler and generate the majority of recovery load, which is the expensive part of running this at scale.
Should attestation be required?
Request and record it, but do not make it a hard gate for consumer customers.
Attestation tells you what kind of authenticator produced a credential, which is genuinely useful for assurance decisions and for corporate device policy. It is also inconsistently available across consumer platforms, so a strict requirement will block legitimate customers on common devices. Ask for it, store what you receive, use it to inform whether a credential qualifies for high-value actions, and reserve hard attestation requirements for staff and corporate populations where you control the estate.
How does this interact with regulatory authentication requirements?
Passkeys generally map well onto strong authentication requirements, and the mapping must still be confirmed per jurisdiction.
Most strong customer authentication frameworks require elements from separate categories, and a passkey with user verification typically satisfies possession of the authenticator combined with an inherence or knowledge element resolved locally. That is a favourable position, and it is not something to assume. Take the specific mapping to your compliance function per market, document it, and record the evidence your logs retain to demonstrate it, because the audit question will be about what you can prove rather than what you designed. Server-side, the credential store and its protection belong in the same key management regime as your other cryptographic material, which is covered in HSM and key management architecture.
How should rollout be sequenced and measured?
Staff first, then a digital-native segment, then broad rollout, then fallback removal, measured on adoption and support load.
| Phase | Duration | Deliverable |
|---|---|---|
| Internal and staff rollout | 1 to 2 months | Real-world validation on a controlled population |
| Consumer pilot | 2 months | Enrolment flow, conversion measurement, support readiness |
| Broad availability | 2 to 3 months | Default path for supported platforms, multi-credential support |
| Action-based fallback restriction | 1 to 2 months | Password sessions limited to low-risk actions |
| Segment-by-segment password removal | 3 to 6 months | Removal where two credentials exist, alternatives for the rest |
| Recovery hardening | Ongoing | Re-proofing standard, delays, notifications, assisted routes |
Measure enrolment rate by segment and platform, authentication success rate compared with the old method, support contacts per thousand authentications, recovery volume and its causes, the share of sessions still using fallback, and the share of customers holding two or more credentials. That last metric is the leading indicator for everything else, since it determines how fast you can remove the password. Identity lifecycle plumbing underneath all of this is the subject of this guide to modernising identity and access management.
Passkeys are worth doing on customer experience grounds alone, and they only improve security to the extent that you eventually close the paths they replace. Plan the rollout as a fallback removal programme with a passkey deployment attached, and the security benefit follows.
Frequently Asked Questions
What is a passkey?
A public key credential based on FIDO standards, stored on a device and unlocked with the same biometric or PIN used to unlock that device, replacing a password with a cryptographic key pair.
Why are passkeys phishing-resistant?
Because the credential is scoped to a specific relying party and the private key never leaves the authenticator, so there is no shared secret an attacker can capture and replay.
Should a bank accept synced or device-bound passkeys?
Both, with different assurance. Synced passkeys drive adoption because they survive device loss, while device-bound credentials give the highest assurance for high-value actions.
What is the difference between user presence and user verification?
Presence confirms someone interacted with the authenticator. Verification confirms the authenticator locally authorised the specific user through a biometric or PIN, which is what a bank should require.
Why is fallback the hardest part of a passkey programme?
Because your effective security equals your weakest available path. Retaining a password or SMS code as fallback leaves the phishing route open regardless of passkey adoption.
How should account recovery work in a passwordless bank?
As re-proofing against the same evidence standard as onboarding, with a delay before sensitive actions and notification to previously known contact details.
Do passkeys satisfy regulatory strong authentication requirements?
In most frameworks they map well to possession plus inherence or knowledge, but confirm the mapping with your compliance team per jurisdiction rather than assuming it.
Should attestation be required at enrolment?
Request it and record it, but avoid hard requirements that block common consumer platforms. Use attestation to inform assurance decisions rather than as a gate.
