This site is an interactive walkthrough for banks evaluating passkeys: the fraud and support-cost case, how the cryptography actually works, and a live registration and sign-in flow you can try right now, in this browser.
The problem
Both are shared secrets: something the bank sends and the customer types back. Anything typed back can be phished, replayed, or intercepted — and every failed attempt becomes a support call.
33%
A third of consumers surveyed in 2026 reported a confirmed account compromise or breach notification in the past year; in the US that rises to 41%.
FIDO Alliance, State of Passkeys 2026
80%
The large majority of basic web-application breaches trace back to a password or code that was phished, reused, or leaked elsewhere.
Verizon Data Breach Investigations Report, 2024
$200–4,500
Fraud losses plus remediation per incident is what makes phishing-resistant login a line item finance teams actually track.
Industry ATO cost benchmarks, cited in 2026 fintech passkey adoption research
How it works
At registration, the customer's device creates a fresh key pair for your bank. The private key never leaves the device; you only ever store the public half.
Bank server sends a random challenge and asks for a new credential.
navigator.credentials.create()The device prompts the customer for a fingerprint, face, or PIN — locally, on-device.
User verification, no data sent to the bankA new key pair is generated for this bank specifically. The private key is sealed in secure hardware.
Key pair scoped to the relying party IDOnly the public key and a credential ID are sent back and stored against the customer's profile.
Nothing secret ever left the deviceBank server sends a fresh, one-time challenge for this attempt.
navigator.credentials.get()The device confirms it's really the customer, then signs the challenge with the private key.
Signature is bound to your domain — unusable on a lookalike siteBank server verifies the signature against the stored public key.
No password, code, or secret was ever transmittedSession is granted. A phishing page pointed at the wrong domain simply cannot obtain a valid signature.
This is what "phishing-resistant" means in practiceThe business case
Figures below are publicly reported by the named organizations or aggregated in the 2026 FIDO Alliance and industry passkey research. Treat them as directional benchmarks for your own model, not guarantees.
reduction in mobile account-takeover fraud after passwordless rollout
CVS Health, 10M+ users
fewer authentication-related support tickets
Branch Insurance (Descope customer)
higher conversion on passkey sign-in vs. password sign-in
Dashlane
of mobile banking customers now authorize transactions with a passkey
ABANCA
average reduction in sign-in time after deploying passkeys
FIDO Alliance, State of Passkeys 2026
average reduction in login-related support tickets
FIDO Alliance, State of Passkeys 2026
active passkey adoption already reached across fintech and banking, the highest of any sector
2026 industry adoption benchmarks
login success rate for passkeys vs. traditional password methods
FIDO Alliance, State of Passkeys 2026
Side by side
| Password | SMS / voice OTP | Passkey (WebAuthn) | |
|---|---|---|---|
| Resistant to phishing | No | No — codes can be relayed | Yes — bound to your domain |
| Resistant to SIM-swap | N/A | No | Yes |
| Vulnerable to credential stuffing | Yes | Partially | No — nothing reusable to steal |
| Typical time to authenticate | 8–15 sec | 20–40 sec, plus delivery delay | 2–4 sec |
| Delivery cost per login | None | Carrier / SMS gateway fee | None |
| Works offline / no signal | Yes | No | Yes |
| Meets PSD2 strong customer authentication | Not alone | Only combined with another factor | Yes — inherence + possession in one step |
| Recovery if device is lost | Reset flow | Reissue SIM / number | Synced across the customer's devices, or re-enroll in-app / in-branch |
Try it yourself
This uses your browser's actual passkey prompt — Windows Hello, Touch ID, Face ID, or a security key — against a fictional bank, "FXdemo Bank." When the companion backend is running (a NokNok S3 FIDO2 server for the passkey, a OneSpan Authentication server for the Cronto step-up), every step below is verified by those real servers. Without it, the page falls back to a browser-only simulation.
Simulates a customer who just opened an account and is asked to secure it with a passkey instead of a password.
Simulates the same customer returning later and signing in with the passkey created above.
Create a passkey first.
Simulates a step-up challenge on a high-value payment: a Cronto-style visual code the customer scans, then a one-time code they type back to confirm.
Questions banks ask first
Not necessarily. A passkey already combines something-you-have (the device) with something-you-are-or-know (biometric or PIN), which is enough to satisfy strong customer authentication on its own. Most banks keep step-up options — a second passkey-backed device, or a fallback channel — for account recovery and high-risk transactions.
Passkeys created through a platform (iCloud Keychain, Google Password Manager, Windows Hello) sync to the customer's other devices, so a new phone often already has it. For a full device loss, banks typically fall back to an in-app re-verification flow or in-branch identity check — the same recovery path they'd need for a forgotten password, but used far less often.
No. Nearly every bank piloting passkeys runs them alongside existing methods, prompting passkey creation at natural moments — after a password login, during onboarding, or after a step-up challenge — and lets adoption climb before deprecating the old flow.
PSD2's strong customer authentication rules call for two independent factors, and FFIEC guidance points explicitly toward phishing-resistant methods. A passkey's on-device biometric check plus device-bound key satisfies both in a single customer gesture, which is why regulated fintechs have moved faster on passkeys than almost any other sector.
On the server side: storing a public key and credential ID per customer, and verifying signatures against fresh challenges — most identity platforms and several open-source libraries handle this. On the client side: calling the browser's WebAuthn API, as this page does. The heavier lift is usually enrollment UX and support-team training, not the cryptography itself.
Current-generation iOS, Android, Windows, macOS, and ChromeOS all support platform passkeys, and any customer can additionally use a physical security key. Coverage varies by exact OS and browser version, which is why most rollouts offer passkeys as an upgrade path rather than a requirement.