From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
The discoverable-versus-non-discoverable question used to be an implementation detail buried in a WebAuthn server config. In 2026 it has become a deployment strategy question that touches conditional UI, recovery flows, regulator expectations under NIST 800-63-4 and PSD3, hardware-key fleet management, and the bank's whole identifier model. The decision is more consequential than the two-line flag in a registration options object suggests.
This post is a practical framework for the decision. It's written for the bank security leaders, product owners, and identity architects who have to commit to one path, both paths, or a segmented approach across consumer, employee, and high-risk transaction flows. The thesis is straightforward: most consumer banking flows in 2026 should default to discoverable credentials, several enterprise and high-assurance flows should keep non-discoverable as the right tool, and the platform decision is whether you can support both under one policy without a re-platform.
The technical difference is narrow and worth stating precisely. A discoverable credential — formerly called a resident key, with the legacy term still appearing in the WebAuthn API as the residentKey parameter — stores the credential ID and user handle on the authenticator itself, which can be a platform secure enclave, a TPM, or a roaming hardware key. A non-discoverable credential stores only the cryptographic key material; the credential ID lives on the relying party's server and is passed back to the authenticator on every authentication via the allowCredentials parameter.
That single storage difference produces every downstream UX, security, and operational implication that follows. With a discoverable credential, the authenticator can answer the question "what accounts do I have for this site?" without being told. Without that capability, the bank's server has to identify the user first — via username, email, or session cookie — before authentication can begin.
A passkey, in the FIDO Alliance's current definition, is a WebAuthn credential that is both discoverable and user-verified. Every passkey is a WebAuthn credential, but not every WebAuthn credential is a passkey. The distinction matters because most of the regulatory and ecosystem momentum — iCloud Keychain sync, Google Password Manager sync, the W3C's Credential Exchange Protocol work, conditional UI autofill across browsers — is built around the passkey definition, which assumes discoverability.
Conditional UI is the single biggest reason discoverable credentials dominate consumer banking. Conditional UI — the autofill-style passkey suggestion that appears in the username field alongside saved passwords — only works with discoverable credentials. The browser queries the authenticator for matching credentials by relying-party ID, surfaces them in the autofill menu, and lets the user sign in without typing.
The Corbado Passkey Benchmark 2026 reports a 90–95% final completion rate on the conditional UI login path on desktop, with server-side validation of submitted assertions running at 97–99%. That kind of completion is the reason most consumer banking sign-in pages in 2026 ship the WebAuthn call with mediation: conditional and an annotated autocomplete="username webauthn" input. The friction reduction relative to identifier-first password entry is large enough that it shows up in sign-in success rate and conversion telemetry within weeks of deployment.
Discoverable credentials also handle the cross-device and account-selection cases the consumer market increasingly expects. A customer with three cards at the same bank can be shown three account options at sign-in. A customer signing in from a new laptop can scan a QR code with the phone where the passkey lives. None of that works the same way with non-discoverable credentials, where the bank's server has to know which user the request is for before the WebAuthn call is even constructed.
The synced-passkey ecosystem amplifies this. Roughly 80% of passkeys in active use today are synced, with iCloud Keychain and Google Password Manager together accounting for the dominant share, and synced passkeys are effectively always discoverable. A bank that issues non-discoverable credentials to a customer whose authenticator is a synced platform passkey is fighting the platform's whole UX model.
The case for non-discoverable credentials is narrower in 2026 but not zero. The two cases that come up most often in bank deployments are hardware-key fleets and employee-facing flows that already have a strong identifier in the session.
Hardware keys have a finite number of discoverable credential slots. Even the most recent YubiKey 5 firmware (5.7+) tops out at 100 discoverable credentials per key; older models and many of the FIPS variants are closer to 25. A bank issuing security keys to a workforce that authenticates to dozens of internal applications can run into the slot limit if every application is configured to require a discoverable credential. Non-discoverable credentials don't consume slots — they work off a single hardware secret — so a single key can hold an effectively unlimited number of non-discoverable credentials.
The other case is employee-facing flows where the identifier is already known. A workforce VPN, an internal admin console, or a privileged-access management gateway typically already has the user's identifier from the SSO session, a smart-card insertion, or a Windows logon context. In those cases, the user-discovery property of discoverable credentials adds no UX value and consumes hardware slots that could be reserved for the consumer-facing applications where discoverability matters.
Older U2F-style security keys, which produce non-discoverable credentials by default, also remain widely deployed as second factors in regulated environments. They are still phishing-resistant, still WebAuthn-compliant, and still meet AAL2 in the right configuration. There is no security reason to rip and replace them before the natural refresh cycle.
The decision criteria reduce to four questions the bank's authentication architect can answer in a working session.
One: who is the population? Consumer customers using mobile and web should default to discoverable. The whole ecosystem is built around that assumption, and the UX delta is large enough to show up in conversion data. Employees using managed devices with known identifiers can use non-discoverable without UX cost.
Two: what authenticator types dominate? If the population is overwhelmingly platform authenticators — iCloud Keychain, Google Password Manager, Windows Hello — discoverable is the path of least resistance and the path the platforms optimize for. If the population includes a meaningful hardware-key fleet at risk of slot exhaustion, segment the policy: discoverable for the bank's customer-facing apps, non-discoverable for the workforce's tail of internal apps.
Three: what does the regulatory posture require? NIST SP 800-63-4 (finalized July 2025) classifies both synced and device-bound passkeys as meeting AAL2; device-bound passkeys on hardware authenticators can meet AAL3. PSD3, the RBI's 2025 authentication directions (effective April 2026), NYDFS Part 500, and APRA CPS 234 all push toward possession-factor binding for high-value transactions. Discoverable vs. non-discoverable is orthogonal to the AAL question — both can meet AAL2 — but the device-bound vs. synced question often correlates with it. A bank rolling out hardware keys for AAL3 step-up should think about the discoverable-slot budget early.
Four: does the identity model support both? A bank that locks itself into a single credential type at the platform layer loses optionality. Consumer flows evolve, hardware fleets change, regulators issue new guidance, and the same bank that needed non-discoverable for its workforce in 2024 may need discoverable for its consumer relaunch in 2026. The platform decision is whether the authentication layer can be reconfigured by policy without a re-platform.
The practical operating posture for most banks in 2026 is to default to discoverable credentials for consumer-facing flows, retain non-discoverable as an option for hardware-key-heavy workforce flows, and run both under a single policy framework that the security team can adjust without engineering rework. The decision should be encoded as policy, not as a hardcoded server flag.
Three concrete operational implications follow. First, conditional UI should be on by default for consumer sign-in and treated as a measured KPI — the bank should know the conditional UI suggestion rate, interaction rate, and completion rate by browser and platform, because the Corbado benchmark data shows that the gap between best-in-class and median is wide. Second, enrollment flows for consumer customers should request a discoverable credential by default (set residentKey to required, not preferred, for the bank's primary RP), so a customer who enrolls on one device and signs in on another doesn't fall back into a password flow. Third, the bank's recovery and re-enrollment processes have to assume the credential is discoverable and synced for the consumer population — which means the meaningful share of customers (industry estimates put it in the high single digits to low double digits over an 18-month window) who lose access to all devices need a documented, attested re-enrollment path that doesn't open the unsecured-enrollment attack vector.
None of this should be a one-time decision. The right operating model is a policy that distinguishes consumer from workforce, primary from step-up, and synced from device-bound — reviewed quarterly as the FIDO MDS catalog, the platform UX, and the regulatory posture evolve.
Ideem's Passkeys+ is built for banks that need both discoverable and non-discoverable credentials under a single policy framework, not for banks that have to pick one and live with the consequences. The platform exposes credential-type selection as a policy decision — per channel, per user segment, per risk tier — so a single bank can run discoverable credentials for the consumer mobile app, non-discoverable credentials for a hardware-key-heavy workforce flow, and device-bound discoverable credentials for AAL3 step-up on high-value transactions, all without separate integrations or separate identity stacks.
Passkeys+ also provides the telemetry banks need to operate either model in production. Conditional UI suggestion and completion rates by browser. Discoverable-slot usage on the issued hardware-key fleet. Re-enrollment success rate by recovery path. The instrumentation that turns the discoverable-vs-non-discoverable choice from a one-time decision into an observable, tunable production control.
The credential-model question is going to keep evolving as W3C WebAuthn Level 3 moves toward Recommendation, as the FIDO Credential Exchange Protocol opens up cross-provider sync, and as the next round of regional regulator guidance lands in the GCC and APAC. The banks that build their authentication layer around a policy engine that supports both paths will adapt without re-platforming. The ones that hardcode the decision will be having this conversation again in 2027.
Most orgs running OTP-based MFA have 3–4 exploitable gaps they don’t know about. Our Authentication Assessment takes 2 minutes and shows you exactly where you stand — plus a phased migration roadmap.
Take the Assessment →Built by Ideem
Device-bound passkeys and A2A payment authentication. One SDK. No OTPs, no redirects.
Our 2-minute assessment scores your authentication setup and shows you exactly where the improvements are.
See Your Score →