You've read the compliance memo. Your board wants phishing-resistant authentication. You've allocated budget for FIDO2. Yet, six months later, you're still running SMS one-time passwords alongside a pilot that nobody uses.
This pattern repeats across financial institutions. The technology works. The standards are mature. Microsoft, Google, and Apple ship passkey support in every OS update. But implementation stalls, adoption flatlines, and your authentication stack remains vulnerable to the exact attacks FIDO2 was designed to prevent.
Here's why these mistakes keep happening: banks treat passkey deployment as a feature launch instead of an authentication migration. You're not adding a login option. You're replacing a 40-year-old trust model that touches every system, every user workflow, and every compliance control you've built. When you approach it like a product feature, you skip the hard work of credential lifecycle planning, fallback path design, and user migration sequencing.
Mistake 1: Treating FIDO2 as "Better MFA"
Why it happens: Your procurement team sees passkeys as a drop-in replacement for TOTP or push notifications. The vendor demo shows a smooth login. You assume it slots into your existing MFA stack.
The consequence: FIDO2 isn't Multi-Factor Authentication with a different second factor. It's cryptographic proof of possession that replaces the password entirely. When you bolt it onto a password-first architecture, you create two parallel authentication paths. Users pick the easier one (the password). Your phishing surface stays wide open. Attackers ignore the passkey path and target the legacy flow you left running.
The fix: Design for passwordless from day one. Map every system that currently validates passwords. Identify which ones support WebAuthn or CTAP2 natively, which need federation proxies, and which require application rewrites. Build a migration roadmap that phases out password validation, not one that runs both indefinitely. Your compliance reporting should track "percentage of authentication events that never touched a password," not "percentage of users enrolled in passkeys."
Mistake 2: Skipping the Credential Recovery Plan
Why it happens: You focus on the happy path. Users register a passkey, they log in, everything works. You assume lost devices are an edge case you'll handle later.
The consequence: A user loses their phone. They can't authenticate. Your help desk has no documented procedure for passkey recovery that doesn't revert to SMS OTP (which defeats the phishing resistance you just paid for). So you either lock legitimate users out or you build a recovery path that reintroduces the exact vulnerabilities FIDO2 eliminated. Attackers will find that recovery path.
The fix: Design credential recovery before you onboard the first user. Require multiple registered passkeys per identity (a platform authenticator on their phone, a second on their laptop, a Multi-Factor Cryptographic Device in their desk). Document the recovery workflow: how does a user with zero registered credentials prove their identity without falling back to SMS? Many banks use in-branch identity proofing for high-value account recovery. Others require video verification with government ID. The method matters less than having a documented process that maintains phishing resistance through the entire lifecycle.
Mistake 3: Ignoring Shared Device Workflows
Why it happens: Your pilot targets knowledge workers with corporate laptops. Passkeys work beautifully. You declare success and expand to branch tellers, call center staff, and back-office teams who share workstations.
The consequence: Platform authenticators (Face ID, Windows Hello) bind to a device, not a user. When five tellers share one Windows PC, you can't use device-bound passkeys without creating a single shared credential (a compliance violation) or forcing each teller to carry a separate Multi-Factor Cryptographic Device (which they'll lose, forget, or share). Your elegant passwordless flow collapses into a mess of workarounds.
The fix: Segment your authentication strategy by user context. Dedicated-device users (executives, remote workers, developers) get platform authenticators. Shared-device users get roaming authenticators (security keys, smart cards with FIDO2 applets). Call center staff might use a hybrid model: security key for initial login, then session-bound soft tokens for application access. Map your workforce by device ownership before you pick authenticator types. One size does not fit all.
Mistake 4: Deploying Without Browser and OS Baseline Requirements
Why it happens: You test on the latest Chrome and Safari builds. Everything works. You push to production and discover 30% of your user base runs Internet Explorer 11 or three-year-old Android phones that don't support CTAP2.
The consequence: You either block a third of your users (unacceptable) or you maintain a legacy authentication path for "incompatible devices" (which becomes the path attackers target). Users on old devices never migrate. Your phishing-resistant authentication becomes a voluntary opt-in for people with new phones.
The fix: Audit your actual device and browser telemetry before you design the migration. Identify the oldest OS version and browser release you'll support. Set a compatibility floor: "We support WebAuthn on Chrome 90+, Safari 14+, Edge 90+, and Android 9+." Publish a device upgrade timeline. Give users 90 days' notice that older devices will require a security key instead of a platform authenticator. Compliance teams should track "percentage of authentication events from incompatible clients" as a migration KPI. When that number hits 5%, you can retire the legacy path.
Mistake 5: Treating Passkeys as the Compliance Finish Line
Why it happens: Your auditor asks how you're addressing phishing risk. You point to your passkey rollout. They check a box. You assume you're done.
The consequence: FIDO2 solves credential phishing. It doesn't solve session hijacking, authorization bypass, or insider threats. An attacker who steals a valid session token after authentication can still move laterally, exfiltrate data, or modify transactions. Strong Customer Authentication under PSD2 requires transaction-level verification for high-risk payments, not just login-time authentication. DORA mandates resilience testing of your entire authentication stack, including failover paths and recovery procedures. A passkey rollout that ignores post-authentication controls leaves you exposed and non-compliant.
The fix: Map your compliance obligations to specific controls, not technologies. SCA requires dynamic linking between the authentication and the transaction. Implement step-up authentication for wire transfers above your risk threshold. FFIEC guidance expects continuous monitoring and anomaly detection. Deploy session management controls that re-verify high-risk actions even after successful FIDO2 login. Your compliance matrix should list "phishing-resistant authentication" as one control among many, not the single line item that closes all findings.
Prevention Checklist
Before you deploy passkeys to production:
- Document which systems will stop accepting passwords and when
- Define credential recovery workflows that maintain phishing resistance
- Segment users by device ownership (dedicated vs. shared workstations)
- Audit browser and OS telemetry; set minimum compatibility requirements
- Map compliance obligations beyond login (session security, transaction verification, resilience testing)
- Establish KPIs: authentication events without passwords, users with multiple registered credentials, authentication events from incompatible clients
- Test failover scenarios: what happens when your FIDO2 provider has an outage?
- Train your help desk on passkey recovery before users call in
- Identify high-risk workflows that need step-up authentication after login
- Schedule post-deployment reviews at 30, 90, and 180 days to measure adoption and identify friction points
The technology works. The mistakes are in the migration planning.
