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 - a trap especially common in large-scale CIAM passkey deployments
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. Yet FIDO data shows passkeys increase conversion by 30 percentage points - ROI that remains unrealized without adoption.

The fix:

• Resource the rollout as a product program, not just an IT upgrade. Engaging stakeholders early across compliance, security and product teams is essential.
• Build an "adoption layer" in front of the IdP to manage user education, enrollment prompts and error handling. For guidance on designing these flows, see our product design and strategy guide.
• 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 (see our enterprise passkey testing guide for a detailed matrix).
• 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. For a comprehensive overview of all implementation phases, see our enterprise passkey integration guide.

5. How Corbado can help#

Almost every mistake above has the same root. The bank cannot see what its passkey flows actually do on customer devices, and it has no switch to turn a flow off for the devices where it breaks. Corbado Connect adds both in front of your existing IdP: Ping, Okta or ForgeRock keep owning credentials and sessions, while the client-side behaviour becomes something you can measure and steer.

5.1 Mistake Prevention through client-side Telemetry#

The blind rollout in mistake 3 and the device fragmentation in mistake 4 are visibility problems. Corbado Observe, the authentication observability layer, records every ceremony in the browser and in the native app and groups it by device brand, model, OS version and browser. Its Device Health view keeps hard errors, ceremonies that never returned and unknown incompletes apart, so a broken firmware build or a WebView that swallows the prompt shows up as a device cohort long before it shows up as a ticket queue.

See how Corbado Connect ships this →

Three further Observe views map directly onto the mistakes above:

• Passkey Errors attributes failed ceremonies to a concrete WebAuthn reason, which is the client-side telemetry mistake 3 asks for.
• Client Capabilities charts six WebAuthn support signals as a share of your login sessions over time: platform authenticator availability, conditionalGet, conditionalCreate, hybrid transport, relatedOrigins and the signal methods. Each chart filters by operating system, touchpoint and application, so the rpID and channel decisions in mistake 2 rest on measured support rather than on a support matrix from a vendor deck.
• Inventory splits your credential base into synced passkeys, device-bound passkeys and security keys and names the model behind each AAGUID, from the FIDO Metadata Service for security keys, which is where the certification level comes from too, and from a platform-authenticator catalog for iCloud Keychain, Google Password Manager and the third-party managers. That is the evidence the 1FA vs 2FA discussion in mistake 9 needs.

5.2 Policy-based Rollout Controls#

Rather than a big-bang passkey deployment, Corbado Connect's Gradual Rollout rulesets decide per request whether passkey creation, passkey login and passkey management are offered at all. Rules match on platform and version, browser, device brand and model, client type (web, app, native, WebView), whether conditional create is available and IP range, and each rule can allow, block or allow a sampled share of traffic. A ruleset can be simulated against past traffic before it goes live, an identifier whitelist opens the flow for internal testers first, and a kill switch takes it back down in one step. That is how you keep the "terminal lockout" scenario that Japanese financial institutions ran into out of your deployment without freezing the rollout for everyone.

See how Corbado Connect ships this →

If you have read the mistakes above, you realize that "supporting passkeys" is a small amount of WebAuthn work in the IdP and a large amount of ongoing adoption work. Most banks struggle because their existing Identity Providers (Ping, Okta, ForgeRock) handle the backend perfectly and offer no tooling for the "Last Mile": the device fragmentation, the UX nudges and the client-side telemetry. Corbado Connect fills that gap and leaves your stack in place.

• Adoption engine: Pre-built login, append and passkey-list components together with Passkey Intelligence rules handle nudge timing, suppression and A/B splits, which is where the up to 10x higher passkey adoption comes from.
• Device intelligence: Passkey Intelligence and Gradual Rollout evaluate device brand, model, OS version, browser and client type on every request, so a model with a broken passkey implementation stops being offered the prompt.
• Smart fallbacks: When a device is not ready, the flow routes the user back to your existing method instead of dead-ending, which keeps mistake 10 away from your call center.
• Forensic telemetry: Observe reconstructs one user's login journey step by step, so support can say whether a login ended in a user cancellation, a timeout or a platform error.

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.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

How do we prevent passkey adoption from stagnating at under 1% in our banking app?#

Adoption stalls when passkeys are buried in account settings rather than surfaced during the login flow. Banks should prompt users to create a passkey immediately after a successful MFA check, set explicit KPIs such as '50% of logins via passkey in 6 months' and A/B test enrollment nudges. FIDO data cited in banking deployment research shows passkeys can increase conversion by 30 percentage points when adoption is actively driven.

What rpID configuration should a bank with multiple subdomains like retail.bank.com and wealth.bank.com use for passkeys?#

Banks should define a single Relying Party ID anchored to the top-level domain, for example 'bankgroup.com', before any implementation begins. Passkeys are origin-bound by design to prevent phishing, so separate subdomains force users to register distinct credentials for each business unit, fragmenting the experience. If legacy domains cannot be consolidated immediately, Related Origins can bridge the gap without forcing re-enrollment.

How can we stop an attacker from enrolling their own passkey on a victim's account after a credential breach?#

Passkey enrollment must be gated behind a step-up authentication check, requiring a fresh out-of-band verification such as SMS, push notification or selfie liveness before a new passkey is registered. Without this gate, an attacker who obtained a victim's password via phishing can register their own passkey and permanently lock out the legitimate user. Device fingerprinting and behavioral signals should additionally block passkey creation on suspicious or highly shared devices.

What client-side telemetry events should we capture during a bank passkey rollout to diagnose failures?#

Server-side HTTP logs cannot see device-level failures such as user cancellations, biometric timeouts or Android firmware bugs, so dedicated client-side instrumentation is essential. At minimum, banks should track the full authentication funnel alongside error codes such as NotAllowedError, AbortError and UnknownError, segmented by OS version, browser, hardware model and credential manager. This data lets teams distinguish a Samsung firmware issue from a network block or user error without relying on support tickets.