From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
The passkey conversation in financial services has shifted in the last twelve months. The question is no longer "should we support passkeys" or even "which provider should we standardize on." It's "we have customers presenting credentials from seven different sources — how do we treat them consistently without writing seven different code paths?" That is a much better problem to have, and it is the one this post is about.
Each of the major passkey providers — Apple iCloud Keychain, Google Password Manager, Microsoft Authenticator, 1Password, Dashlane, Bitwarden, Yubico hardware keys — made thoughtful, defensible decisions about how their credentials behave. Those decisions diverge because the underlying use cases diverge. A consumer with one iPhone has different needs than a developer with a corporate laptop, an Android phone, and a YubiKey. The providers built for their users, the FIDO Alliance kept the protocol open, and the bank now has the job of stitching it together. This is engineer-to-engineer territory: AAGUIDs, attestation modes, hybrid transport, and the policy layer that sits on top.
The WebAuthn registration response is a small object with a few load-bearing fields: the credential ID, the public key, the attestation object, and inside that, the AAGUID. The AAGUID is a 128-bit identifier that names the authenticator model that produced the credential. In a clean world, every provider would return a real AAGUID, the bank would do an MDS lookup, and the rest of the program would be deterministic.
The world is not clean. Apple deliberately omits attestation for consumer synced passkeys and returns a zeroed AAGUID — 00000000-0000-0000-0000-000000000000 — on platform-authenticator registrations from iCloud Keychain. This is a privacy decision: Apple did not want every relying party fingerprinting which Apple device created the credential. Google, by contrast, returns a real AAGUID for Google Password Manager passkeys, and so do Microsoft Authenticator, 1Password, Dashlane, and Bitwarden. Yubico hardware keys return both an AAGUID and a full attestation statement.
The community-maintained AAGUID list at passkeydeveloper/passkey-authenticator-aaguids is the practical reference. It maps each known AAGUID to a provider name and an icon, so a bank's account-management UI can show "Passkey saved in 1Password" instead of a hex string. The list is community-sourced and the passkeys.dev maintainers are explicit that it is not a security boundary — an attacker can lie about an AAGUID at registration unless attestation is enforced. For consumer-grade trust signaling the list is fine. For policy enforcement, the AAGUID has to be paired with attestation verification against FIDO MDS.
Sync model is the second axis of divergence, and it is the one that most affects how the bank thinks about credential lifecycle.
iCloud Keychain syncs across the user's Apple devices using end-to-end encryption rooted in the user's iCloud account. Google Password Manager syncs across devices signed into the user's Google account, with Chrome on macOS and Windows acting as a sync endpoint since Chrome 129. Microsoft Authenticator on iOS and Android takes a different stance — the passkeys it stores are device-bound, which Microsoft has positioned as a deliberate security trade-off for managed environments. 1Password, Dashlane, and Bitwarden treat "every device the user owns" as the sync unit, including Linux, where the platform vendors do not play. Yubico hardware keys are device-bound by definition; the key is the device.
From a relying party's perspective the sync model matters for two things: recovery and account binding. A synced passkey survives device loss because the provider's sync fabric restores it on the next device the user signs into. A device-bound credential does not. If the bank's only enrolled credential is on a YubiKey that the customer left in a hotel room, the bank's recovery flow is now the primary control. That is a fine design — many banks prefer it — but it has to be designed.
The signature the bank verifies looks identical in both cases. The risk profile does not. A synced credential is implicitly backed by the security of the user's iCloud, Google, or Microsoft account, which the bank does not control and cannot audit. A device-bound credential is backed by the hardware element the bank just attested. Both are dramatically better than a password. The bank's job is to express which class it accepts where, and to make that decision at the authentication layer, not in scattered application code.
Cross-device authentication — CDA, sometimes called hybrid transport or caBLE — is the flow where the user signs in on Device A by presenting a passkey on Device B, typically by scanning a QR code with their phone. It is one of the more elegant pieces of the FIDO spec: the private key never leaves the originating device, and a Bluetooth proximity check prevents a phishing site from initiating a hybrid flow against a victim's phone halfway around the world.
Hybrid transport is also where provider divergence shows up at the surface most visibly to users. The Corbado Passkey Benchmark 2026 puts hybrid completion at roughly 60–78% on Windows web and 66–86% on macOS web in normal flows, dropping into the 50–60% range in identifier-first flows and climbing to 79–98% in same-device nudge contexts. The variance is largely driven by which OS is acting as the client, which mobile OS is acting as the authenticator, and whether Bluetooth is enabled and unblocked by enterprise policy on the desktop side.
For a bank, the engineering implication is concrete: hybrid is a real flow that real customers use, but it is not a flow you should require for high-friction moments. Use it for first sign-in on a new desktop, not for stepping up a wire transfer on the phone the user is already holding. And measure it. The hybrid completion rate on the bank's own traffic, broken down by client OS and authenticator OS, is the data point that tells the bank whether the flow is healthy.
The FIDO Alliance's Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) are the most consequential standards work happening in this space. CXF reached Proposed Standard in August 2025, and CXP — which wraps CXF in a Hybrid Public Key Encryption (HPKE) envelope for secure transport between providers — is on track to follow in early 2026. Apple shipped CXF-based same-device credential transfer in iOS 26 and macOS 26. 1Password shipped CXF import in beta in 1Password 8.10. Google began rolling out CXF/CXP support in Google Play Services v26.21 in June 2026, with the broader Google Password Manager UI controls still in development. Microsoft has acknowledged the work without committing a timeline.
The user-facing promise is straightforward: a customer who decides to move from iCloud Keychain to 1Password (or vice versa) will eventually be able to export and re-import their passkeys without re-enrolling at every relying party. For banks, that changes the threat model in two interesting ways.
First, the AAGUID associated with a given credential becomes less stable over the credential's lifetime. A passkey that was created on an iPhone may end up sitting in Bitwarden a year later. The bank's policy engine has to handle that gracefully — the credential is the same public key and the same user, but the storage provider has changed. Second, the recovery semantics that the providers are still negotiating — what happens to the original copy when a credential is transferred — mean the bank needs to lean on its own signals (device binding, transaction binding, step-up) for the highest-value actions. The CXP working draft as of mid-2026 has explicit open issues on this, and the providers are working through them in public.
The net effect is that provider-agnostic infrastructure becomes more valuable in a CXP world, not less. The bank's policy engine becomes the stable layer; the storage provider becomes more fluid.
Pulling the pieces together, a bank running a defensible multi-provider passkey program needs the authentication layer to do five concrete things on every enrollment and sign-in.
Ideem Passkeys+ is provider-agnostic by design. We support every major passkey provider — Apple iCloud Keychain, Google Password Manager, Microsoft Authenticator, 1Password, Dashlane, Bitwarden, Yubico and other FIDO-certified hardware keys — and we normalize the registration response into a uniform shape that the bank's policy engine can reason about. The AAGUID is parsed, the FIDO MDS lookup is automatic, the zeroed-AAGUID case is handled as a first-class Apple-synced class with its own metadata, and the provider display name and icon are surfaced for the bank's account-management UI.
The policy engine on top of that is where the bank's risk team operates. AAGUID allow and deny lists, per-provider risk scoring, sync-vs-device-bound routing, and the integration with the bank's existing IdP (Okta, ForgeRock, Ping, or homegrown) all live in one place. When CXP-based credential transfer goes mainstream, Passkeys+ tracks the provider transitions and adjusts the risk signal — the bank doesn't have to rebuild the policy each time the ecosystem shifts.
The thing to internalize about provider divergence in 2026 is that it isn't a problem to be solved — it's a feature of a healthy open standard with multiple committed implementers. The banks that have moved fastest this year are the ones who stopped trying to pick a winning provider and started building the policy layer that makes the whole ecosystem legible. The next twelve months will bring CXP-based portability, more hardware-backed platform authenticators, and a steady widening of the provider field. The infrastructure decision worth making now is the one that absorbs that change instead of fighting it.
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 →