The short answer
Passkeys—built on the FIDO2 and WebAuthn standards—represent the most secure authentication mechanism available today. Unlike traditional passwords or SMS 2FA codes, passkeys use public-key cryptography bound strictly to a domain name, rendering them completely immune to credential phishing attacks, SIM swapping, and Man-in-the-Middle (MitM) proxy attacks.
However, while passkeys are widely adopted across tech platforms (Apple, Google, Microsoft), financial institutions have been slow to replace traditional mobile bank tokens and SMS 2FA. Regulatory requirements under PSD2 for explicit transaction signing and complex account recovery requirements explain why passkey adoption in retail banking remains gradual.
Why Passkeys Outperform Traditional Bank 2FA
| Authentication Factor | Phishing Vulnerable? | SIM Swap Risk? | MitM Proxy Vulnerable? | Hardware Token Needed? |
|---|---|---|---|---|
| SMS One-Time Password (OTP) | Yes (High) | Yes (High) | Yes | No |
| Authenticator App (TOTP) | Yes (Medium) | No | Yes | No |
| Bank Push Notifications | Yes (Prompt fatigue) | No | Partial | Mobile Device |
| FIDO2 / WebAuthn Passkeys | No (Immune) | No | No (Immune) | Built-in (Biometrics/Secure Enclave) |
The Cryptographic Mechanics of Passkey Security
Passkeys eliminate shared secrets (passwords) stored on bank servers:
- Domain Binding: During registration, your device (Secure Enclave / TPM) generates a unique cryptographic key pair for the specific bank domain (e.g.,
bank.com). The private key never leaves your physical device. - Challenge-Response Authentication: When logging in, the bank sends a cryptographic challenge. Your device prompts for local biometric verification (Face ID / Touch ID / Windows Hello) and signs the challenge with the private key.
- Phishing Immunity: If an attacker tricks you into visiting a phishing site (
bãnk-login.com), your browser checks the domain origin. Because the origin does not matchbank.com, the browser refuses to sign the challenge, rendering phishing pages completely ineffective.
Why Retail Banks Have Been Slow to Adopt Passkeys
Despite clear security advantages, financial institutions face three implementation barriers:
1. PSD2 Dynamic Linking Requirements
Under PSD2 Strong Customer Authentication (SCA) rules, high-value payment transfers require “Dynamic Linking”—the authentication code must be cryptographically bound to the specific transaction amount and recipient IBAN. While WebAuthn supports transaction confirmation extensions, legacy banking backend systems require major upgrades to support dynamic linking via FIDO2 natively.
2. The Account Recovery Dilemma
If a user loses all devices, recovering a passkey-only banking account requires fallback identity verification (video KYC, branch visits, or physical letter codes). Banks fear increased customer support costs if users accidentally lock themselves out of financial accounts.
3. Sync vs. Hardware-Bound Passkeys
Multi-device synced passkeys (stored in Apple iCloud Keychain or Google Password Manager) replicate across personal devices. Some bank security compliance teams express concern regarding synced passkeys on unmanaged family devices, preferring hardware-bound (non-exportable) security keys.
Current State of Passkey Adoption in European Banking
- Fintechs & Neobanks: Leading fintechs (such as Revolut and Wise) have begun offering passkeys for web login and device authorization.
- Traditional Retail Banks: European banks are currently deploying passkeys primarily for web portal login, while maintaining dedicated mobile banking apps for transaction signing.
Because support moves quickly and varies by market, treat any list of banks as a starting point rather than a current answer. The reliable check is your own bank’s security settings page, where the feature usually appears without being announced.
What passkeys do not protect against
The phishing immunity is genuine and it is narrow. Four things remain untouched.
Authorised push payment fraud. If you are deceived into making a payment yourself, you will authenticate it flawlessly with a passkey. The cryptography confirms you are you; it has no opinion on whether the person who called you was lying. This is now the dominant fraud type in several European markets and no authentication technology addresses it.
Malware on the authenticating device. A passkey protects the credential, not the session. Malware with sufficient privilege — on Android, typically through an abused accessibility service — can act inside your session after you have authenticated perfectly. See what app permissions actually grant.
Account recovery. If the recovery path still accepts an SMS code or a security question, an attacker simply uses that instead. The strength of your login is capped by the weakest route back in, which is the argument in account recovery is your real attack surface.
Fallback authentication left enabled. Many deployments add passkeys alongside the existing password and OTP rather than replacing them. If the old method still works, the attacker uses the old method. Adding a passkey to an account that still accepts a phishable factor improves your convenience and not your security.
That last point is the one most people miss, and it is worth checking deliberately: after enrolling a passkey, look for whether the bank lets you disable the weaker methods. Where it does not, understand what you have and have not gained.
Synced versus device-bound, and which you want
The distinction mentioned above deserves a practical framing rather than a theoretical one.
Synced passkeys live in a credential manager — iCloud Keychain, Google Password Manager, or a third-party manager — and replicate across your devices. Losing a phone is not a lockout, because the credential is on your other devices and restorable to a new one. The security of the passkey now depends on the security of that cloud account.
Device-bound passkeys never leave the hardware they were generated on. Hardware security keys are the clearest example. Nothing to sync, nothing to compromise remotely, and no recovery if you lose the device.
For a personal banking account, synced is almost always the right choice. The realistic threat is a remote attacker, not someone stealing your specific phone, and the failure mode of device-bound credentials — permanent lockout — is far more likely to happen to you than a targeted physical attack. The exception is a high-value or high-risk account, where two hardware keys stored separately is the mature configuration.
The reason some bank security teams resist synced passkeys is that the credential becomes as strong as the customer’s Apple or Google account, which the bank does not control and cannot audit. That is a legitimate institutional concern. It is not usually the right consumer conclusion.
Enrolling one properly
Check the security settings, not the marketing. Look for “passkey”, “security key”, “sign in without a password”, or “device sign-in”. It is often present and unannounced.
Enrol on a device you will keep. The passkey binds to the credential manager, so enrol from a phone or laptop signed into the account you actually use long-term.
Add a second credential immediately. A passkey on one device is a single point of failure. Enrol a second device, or a hardware key, before you rely on it. Most services support multiple passkeys per account and most people stop at one.
Then go and check what still works. Try to sign in with the old password and OTP. If that path is still open, you have added convenience. If the bank lets you turn it off, turn it off — that is the moment the security benefit actually arrives.
Secure the credential manager itself. If your passkeys sync through your Google or Apple account, that account is now the root of your banking security. It needs its own strong second factor and a clean recovery configuration.
Start with email, not the bank. Your email account is the recovery path to every financial account you hold, which makes it the highest-value target you own and usually the easiest place to enrol a passkey. If you only do this once, do it there.
Where this leaves you
Passkeys eliminate the largest category of remote account compromise — credential phishing and code relay — and they do it without asking the user to be vigilant, which is why they work where training does not. That is a substantial advance and it is worth adopting wherever it is offered.
They do not make an account unbreakable, and the residual risks are concentrated in places passkeys were never designed to reach: the recovery path, the device, and the human being persuaded to send money. Fixing those is separate work, and the authentication upgrade is what makes it worth doing.
Read our security breakdown of mobile authentication threats in our guide on SIM swap: protecting your bank accounts, and why your bank still sends codes by SMS for the constraints that keep the weaker method in place.