From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
Customer onboarding is the most expensive moment in the bank's relationship with a new customer. It's also the moment when the bank has the least information about the person on the other end of the connection. Every decision the onboarding flow makes — what questions to ask, what documents to require, what authentication factor to enroll — ripples through every interaction that follows.
Passkeys are changing what's possible in this moment. The FIDO Metadata Service in particular gives the bank a piece of information at enrollment that previously was unavailable: a cryptographically-verified statement of what kind of authenticator the customer is using to create their first credential. That statement turns onboarding from a guessing game about device security into a decision the bank can defend in front of a regulator.
This post is for the security architects, fraud teams, and product leaders building or refining a passkey-enabled onboarding flow. The mechanics of MDS are well documented elsewhere. The question this post answers is how to put MDS to work specifically during onboarding — to assign risk tiers, gate sensitive features, and capture the audit evidence that bank compliance functions need.
The FIDO Alliance maintains MDS as a continuously-updated registry of every certified authenticator. The current production endpoint, MDS3, publishes a signed BLOB containing metadata for each authenticator the FIDO Alliance recognizes. The metadata schema is governed by the FIDO Metadata Statement specification (currently v3.1.1, published in October 2025).
For each authenticator, the BLOB includes the manufacturer and model, the FIDO certification level (L1, L2, L3, L3+), the user-verification methods supported (biometric, PIN, pattern, none), the attestation root certificate, the supported public-key algorithms, and any current security status updates — including firmware-level advisories that have been published since the previous BLOB refresh.
Banks subscribe to the BLOB feed at mds3.fidoalliance.org, ingest the signed document on a regular cadence (typically daily), verify the signature against the FIDO root, and load the metadata into a local registry the authentication server consults at runtime. The mechanics are straightforward. What banks do with that registry is where the program shape gets defined.
The opportunity in onboarding is that the bank doesn't have to treat every new customer's authenticator as if it were the same. The AAGUID in the attestation tells the bank exactly which authenticator made the credential. The MDS lookup tells the bank what that authenticator's security properties are. The risk team's policy — expressed once, applied per enrollment — assigns the trust tier.
A typical risk-tiered onboarding policy reads in three or four tiers, with the bank's risk appetite setting the boundaries. Tier 1 recognizes a FIDO L2 or L3 hardware authenticator with full attestation: the customer can be onboarded directly into higher-value features. Tier 2 accepts a platform authenticator with strong hardware backing — Apple Secure Enclave, Windows Hello TPM, Android StrongBox — with biometric user verification. Tier 3 accepts a synced credential from a recognized third-party password manager, often with additional friction (a step-up at the first sensitive action). Tier 4 is anything the MDS doesn't recognize — the bank can either reject at registration time or accept into a low-trust onboarding lane that requires manual verification before any sensitive activity.
This is not a sorting hat. It's a way of expressing the risk team's decision in machine-readable form, so the onboarding flow doesn't have to make ad-hoc judgments about every passkey it sees.
Most banks operating in regulated markets don't ingest the full FIDO MDS BLOB and accept everything. They construct a filtered BLOB containing only the authenticators that match the bank's explicit acceptance criteria. The FIDO Alliance and major identity vendors support this pattern directly: the bank can filter on FIDO certification level (e.g., "must be at least L2"), on biometric user verification support, on attestation availability, or on specific manufacturer / model lists.
The advantage of a filtered BLOB is auditability. When a regulator asks "what does your bank accept as a passkey," the answer is a specific, point-in-time-versioned list. When an examiner asks "how do you respond to a FIDO advisory," the answer is "we recompute the filtered BLOB and pause registrations for affected authenticators." The bank has converted authenticator vetting from a meeting-driven process into a software-driven one.
The filtered BLOB needs governance. The risk team owns the inclusion criteria. The security team owns the ingestion and signing pipeline. The product team owns the customer experience for the cases where a customer's device doesn't make the cut. A program that doesn't define those ownership boundaries up front ends up with three teams pointing at each other every time an advisory drops.
The clearest example is account opening. A new customer is enrolling. The bank's onboarding flow prompts for a passkey. The customer's device generates the credential and includes the AAGUID in the attestation object. The bank's server looks up the AAGUID in its local copy of the filtered MDS BLOB.
If the AAGUID matches a Tier 1 authenticator, the customer can be onboarded into wealth, lending, or treasury features without additional verification beyond standard KYC. If it matches a Tier 2 authenticator, retail features are immediately available; lending is gated on a step-up. If it matches a Tier 3 authenticator, the customer is onboarded into transactional accounts with risk-monitored thresholds. If the AAGUID is unrecognized, the flow either rejects the registration or onboards into a low-trust lane that requires manual verification before any sensitive action.
In every case, the bank has captured a cryptographically-signed record of the decision: which AAGUID, which trust tier, which onboarding lane, which risk policy version. That record is the audit artifact a regulator will eventually ask for.
Ideem's Passkeys+ ships MDS ingestion, filtered-BLOB management, and the policy editor that lets a bank's risk team express their trust-tier framework directly — without engineering build-out. The platform handles signature verification on every BLOB refresh, exposes the policy interface that risk and product teams share, and produces the audit-grade evidence that compliance teams need for examiner conversations.
Banks plug Passkeys+ into the identity stack they already run — Okta, ForgeRock, Ping, or a homegrown IdP — so the MDS-driven onboarding flow lives alongside the rest of the authentication program. The risk-tier decisions are made at the authentication layer, where they belong, rather than scattered across application code.
MDS-driven onboarding is one of the practical reasons financial services has become FIDO's most strategically important market. It's also one of the differentiators between banks that have a passkey program and banks that have a defensible passkey program. The framework is published, the registry is operational, and the audit story writes itself. The remaining question is how soon each bank wires it up.
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 →