A passkey replaces a reusable password with a cryptographic credential. The customer proves control through an approved device or credential provider, while the secret needed to sign in is not sent to the bank.
The public and private keys perform different roles
When a passkey is created, the service keeps a public key and the user’s authenticator protects the corresponding private key. During sign-in, the authenticator signs a challenge that the service verifies with the public key.
The private key is not a password copied into a form or stored by the bank for later comparison. This design limits the value of stealing the bank’s public-key record and avoids sending a reusable shared secret during each login.
The customer unlocks the authenticator locally
A device may require a biometric, device PIN or another local action before using the private key. The local verification and the cryptographic proof serve different purposes: one unlocks the authenticator, and the other proves possession to the bank.
Implementation varies across devices and credential providers. A bank should explain what is stored, what may synchronize and which recovery options are available rather than implying that every passkey works in exactly the same way.
Binding the credential to the real service resists phishing
Passkey protocols bind authentication to the legitimate website or application. A fake site cannot normally reuse the signed response for the bank because the cryptographic proof is tied to a different verifier.
That makes a correctly implemented passkey resistant to common credential phishing. It does not prevent every form of fraud, such as social engineering that persuades a customer to approve a separate payment or disclose unrelated information.
Recovery and device changes remain important
Customers replace phones, lose devices and may use several platforms. Banks need recovery paths that restore legitimate access without creating an easier route for an attacker to take over the account.
Recovery may use synced credentials, another registered device or additional identity checks. High-risk recovery events can warrant stronger monitoring, waiting periods or limits until confidence in the customer’s identity is restored.
Sign-in is only one layer of banking security
A bank still monitors device changes, session behavior and unusual account activity after authentication. Sensitive actions may require confirmation that is distinct from the original sign-in.
A sound rollout also considers accessibility, customer support, fallback methods, account sharing and the risk of weaker alternatives. The security of the strongest method can be undermined if recovery or fallback is much easier to exploit.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.