From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
TL;DR: Synced passkeys, the variant that backs up across the user's iCloud Keychain or Google Password Manager, are a real step forward for consumer authentication. They are also creating a specific problem for financial services. When a passkey syncs, the security of the credential becomes the security of the cloud account that holds it. For high-assurance flows like wire transfers, beneficiary additions, and account recovery, financial institutions need to know that the credential on the other end of the session is bound to a specific, attested device. Here is the trade-off, why it matters at the regulator's table, and how device-bound passkeys close the gap.
The FIDO Alliance specification supports two passkey variants. Device-bound passkeys are generated and stored in a hardware security module on a single device, and they do not leave that device. Syncable passkeys are generated and then synchronized across the user's devices through a platform credential manager: iCloud Keychain on Apple, Google Password Manager on Android and Chrome, and an emerging set of third-party password managers including 1Password and Bitwarden.
From the user's perspective, syncable passkeys solve a real usability problem. If a user creates a passkey on their phone and the phone is lost, broken, or replaced, the passkey is still available on the user's iPad, laptop, or other Apple or Google devices. Account recovery is materially easier. The friction of re-enrolling at every relying party after a device change is gone.
For consumer applications and enterprise SaaS, the trade-off is generally favorable. The increased recoverability outweighs the increased attack surface. For financial services, the calculus is different.
When a passkey syncs through iCloud Keychain or Google Password Manager, the private key material has to leave the original authenticator. The platform encrypts it with keys derived from the user's cloud account credentials, transmits it to the platform's cloud storage, and decrypts it on the user's other devices. The implementations are well-engineered and the encryption is real, but the security boundary has moved.
Before sync, the security boundary of the passkey was the secure enclave of the device that generated it. After sync, the security boundary is the cloud account that holds the synced copy. If an attacker compromises the user's Apple ID or Google account, they compromise every passkey synced through that account, at every relying party that trusted the synced credential.
This is not a theoretical risk. Cloud account takeover is a well-understood attack vector. SIM swap can deliver an Apple ID password reset. Phishing can capture Google account credentials. Once the cloud account is compromised, the attacker has access to every passkey the user has synced, indefinitely, without any signal to the relying parties that the credentials have moved.
Most relying parties can absorb the residual cloud account risk because the value at stake per session is bounded. The cost of a fraudulent password manager login is, for most consumer services, low. The recovery story is straightforward.
For financial institutions, the value at stake per authenticated session can be the entire balance of an account. Wire transfers, beneficiary changes, account recovery flows, and high-limit transaction signing all live behind the same credential. The cost of a single compromise is materially higher, and the regulatory expectations have evolved accordingly.
The Bangko Sentral ng Pilipinas Circular 1213, the UAE Central Bank's authentication directive, the Reserve Bank of India's framework on alternative authentication factors, and NIST SP 800-63B-4 all emphasize the same property: the authentication factor must be bound to something the attacker cannot share or intercept. A synced credential, by definition, can be moved. Whether that movement is desirable for usability and how it interacts with the regulatory definition of possession is a question financial institutions are working through actively.
A device-bound passkey lives in the secure enclave of a specific device and does not leave it. There is no synced copy on a server. There is no shadow credential on a different device that could be used in the user's name. When the bank authenticates a session against a device-bound passkey, it is authenticating against the same physical device that enrolled originally.
The properties that matter for financial services follow from this binding.
The credential cannot be silently exfiltrated. A cloud account compromise does not give an attacker access to a device-bound passkey because the credential never left the device.
The bank gains continuous device assurance. Each authentication is signed by the same hardware key, and the bank can detect a change of device as a meaningful event. With synced passkeys, a new device is just another sync. With device-bound passkeys, a new device is a re-enrollment.
The credential supports attestation. The bank can verify, at enrollment, that the passkey is generated on a specific class of authenticator with known security properties. This matters when regulatory frameworks require evidence of the technical operation of the authenticator, which several global frameworks now do.
The honest trade-off is recoverability. A user who loses a device with a device-bound passkey has to re-enroll. Re-enrollment is friction. Banks that adopt device-bound passkeys need a thoughtful re-enrollment flow, ideally one that combines a strong identity verification with a fresh device attestation.
The institutions that have done this well treat re-enrollment as a security event in its own right, not as a customer service inconvenience. The user proves identity through a layered verification (KYC documents, video, or in-person) and the bank issues a fresh device-bound passkey on the new device. The user has full account access again. The attacker who took the original device, or compromised the cloud account, does not.
This is the workflow most banks are comfortable with for high-assurance scenarios already. Adding a device-bound passkey enrollment to it is incremental, not a rewrite.
The argument is not that synced passkeys are bad. They are a clear improvement over OTP, push MFA, and TOTP. For routine session login at consumer-grade relying parties, synced passkeys are likely the right choice. The user gets a strong, phishing-resistant credential without the recoverability tax.
The argument is that financial services has a higher threshold for what counts as the same authentication every time, and the device-bound variant meets that threshold in a way the synced variant does not. The two variants are not competitors. They serve different points on the assurance spectrum.
Most institutions will land on a hybrid model. Routine login on synced passkeys. High-value actions on device-bound passkeys. The same FIDO standard, the same cryptographic primitives, just used at the right point in the flow.
The FIDO standard offers institutions a choice that did not exist with OTP, TOTP, or push. They can pick the variant that matches the assurance requirement, rather than negotiating with a single one-size-fits-all factor. Device-bound passkeys for the actions that matter most. Synced passkeys for the actions that don't. Both are passkeys. Both are phishing resistant. The variant matters for the high-assurance side of the bank's authentication architecture, and 2026 is the year the choice is being made in earnest.
NIST SP 800-63B-4 Digital Identity Guidelines
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 →