From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
Every passkey program I've worked on starts with the same conversation. Someone on the security team has read the WebAuthn spec, someone in engineering has prototyped a flow against SimpleWebAuthn over a long weekend, and the question lands on a steering committee agenda: do we build this ourselves or buy it?
The honest answer in 2026 is that it depends — but the dependencies have changed. PCI DSS 4.0 is now in force. DORA went live across the EU. The Interagency Guidance on Third-Party Relationships has reframed how U.S. regulators look at vendor risk. And the cost data on in-house passkey builds is finally good enough to make the decision on numbers rather than intuition. This post is the framework my team uses to walk financial services customers through the choice, with the lessons we've collected from actual deployments — including the ones that started as builds and ended as buys.
The term "build" gets used loosely. In practice, building a production passkey stack for a regulated bank is at least eight workstreams running in parallel.
There's the WebAuthn server itself — registration, authentication, credential storage, AAGUID handling, attestation verification, FIDO Metadata Service ingestion. There are the client SDKs for web, iOS, and Android, each of which has its own quirks and breaks on its own quarterly schedule. There's the conditional UI work, the autofill behavior, the cross-device flows, the QR-code hybrid transport for legacy device pairs. There's account recovery — the part that determines whether your phishing-resistant credential is actually phishing-resistant, or whether it falls back to an SMS OTP the moment a customer drops their phone.
Then come the bank-specific layers. Transaction binding so a high-value transfer is authorized by a fresh passkey signature, not a session token. Step-up logic that routes by AAGUID and trust tier. Telemetry that the compliance team can actually use in an audit. Provider allowlists. Revocation flows that respond to FIDO advisories within a defined SLA. Multi-provider normalization so an Apple iCloud Keychain credential, a 1Password credential, and a YubiKey behave consistently inside the bank's risk model.
Corbado's published 2026 cost data puts a full in-house passkey integration for a 5M-user consumer-scale platform at roughly 27.5 FTE-months: about 14 months of engineering across web, native mobile, and backend; 8 months of QA; and 5.5 months of product management and design. That's before SOC 2 Type 2 work, PCI DSS 4.0 alignment, FIDO server conformance testing, or any of the bank-grade controls above. The 1.5 FTE per year ongoing-maintenance figure that Corbado, MojoAuth, and others converge on covers exactly what you'd expect: browser API changes, OS releases, OEM bugs, password manager updates, and the steady churn of the WebAuthn spec itself.
Buying isn't a single option either. There are at least three meaningfully different shapes of vendor relationship.
The first is a full-stack CIAM platform that replaces the bank's identity layer entirely — Auth0, ForgeRock, Ping, Okta CIC. These are heavy lifts for an established bank because the bank already has an IdP, an IAM team, an investment in token lifecycles, and a regulator who has seen the architecture diagram. Replacing the whole stack to get passkeys is rarely the right move.
The second is a passkey-first specialist that operates as a standalone authentication service — Hanko, Stytch, Corbado, Descope, Beyond Identity. These vendors handle WebAuthn well and ship fast. They generally weren't built for the bank-grade governance layer: transaction binding, FIDO MDS-driven trust tiers, audit trails formatted for a regulator's evidence request, multi-provider normalization specifically tuned for financial services risk decisions.
The third is what I'd call the managed bank-grade passkey layer — a vendor that sits alongside the bank's existing identity stack and handles only the passkey infrastructure, with the regulator-facing controls a financial institution needs. That's the category Ideem's Passkeys+ is built for, and it's the category most of our customers end up in after evaluating the first two.
The shorthand my team uses in customer conversations: full-stack CIAM is a re-platform, passkey-first specialist is a feature, and managed bank-grade is a discipline. For most banks, the third one is the closest fit.
The interesting shift in 2026 is that the build-vs-buy question is no longer purely a TCO calculation. Three regulatory changes have pushed it into a governance conversation too.
PCI DSS 4.0 became fully mandatory on March 31, 2025. MFA is now required for all access to the cardholder data environment, with explicit resistance to adversary-in-the-middle and replay attacks. SMS OTP no longer cleanly meets the bar in many readings of the standard. Whatever you build or buy has to satisfy this baseline, and the auditor doesn't care which side of the build-vs-buy line your stack sits on — they care that the controls are there and demonstrable.
DORA, applied across the EU since January 17, 2025, formalizes ICT third-party risk management as a board-level concern. Concentration risk is explicitly named. The European Supervisory Authorities published the first list of Critical ICT Third-Party Providers in November 2025. For banks with EU exposure, "we built it ourselves" is no longer a regulatory get-out-of-jail card — the bank still has to prove the build is operationally resilient, recoverable, and tested. But "we bought it from a vendor" comes with its own additional set of contract clauses, exit plans, and oversight obligations.
In the U.S., the 2023 Interagency Guidance on Third-Party Relationships (FRB, FDIC, OCC) and the federal banking agencies' May 2024 community-bank guide (OCC Bulletin 2024-11) have raised the bar on vendor due diligence. Examiners now expect banks to assess the criticality of the activity, the vendor's incident recovery capability, ongoing performance monitoring, and contractual rights to independent reviews. The work is real — but it's standard discipline for any vendor that touches authentication, and the regulators have stopped treating it as exotic.
Net effect: buying no longer absolves the bank of governance work, and building no longer absolves it of vendor-equivalent scrutiny. The decision is now about where the bank wants to spend its engineering and compliance capacity, not about which side has less regulatory weight.
Here's the scorecard we walk customers through. There are no wrong answers, only signals. Three or more "build" answers usually means an institution has the surface area to make a build work. Three or more "buy" answers means the rollout will move faster, cheaper, and with less regulatory drag through a vendor.
1. Do you already operate a dedicated IAM platform engineering team of 8—15 people, including specialists in WebAuthn, mobile SDKs, and FIDO conformance? Build is viable if yes. If the answer is "we have a security team and an identity vendor," buy.
2. Is your time-to-first-production-passkey horizon longer than nine months? Build requires it. Most banks I work with are being asked by their boards to have passkeys in customer hands inside two quarters — a horizon only a buy can hit.
3. Do you have a hard data-residency or sovereignty constraint that no vendor in the market can meet? If yes, build (or buy a vendor that can deploy in your VPC or on-prem). If no, the constraint isn't real and shouldn't drive the decision.
4. Is the passkey authenticator itself a product differentiator — for example, a co-branded hardware key or an embedded SDK inside a proprietary banking device? If yes, building parts of the stack is defensible. For pure consumer banking login and step-up, the authenticator is plumbing.
5. Are you prepared to commit 1.5 FTE per year, indefinitely, to maintenance work that doesn't differentiate the bank? Browser API churn, OS releases, FIDO Metadata Service updates, OEM bug workarounds. If the honest answer is "no," that's the buy case in one question.
6. Can your in-house build credibly pass FIDO server conformance testing and produce attestation-grade audit trails on day one? If not, the cost of getting there should be added to the build column — it isn't optional for a bank.
7. Will the build need to support more than one credential provider class (platform authenticators, password managers, hardware keys) with consistent risk behavior across all of them? Multi-provider normalization is the workstream that tends to blow up in-house budgets. Buy handles it as a feature.
8. Does your bank need transaction-binding, per-transaction passkey signatures, and not just session-level authentication? If yes, that's a substantial additional build effort on top of baseline WebAuthn. Bank-grade managed layers ship it as a default.
Most mid-size and large consumer banks score 5–7 "buy" answers on this scorecard. Some institutions — very large global banks with mature platform-engineering organizations, or specialized institutions with embedded-device strategies — legitimately land on build. Both outcomes are defensible. The framework just makes the decision visible.
The financial-services deployments with the cleanest publicly documented results sit on opposite ends of the build-vs-buy continuum, which is itself a useful data point.
ABANCA, the largest bank headquartered in Galicia, built its own platform for passkey authentication on mobile banking and published the operational results through a FIDO Alliance case study in April 2025. More than 42% of roughly 1.2 million monthly mobile customers are using ABANCA Key passkeys; more than 11 million high-risk transactions have run through the passkey path without a service incident; customer-effort scores on the new flow sit at 4.7. That's a build outcome at the upper end of what build can deliver — a bank with a serious in-house identity team treating passkey infrastructure as a differentiator.
Banesco Banco Universal in Venezuela, profiled by the FIDO Alliance in May 2026, took a phased rollout over seven months and reached 2.2 million users on passkeys with roughly 92% of active users authenticating regularly through the new flow. Banesco reported a 65% reduction in identity-theft-related fraud reports and more than 12 million passwordless transactions in the program's first year, with 8.3 million of those classified as high-value. That's a vendor-supported rollout posture — closer to a buy or hybrid model — that achieved a national-scale outcome in under a year.
Aflac, the U.S. insurer that became one of the first major U.S. financial-services firms to ship passkeys, took a partner-led approach and reported the operational numbers most banks actually care about: more than 500,000 customers enrolled in the first phase, a 32% reduction in password recovery requests, and roughly 30,000 fewer monthly identity-related calls into the contact center.
The pattern across these deployments is consistent. The build path is viable for institutions with the engineering depth and strategic intent to own the stack. The buy path moves faster, hits production with less risk, and frees engineering to focus on the customer experience and risk-policy work that's actually differentiating. The build stories that struggle follow a recognizable curve. Engineering team builds a working WebAuthn server in 3—6 months. Hits the 80% mark fast. Spends the next 9—12 months on the remaining 20%: account recovery edge cases, browser regressions, multi-provider quirks, attestation handling, FIDO MDS ingestion, audit telemetry, regulator evidence formats. By the time the in-house stack is bank-grade, two of the original engineers have left, the WebAuthn spec has moved to Level 3, and the team is asking whether maintenance is worth the FTE commitment. A surprising number of these projects quietly transition to a managed vendor in year two.
Ideem's Passkeys+ is built for the buy side of this decision — specifically the bank-grade managed layer category. We sit alongside whatever IdP the bank already runs (Okta, ForgeRock, Ping, homegrown), so adopting passkeys doesn't require a re-platform. We handle the workstreams that tend to blow up in-house budgets: FIDO Metadata Service ingestion, AAGUID-based trust tiering, multi-provider normalization, transaction binding for high-value flows, and the audit telemetry a compliance team can hand to a regulator without translation.
The honest pitch is this. Banks that choose Passkeys+ aren't outsourcing the risk decision — that still belongs to the bank and its regulator. They're outsourcing the engineering and operational discipline of keeping a passkey stack production-grade through quarterly browser releases, OS updates, FIDO advisories, and the broader passkey ecosystem's evolution. That frees the bank's engineers to do the work that actually differentiates the institution: the customer experience, the risk models, the products. The passkey infrastructure underneath becomes a vendor problem, deliberately.
Looking ahead to the back half of 2026, the build-vs-buy question is going to get easier, not harder. The cost data is converging. The regulatory expectations are clearer. The bank-grade vendor category is maturing fast. The banks that make a deliberate, documented choice now — whichever direction they go — will be the ones that have a clean story to tell when the next regulator visit asks how the passkey program is being operated. The banks that drift into a build because nobody asked the question are the ones that will be re-litigating it 18 months from now, in the middle of a maintenance backlog.
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 →