10 Passkey Deployment Mistakes Banks make

1. Introduction#

The banking sector is at a critical juncture, transitioning from legacy passwords and OTPs to phishing-resistant passkeys. For CISOs and Product Owners this is an existential necessity driven by phishing and rising infrastructure costs. However, banking deployments face unique hurdles: strict regulations (e.g. PSD2/SCA), legacy infrastructure and extreme device diversity.

This guide synthesizes insights from global deployments. It argues that success depends on mastering the "last mile" of user adoption. While infrastructure-focused rollouts often stall at <1% adoption, product-led approaches can achieve >50% quickly.

Strategic imperatives:

• Enrollment is the perimeter: Securing the creation moment is the primary defense against Account Takeover (ATO).
• Visibility is non-negotiable: "Blind rollouts" without client-side telemetry lead to undiagnosable support spikes.
• Context is king: Intelligent fallback logic is essential to prevent "terminal user lockouts" on incompatible hardware.

2. Why Passkeys in Banking are different#

Banks don't have the luxury of "moving fast and breaking things." You operate with zero tolerance for fraud and strict oversight. Deploying passkeys in this environment introduces specific friction points that other industries don't face.

2.1 "Black Box" Problem#

In the password world, your server logs told you everything. You knew exactly why a login failed (wrong character, expired credentials). With passkeys, the authentication happens on the user's device. If a face scan fails, a user cancels the prompt or the Bluetooth handshake drops, your server sees nothing but a generic error.

Banking reality: Fraud and Risk teams suddenly lose their "eyes" on the authentication attempt. Without new, purpose-built telemetry on the client side, you are flying blind during a rollout, unable to tell if a spike in failures is a technical bug or an attack.

2.2 "Possession" Compliance Headache#

Regulators (PSD2/SCA) require two distinct factors: something you know/are and something you have (possession).

Banking reality: Passkeys synced to the cloud (i.e. iCloud Keychain or Google Password Manager) blur this line. If a key is synced to an iPad, a MacBook and an iPhone, does the user physically "possess" a specific device? Legal and Compliance teams often block rollouts because they can't verify "possession" in the traditional hardware sense, forcing teams to build complex "device binding" workarounds that hurt UX.

2.3 Extreme Device and User Fragmentation#

A SaaS company can drop support for older browsers. A bank cannot. Your customers range from digital-native 18-year-olds to 80-year-olds using budget Android devices that haven't been updated in years.

Banking reality: The Android ecosystem is a minefield. Samsung devices often default to "Samsung Pass" which blocks smooth passkey creation on Android. Corporate customers work behind firewalls that could block the WebSocket connections required for cross-device (QR code) logins. A "standard" implementation that works on a QA iPhone will fail for thousands of real-world customers, leading to immediate support queue overflows.

2.4 The Risk of Permanent Account Lockout#

If a Spotify user loses their account, it's annoying. If a banking customer loses access, they can't buy groceries.

Banking reality: Passkeys rely on the ecosystem (Apple/Google). If a user gets locked out of their Apple ID, they lose their passkeys. If you have removed passwords without building a robust recovery path (like ID verification), you risk permanently locking customers out of their accounts. The fear of this scenario paralyzes decision-making in banking rollouts.

3. 10 biggest Mistakes in Passkey Deployments#

Here is an overview of the 10 most common mistakes we see banks making when deploying passkeys:

1. Treating "CIAM/IdP supports Passkeys" as the finish line
2. Fragmenting passkeys (wrong rpID strategy)
3. "Blind rollout" (no client-side telemetry)
4. Ignoring device and network reality
5. Hiding passkeys in account settings
6. Leaking account existence (enumeration)
7. Unsecured enrollment (the ATO vector)
8. Ignoring shared devices and PIN risks
9. Skipping the compliance decision (1FA vs 2FA)
10. Neglecting recovery and permanent lockouts

3.1 Mistake 1: treating "CIAM/IdP supports Passkeys" as the finish line#

The mistake: Teams upgrade their Identity Provider (IdP) to support FIDO2, enable the feature flag and consider the project complete. They treat passkeys as a backend commodity rather than a frontend product journey.

The impact: Adoption stagnates at <1% as users fail to discover or understand the feature. Banks see zero ROI on SMS cost reduction or fraud prevention because the vast majority of logins remain on legacy methods.

The fix:

• Resource the rollout as a product program, not just an IT upgrade.
• Build an "adoption layer" in front of the IdP to manage user education, enrollment prompts and error handling.
• Set adoption KPIs (e.g. "50% of logins via passkey in 6 months") and A/B test enrollment nudges.

3.2 Mistake 2: fragmenting passkeys (wrong rpID strategy)#

