--- url: 'https://www.corbado.com/blog/passkey-deployment-mistakes-banks' title: '10 Passkey Deployment Mistakes Banks make' description: 'A practitioner guide for bank CISOs: the 10 most common passkey deployment mistakes in banking - from wrong rpID to lockouts - with concrete fixes.' lang: 'en' author: 'Vincent' date: '2026-02-19T07:11:52.825Z' lastModified: '2026-03-25T10:44:22.014Z' keywords: 'passkey deployment mistakes banks' category: 'Passkeys Strategy' --- # 10 Passkey Deployment Mistakes Banks make ## Key Facts - **Infrastructure-focused** rollouts stall at under 1% adoption; **product-led** approaches treating passkeys as a UX journey can exceed 50% adoption quickly. - **FIDO data** shows passkeys increase conversion by 30 percentage points, ROI that remains unrealized without active **enrollment nudges** and adoption tooling. - In 2025, roughly 80% of passkeys are **synced** and 20% are **device-bound**; about 85% use iCloud Keychain or Google Password Manager. - The **rpID** must be set to a single domain early: passkeys are origin-bound, so mismatched subdomains force users to register multiple credentials for the same bank. - **Unsecured enrollment** is the primary Account Takeover vector: attackers with harvested passwords can register their own passkey, locking out the legitimate user permanently. ## 1. Introduction The [banking](https://www.corbado.com/passkeys-for-banking) sector is at a critical juncture, transitioning from legacy passwords and OTPs to [phishing](https://www.corbado.com/glossary/phishing)-resistant passkeys. For [CISOs](https://www.corbado.com/glossary/ciso) and Product Owners this is an existential necessity driven by [phishing](https://www.corbado.com/glossary/phishing) and rising infrastructure costs. However, [banking](https://www.corbado.com/passkeys-for-banking) deployments face unique hurdles: strict regulations (e.g. [PSD2](https://www.corbado.com/blog/psd2-passkeys)/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](https://www.corbado.com/glossary/icloud-keychain) or [Google Password Manager](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/saas-companies-integrate-passkeys) 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](https://www.corbado.com/blog/how-to-enable-passkeys-android) devices that haven't been updated in years. **Banking reality:** The [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) ecosystem is a minefield. [Samsung](https://www.corbado.com/blog/samsung-passkeys) devices often default to "[Samsung](https://www.corbado.com/blog/samsung-passkeys) Pass" which blocks smooth [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) on [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Corporate customers work behind firewalls that could block the WebSocket connections required for cross-device ([QR code](https://www.corbado.com/blog/qr-code-login-authentication)) 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](https://www.corbado.com/passkeys-for-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](#31-mistake-1-treating-ciamidp-supports-passkeys-as-the-finish-line) - a trap especially common in [large-scale](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) CIAM passkey deployments 2. [Fragmenting passkeys (wrong rpID strategy)](#32-mistake-2-fragmenting-passkeys-wrong-rpid-strategy) 3. ["Blind rollout" (no client-side telemetry)](#33-mistake-3-blind-rollout-no-client-side-telemetry) 4. [Ignoring device and network reality](#34-mistake-4-ignoring-device-and-network-reality) 5. [Hiding passkeys in account settings](#35-mistake-5-hiding-passkeys-in-account-settings) 6. [Leaking account existence (enumeration)](#36-mistake-6-leaking-account-existence-enumeration) 7. [Unsecured enrollment (the ATO vector)](#37-mistake-7-unsecured-enrollment-the-ato-vector) 8. [Ignoring shared devices and PIN risks](#38-mistake-8-ignoring-shared-devices-and-pin-risks) 9. [Skipping the compliance decision (1FA vs 2FA)](#39-mistake-9-skipping-the-compliance-decision-1fa-vs-2fa) 10. [Neglecting recovery and permanent lockouts](#310-mistake-10-neglecting-recovery-and-terminal-lockouts) ### 3.1 Mistake 1: treating "CIAM/IdP supports Passkeys" as the finish line ![login with passkey button](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/login_with_passkey_button_b3468a2503.png) **The mistake:** Teams upgrade their Identity Provider (IdP) to support [FIDO2](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/sms-cost-reduction-passkeys) reduction or fraud prevention because the vast majority of logins remain on legacy methods. Yet FIDO data shows [passkeys increase conversion](https://www.corbado.com/blog/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](https://www.corbado.com/blog/passkeys-stakeholder) 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](https://www.corbado.com/passkeys-for-e-commerce), 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](https://www.corbado.com/glossary/phishing). A passkey created for [Retail](https://www.corbado.com/passkeys-for-e-commerce) 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](https://www.corbado.com/glossary/relying-party) ID (rpID) possibilities a bank typically faces: ![webauthn relying party id](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/webauthn_relying_party_id_10161e94de.png) **The fix:** - Define a single, primary [Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://www.corbado.com/blog/samsung-passkeys) 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:** | Event | Description | | -------------------------- | ----------------------------------------------------------- | | `auth_viewed` | User lands on the authentication interface | | `auth_method_selected` | User chooses authentication method (passkey, password, OTP) | | `auth_attempt` | WebAuthn ceremony initiated | | `auth_challenge_served` | Server responds with challenge | | `auth_challenge_completed` | User completes biometric / PIN verification | | `auth_success` | Token issued, session established | | `auth_failure` | Access denied with specific error code | **Error classification signals:** | Error type | Meaning | Action | | ------------------------------------------ | ---------------------------------------- | ------------------------------------ | | [`NotAllowedError`](https://www.corbado.com/blog/webauthn-errors) | User dismissed prompt or timeout | Expected - monitor rate | | [`AbortError`](https://www.corbado.com/blog/webauthn-errors) | Navigation / re-render during ceremony | Bug - investigate frontend | | `SecurityError` | Context or policy mismatch | Config issue - check rpID / origins | | `InvalidStateError` | Duplicate registration or state mismatch | UX issue - check enrollment flow | | `UnknownError` | Platform / authenticator failure | Platform bug - segment by OS version | **Device and authenticator context (captured per event):** - OS + version (e.g. [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades).2, [Android 15](https://www.corbado.com/blog/android-15-passkeys-single-tap-autofill-fallback-ui)) - Browser + version - Hardware brand / model - Credential manager (iCloud Keychain, [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager), Samsung Pass, [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis) etc.) - Transport method (internal, hybrid, hybrid + internal) - Time-to-complete / time-to-error For a complete guide on [passkey analytics](https://www.corbado.com/blog/passkey-analytics) and [authentication analytics](https://www.corbado.com/blog/authentication-analytics-playbook), 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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)+), 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](https://www.corbado.com/blog/conditional-create-passkeys)" 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](https://www.corbado.com/faq/testing-enterprise-passkey-deployments-key-steps) 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](https://docs.corbado.com/corbado-connect/features/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](https://www.corbado.com/blog/passkey-creation-best-practices) 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](https://www.corbado.com/blog/passkey-creation-best-practices) 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](https://www.corbado.com/blog/passkey-login-best-practices) 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](https://www.corbado.com/blog/passkey-login-best-practices) 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](https://www.corbado.com/blog/device-bound-synced-passkeys) as meeting "Possession + Inherence" ([2FA](https://www.corbado.com/blog/passkeys-vs-2fa-security)) 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](https://www.corbado.com/blog/paypal-passkeys)) that degrades the passwordless experience. The core question is whether a passkey counts as one factor or two: | | Passkey = 2FA | Passkey = 1FA | | -------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Factors** | Inherence/Knowledge (PIN/biometric) + Possession (private key protected by HSM) | Inherence/Knowledge (PIN/biometric) only - no possession guarantee | | **Reasoning** | Private key is a possession factor as only trusted devices are allowed. 2FA-protected cloud account can be provided | No possession factor because no guarantee of device-binding as private key is synced. No guarantee user owns device during login. Additional factor required (e.g. selfie liveness, SMS OTP, app push, credit card digits) | | **Industries** | Common outside EU | Stricter assessment (e.g. EU banks under PSD2) | **Current market data:** \~80% synced passkeys vs \~20% [device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) in 2025. Among [authenticators](https://www.corbado.com/glossary/authenticator), \~85% use [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) or [Google Password](https://www.corbado.com/blog/how-to-use-google-password-manager) Manager, \~10% use [Windows Hello](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkeys-local-biometrics) (only first [native app](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys) and [Revolut](https://www.corbado.com/blog/revolut-passkeys) use this approach. - **Known trusted device:** Allow direct [passkey login](https://www.corbado.com/blog/passkey-login-best-practices) 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](https://www.corbado.com/blog/passkeys-vs-2fa-security) 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](https://www.corbado.com/blog/psd2-passkeys) compliance. - Refer to [NIST SP 800-63B](https://www.corbado.com/faq/nist-sp-800-63b-supplement-passkey-adoption) guidance which validates synced passkeys at [AAL2](https://www.corbado.com/blog/nist-passkeys). ### 3.10 Mistake 10: neglecting recovery and permanent lockouts ![passwordless recovery plan](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passwordless_recovery_plan_c56596b499.png) **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](https://www.corbado.com/blog/best-fido2-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](https://www.corbado.com/glossary/microcredentials) (e.g. [mDL](https://www.corbado.com/blog/mobile-drivers-license)) 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](https://www.corbado.com/blog/psd2-passkeys) banking deployments and high-scale resilience. For a comprehensive overview of all implementation phases, see our enterprise passkey integration guide. | Step | Area | What to do | | ----- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | | I. | **WebAuthn Relying Party Server and ID (rpID)** | Set up a WebAuthn server and establish a single domain (rpID) for passkeys across your bank's sites | | II. | **Channel and Application Strategy** | Pick your initial platform/app and decide on a central SSO vs in-app integration approach | | III. | **Deployment Strategy: Web-first vs Native-first** | Determine whether to launch on web first or native app first, based on your user base and risk appetite | | IV. | **Use Cases: Login, Transaction Authorization or 3DS** | Start with login, then extend passkeys to transaction approvals and 3DS flows (payment verification) | | V. | **Trust Signals: Passkey Creation and Usage** | Implement device trust checks when creating/using passkeys (ensure only trusted environments) | | VI. | **Multi-Factor Strategy: Classification of Passkeys** | Decide if a passkey counts as "one factor" or "two" under regulations and plan your MFA strategy accordingly | | VII. | **Passwordless and Recovery Plan** | After adoption, have a path to retire passwords and offer secure account recovery methods | | VIII. | **Future Outlook (CMTG Keys)** | Prepare for upcoming passkey enhancements (like cross-device trust via CMTG keys) to further strengthen security | ## 5. How Corbado helps Banks avoid these Deployment Mistakes Many of the mistakes described above stem from a lack of visibility into real-world passkey behavior across diverse device landscapes. Corbado addresses this by providing an intelligence layer that gives banks the operational data and policy controls they need. ### 5.1 Mistake Prevention through Device Trust Monitoring Corbado's Device Trust dashboard provides the forensic visibility that most banks lack during passkey rollouts. Instead of discovering device-specific failures through support tickets, banks can proactively monitor success rates by passkey type, device classification, and SCA factor coverage. ![Corbado Device Trust Dashboard](https://www.corbado.com/website-assets/corbado_device_trust_dashboard_42ce934484.png) The dashboard surfaces issues like shared device usage (0.8% kiosk detection), declining trust durability curves by browser, and SCA factor coverage gaps - all metrics that directly map to the deployment mistakes discussed above. ### 5.2 Policy-based Rollout Controls Rather than a big-bang passkey deployment, Corbado's configurable trust policies let banks implement a controlled rollout. Banks can define exactly which device/passkey/trust combinations allow [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices), which require [step-up authentication](https://www.corbado.com/glossary/step-up-authentication), and which should be blocked - preventing the "terminal lockout" scenario that Japanese financial institutions experienced when disabling password fallbacks too early. ![Corbado Trust Policy Configuration](https://www.corbado.com/website-assets/corbado_trust_policy_80ad56409f.png) 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](https://www.corbado.com/) 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](https://www.corbado.com/blog/user-transition-passkeys-expert-strategies) 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. ## 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.