From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
Banks adopting passkeys are quickly discovering that not all passkeys carry the same weight. A passkey generated in a consumer's iCloud Keychain is a different security object than one generated on a YubiKey purpose-built for the workforce. For a savings account login, the difference may be cosmetic. For a wire transfer, it is not.
This is the question every financial services security team is now wrestling with: not whether to deploy passkeys, but how to govern which passkeys are accepted, when, and for what kinds of transactions. The good news is that the FIDO Alliance built the answer into the standard from day one. The work for banks is connecting that machinery to the risk framework that already exists inside the institution.
Every passkey is created by an authenticator — the device, app, or service that generated the cryptographic key pair. From the bank's perspective, each authenticator is a distinct provider with its own security properties, attestation behavior, and lifecycle.
The major consumer authenticators most banks see today include Apple's iCloud Keychain, Google Password Manager, Microsoft Account and Windows Hello, 1Password, Dashlane, Bitwarden, and increasingly Samsung Pass on Galaxy devices. Alongside these are roaming hardware authenticators — YubiKey, Feitian, Token2 — that ship as physical security keys. And then there are platform authenticators built into newer device categories: Linux TPMs, ChromeOS, automotive systems, and emerging passkey providers from large enterprise IDPs.
None of these providers behave identically. Some sync credentials across the user's ecosystem. Some bind credentials to a single device. Some support attestation that lets the relying party verify exactly which authenticator made the key. Some don't. Some have published certification at FIDO Authenticator Certification Level 1, others at Level 2 or Level 3. Some support user verification via biometrics, others rely on PIN or device unlock.
For a bank, "we support passkeys" is a sentence that resolves to dozens of distinct trust decisions in production traffic.
The FIDO Alliance anticipated this problem. Every certified authenticator carries an AAGUID — an Authenticator Attestation Globally Unique Identifier. It's a 128-bit value (the same shape as a UUID) that identifies the make and model of the authenticator that created a credential.
When a passkey is created, the AAGUID is included in the attestation object the authenticator returns to the relying party. The bank's server can read that AAGUID and look it up in the FIDO Metadata Service — a continuously-updated catalog of certified authenticators that includes the manufacturer and model name, the FIDO certification level, supported user verification methods, whether the authenticator supports attestation, the trust anchor used for attestation signatures, and any known firmware revocations or security advisories.
This is essentially a public-key infrastructure for authenticator trust. The bank doesn't need to do its own evaluation of every consumer device — it can subscribe to the Metadata Service feed, ingest the data at regular intervals, and let it drive policy automatically.
It's worth pausing on the implications. Banks have spent two decades trying to authenticate users through layers of secrets — passwords, OTPs, KBA, voice prints. Passkeys flip the model: the user's device authenticates itself to the bank cryptographically, and the Metadata Service gives the bank the catalog it needs to know what each device actually is.
How do banks turn this into policy? In practice, most financial services rollouts converge on something close to a four-tier trust framework. The tiers vary by institution and risk appetite, but the shape is consistent.
Tier 1 — Hardware-backed, attested, device-bound. A FIDO L2 or L3 certified hardware authenticator with full attestation. The credential cannot leave the device. Suitable for workforce, treasury operations, and the highest-value retail transactions.
Tier 2 — Platform authenticator with strong hardware backing. Apple iCloud Keychain on a Secure Enclave device, Windows Hello on a TPM, Android with StrongBox. Attestation may be available depending on policy. Synced across the user's ecosystem, which is a trade-off but a manageable one. Suitable for most retail banking and consumer SCA.
Tier 3 — Third-party password manager or app-based authenticator. 1Password, Dashlane, Bitwarden, and others. The credentials sync across whatever ecosystem the user has logged the password manager into, which may not be the same trust boundary as a platform authenticator. Often accepted with step-up requirements for higher-risk transactions.
Tier 4 — Unknown or uncertified. An AAGUID the Metadata Service does not recognize, or an authenticator the bank has chosen not to allowlist. Often rejected at registration time, or accepted only for low-value, read-only flows.
The framework is not a value judgment about user choice. A customer with a 1Password subscription is not a worse customer than one with an iPhone. The framework is a way of expressing what the bank's risk team has decided about each technology profile — and making that decision visible, auditable, and enforceable at scale.
A well-run program turns the trust framework into three operational artifacts. First, a registration policy. When a customer creates a passkey, the bank's server reads the AAGUID and decides whether to accept the registration, accept it with a marking, or reject. Some banks accept everything at registration and apply the trust tier downstream. Others reject Tier 4 at the door.
Second, a transaction policy. Each transaction type — login, low-value purchase, high-value transfer, payee management, beneficiary change — is mapped to a minimum trust tier. If the credential being presented doesn't meet the tier, the system steps up: an additional passkey on a higher-tier device, an out-of-band push, a session refresh.
Third, a monitoring and revocation policy. The Metadata Service publishes status updates when an authenticator's firmware is found to have a security defect. The bank's metadata ingestion should react to those updates — pausing registrations, flagging existing credentials, communicating with customers — without requiring a manual incident response every time.
The biggest mistake we see at this layer is treating the trust tier as a static, one-time decision. The right model is closer to how banks already think about IP reputation, device intelligence, or behavioral analytics: a continuously-updated input into a risk decision, not a fixed gate.
If you're a bank security architect, the takeaway is straightforward. Passkey rollouts that skip provider vetting end up making implicit trust decisions invisibly. Rollouts that build provider vetting into the policy from day one give you the same kind of governance you already have for SMS routes, device intelligence, and behavioral signals.
If you're on the product side, the takeaway is that provider vetting doesn't mean a worse user experience. The default flow looks identical to the customer — a passkey prompt, a biometric, a sign-in. The trust framework decides what happens behind the curtain: whether the transaction proceeds, whether a step-up is required, whether the credential is fast-tracked or routed to a friction layer.
If you're on the compliance side, the takeaway is that the framework gives you something genuinely new. For the first time, the bank can prove — with cryptographic attestation, audited against a public registry — exactly which authenticator was used to approve a specific transaction. That's a step change from "the customer entered the correct OTP."
Ideem built Passkeys+ specifically for financial services rollouts where provider vetting matters. The platform ships with FIDO Metadata Service ingestion, an allowlist editor, and policy controls that let a bank express its trust framework in the authentication flow itself. Banks plug Passkeys+ into the identity stack they already run — alongside Okta, ForgeRock, Ping, or a homegrown IdP — and inherit the trust-tier machinery without rewriting the underlying authentication layer.
The point is not that banks should outsource the policy decision. The risk framework still belongs to the bank, and to its regulator. The point is that operationalizing the framework — keeping the AAGUID catalog current, enforcing tier-based transaction policies, responding to FIDO advisories, providing audit-grade evidence — is a discipline, not a feature. Banks that treat it as discipline end up with passkey programs that scale. Banks that treat it as a feature end up patching incidents.
Heading into the second half of 2026, regulators in Saudi Arabia, the UAE, Singapore, India, and the Philippines have all signaled that they expect the passkey programs in their markets to be operated with the kind of governance described here. The banks that have already built the framework will be ready. The ones that haven't are about to discover that "we support passkeys" was the easy part.
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 →