The mistake: Different business units (e.g. Retail, Wealth, Corporate) deploy passkeys on disparate subdomains (e.g. retail.bank.com, wealth.bank.com) without a unified anchor.

The impact: Passkeys are origin-bound to prevent phishing. A passkey created for Retail will not work for Wealth, forcing users to register multiple credentials for the same bank. This fractures the UX and dilutes the "phishing-resistant" promise.

The following diagram shows the different Relying Party ID (rpID) possibilities a bank typically faces:

The fix:

• Define a single, primary Relying Party ID (e.g. bankgroup.com) early.
• Use centralized redirects (OIDC/SAML) to ensure all apps authenticate against this single anchor domain.
• Consider Related Origins if legacy domains can't be consolidated immediately.

3.3 Mistake 3: "blind rollout" (no client-side telemetry)#

The mistake: Launching without granular visibility into client-side WebAuthn events. Teams rely on server-side logs (HTTP 200/400), which cannot see what happens on the device (e.g. user cancellation, biometric failure, OS errors).

The impact: Undiagnosable failure spikes. When users report errors like "Operation Interrupted" (seen in Japanese rollouts), the bank cannot distinguish between a Samsung firmware bug, a user error or a network block, leading to support overload.

A production-grade passkey deployment should track at minimum the following client-side telemetry events:

Authentication funnel events:

Error classification signals:

Device and authenticator context (captured per event):

• OS + version (e.g. iOS 18.2, Android 15)
• Browser + version
• Hardware brand / model
• Credential manager (iCloud Keychain, Google Password Manager, Samsung Pass, 1Password etc.)
• Transport method (internal, hybrid, hybrid + internal)
• Time-to-complete / time-to-error

For a complete guide on passkey analytics and authentication analytics, see our dedicated articles.

The fix:

• Instrument the client: Track every step of the ceremony (Prompt -> User Action -> Browser Error Code).
• Roll out in cohorts: Start with tech-savvy internal users, then specific OS versions (e.g. iOS 18+), monitoring error rates by device model.

3.4 Mistake 4: ignoring device and network reality#

The mistake: Designing for the "Happy Path" on modern iPhones/Pixels while ignoring the fragmented reality of enterprise Windows fleets, corporate proxies and diverse Android OEMs (Sony, Sharp, Samsung).

The impact: Corporate proxies often block the WebSocket traffic required for "Hybrid" (QR code) flows, blocking users at work. Android fragmentation causes features like "Conditional Create" to fail on non-Pixel devices due to conflicting credential managers (e.g. Samsung Pass).

The fix:

• Build a device test matrix weighted to your region's market share.
• Implement explicit fallbacks: If a specific OEM device or network environment is known to fail, dynamically suppress the passkey prompt to avoid user frustration.
• Use Passkey Intelligence to detect device capabilities before prompting.

3.5 Mistake 5: hiding passkeys in account settings#

The mistake: Burying the enrollment option deep in "Settings > Security > MFA," fearing user confusion during the main login flow.

The impact: The "1% Trap." Data confirms that users rarely change security settings voluntarily. Adoption stays negligible and the bank continues paying for SMS OTPs for 99% of logins.

The fix:

• Contextual promotion: Prompt users to create a passkey during the login flow, immediately after a successful MFA check when trust is high.
• Progressive urgency: Move from "Optional" nudges to "Recommended" to "Mandatory" over a 12-18 month timeline.

3.6 Mistake 6: leaking account existence (enumeration)#

The mistake: Using an "Identifier-First" login flow that immediately prompts for a passkey if the user exists but asks for a password if they don't.

The impact: This behavior allows attackers to script checks against thousands of emails to build lists of valid bank customers (Account Enumeration), violating strict privacy regulations (FFIEC/Nacha).

The fix:

• Conditional UI: Use the browser's autofill capability to suggest passkeys within the username field without revealing account existence.
• Unified flow: If Identifier-First is required, implement rigorous timing equalization and generic error handling to mask the backend state.

3.7 Mistake 7: unsecured enrollment (the ATO vector)#

The mistake: Allowing passkey creation after a weak login (e.g. just password) or on untrusted devices.

The impact: Attackers who have harvested passwords via phishing can register their own passkey on the victim's account, permanently locking the legitimate user out.

The fix:

• Step-up authentication for enrollment: Require a fresh, out-of-band verification (SMS, Push, Selfie) before allowing passkey registration.
• Device trust: Block creation on suspicious or highly shared devices (e.g. internet cafes) using device fingerprinting and behavioral signals.

3.8 Mistake 8: ignoring shared devices and PIN risks#

The mistake: Treating a passkey login as definitive proof of identity without accounting for shared devices (spouses, children) or weak device PINs ("1234").

The impact: A child knowing a parent's iPad PIN can authorize transactions. Privacy-preserving WebAuthn does not reveal to the bank whether a face scan or a PIN was used.

The fix:

• Shared device detection: Use telemetry to identify devices with multiple user profiles or frequent account switching and restrict passkey usage there.
• Risk-based auth: Trigger step-up challenges for high-value transactions if the device environment signals risk, even if the passkey login was valid.

3.9 Mistake 9: skipping the compliance decision (1FA vs 2FA)#

The mistake: Realizing too late that Legal/Compliance does not view a synced passkey as meeting "Possession + Inherence" (2FA) requirements because the key is copied to the cloud.

The impact: Last-minute project blockers or forced UX friction (e.g. adding a "device binding" step like PayPal) that degrades the passwordless experience.

The core question is whether a passkey counts as one factor or two:

Current market data: ~80% synced passkeys vs ~20% device-bound passkeys in 2025. Among authenticators, ~85% use iCloud Keychain or Google Password Manager, ~10% use Windows Hello and ~5% use third-party password managers. This share will shift toward more synced passkeys once Windows supports synced passkeys.

If passkeys are classified as 1FA - adding a fallback factor:

If you treat passkeys as a single factor, implement a policy to use an additional factor when necessary. This is mainly relevant for web apps, as native apps stay signed in longer and can use local biometrics (only first native app login requires the additional factor).

• New device / login environment: Require a one-time secondary factor after passkey login to confirm user identity and device trust. After this, the device can be marked as trusted (e.g. via cookie or fingerprinting). Options include SMS OTP, selfie liveness, credit card digits or app push. Examples: PayPal and Revolut use this approach.
• Known trusted device: Allow direct passkey login with no additional friction. The user has already proven device possession in the past, so you maintain a seamless UX.

This approach preserves the passwordless experience in daily use (users on regular devices see no change - just the quick passkey login) while satisfying 2FA requirements for new scenarios. It's a user-friendly compromise that meets strict security standards without burdening users every time.

The fix:

• Decide early: Engage compliance teams to decide factor composition with passkeys before starting implementation. This will inform whether you can eventually go passkey-only or need to always pair passkeys with another factor for PSD2 compliance.
• Refer to NIST SP 800-63B guidance which validates synced passkeys at AAL2.

3.10 Mistake 10: neglecting recovery and permanent lockouts#

The mistake: Removing password fallbacks without a robust, automated recovery strategy for users who lose their device ecosystem (e.g. Apple ID lockout).

The impact: a permanent lockout where a user loses access to their funds entirely. This drives expensive, high-stress support calls and creates a security backdoor if the recovery fallback is weak (e.g. email reset).

The fix:

• Smart fallback: Ensure non-dead-end alternatives exist (e.g. hardware security keys).
• Automated identity proofing: Implement self-service recovery via eKYC (ID scan + liveness) to allow users to re-enroll securely without call center intervention.
• Digital credentials: Prepare for verifiable credentials (e.g. mDL) as the most secure and UX-friendly recovery path.

4. Corbado's 8-step Passkey Banking Framework (PSD2-compliant)#

To navigate the minefield described above, you need a structured framework. The following 8-step blueprint is designed for PSD2-compliant banking deployments and high-scale resilience.

5. How Corbado can help#

If you have read the mistakes above, you realize that "supporting passkeys" is 5% WebAuthn implementation (IdP) work and 95% ongoing, non-trivial (adoption) work. Most banks struggle because their existing Identity Providers (Ping, Okta, ForgeRock) handle the backend perfectly but offer zero tooling for the "Last Mile" - the device fragmentation, the UX nudges and the client-side telemetry.

Corbado is the adoption layer for your IdP. We don't replace your existing stack. We sit in front of it to handle the messiness of the real world.

• Adoption engine: Our pre-built UI components and logic handle the "nudge" strategies, A/B testing and enrollment timing to get you from 1% to 50% adoption.
• Device intelligence: We maintain the massive matrix of "what works where." If a specific Samsung device has a broken passkey implementation, our system knows to hide the prompt automatically, saving you a support ticket.
• Smart fallbacks: We prevent permanent lockouts by intelligently routing users to fallbacks when their device isn't ready, ensuring you never block a legitimate customer.
• Forensic telemetry: We give you the "X-Ray" vision you lost. See exactly why a login failed - was it a user cancellation? A biometric timeout? An Android firmware bug? - so your helpdesk isn't flying blind.

6. Conclusion#

The transition to passkeys represents a fundamental shift in banking security, moving beyond simple credential upgrades to a complete rethinking of identity assurance. While technical implementation is the first step, success is ultimately defined by user adoption and operational resilience.

By anticipating these ten pitfalls - specifically around enrollment security, device visibility and recovery logic - banks can move beyond "pilot stagnation" to deliver a secure, frictionless customer experience that sets the standard for the next decade of digital finance.