Passkeys build vs. buy: the governance trade-offs behind MVPs

At a glance

What this is: This is OneSpan's analysis of build-versus-buy decisions for passkeys, with the central finding that MVP success is not enough if long-term compatibility, maintenance, and integration are not built into the authentication strategy.

Why it matters: IAM teams evaluating passwordless rollouts need to account for lifecycle governance, backend dependencies, and future specification change, not just initial implementation speed.

By the numbers:

• An enterprise in the case study achieved 70% faster sign-ins after deploying FIDO-based passwordless authentication across mobile apps.

Context

Passkeys are a passwordless authentication method based on FIDO and WebAuthn, but the governance question is not whether they can work in principle. The harder issue is whether the organisation can maintain them across devices, application types, backend systems, and changing standards without creating a brittle deployment.

For IAM and identity architects, the build-versus-buy decision is a lifecycle question, not a proof-of-concept question. A passkey MVP can mask integration debt, specification drift, and support burden until the programme has already become business-critical.

Key questions

Q: How should teams decide whether to build or buy passkeys infrastructure?

A: Teams should compare the full lifecycle cost, not just the initial delivery cost. A build decision is only defensible if the organisation can maintain compatibility, support diverse environments, and absorb future FIDO and WebAuthn changes without creating brittle dependencies or major rework.

Q: Why do passkey MVPs create governance risk after launch?

A: Because a successful MVP proves only that one controlled flow works. It does not prove the authentication stack will remain compatible with new devices, evolving FIDO and WebAuthn specifications, diverse applications, and production infrastructure. The risk is not initial adoption failure. The risk is that the control cannot keep pace once it becomes business critical.

Q: What are the main failure points when building passkeys in-house?

A: The most common failure points are backend integration, cross-device compatibility, and maintenance after standards change. Teams often underestimate how much engineering is needed to fit passkeys into existing identity flows and supporting infrastructure. That creates delivery delays, unexpected rework, and a brittle production control that is expensive to sustain.

Q: What should organisations include in the total cost of passkeys?

A: Include implementation, integration, device support, regression testing, spec updates, and ongoing maintenance. Cost models that stop at the first deployment miss the work needed to keep the authentication path reliable over time. For passkeys, the question is not only what it takes to go live, but what it takes to remain current.

Technical breakdown

Why passkey MVPs hide lifecycle risk

A minimum viable passkey deployment proves that authentication can work in one controlled slice of the environment, but it does not prove that the programme will survive version changes, device diversity, or backend complexity. FIDO and WebAuthn implementations are not static. They depend on continuing compatibility across clients, platforms, and security tooling. The technical trap is assuming the first successful login path equals a durable architecture. In practice, the engineering effort shifts from initial delivery to ongoing interoperability and maintenance once the pilot becomes production. Practical implication: treat passkeys as an evolving identity control, not a one-time feature build.

Practical implication: Design passkey programmes for ongoing interoperability, not just initial sign-in success.

Backend integration and secret store dependencies

Passkeys do not live in isolation. They have to fit into existing identity flows, backend infrastructure, cloud hardware security modules, and secret stores. That creates dependency coupling between authentication, key management, and platform operations. If the passkey implementation is built without those dependencies in mind, teams end up patching architecture after go-live, which increases fragility and code churn. The article's core point is that the authentication layer is only as stable as the infrastructure it sits on. Practical implication: evaluate whether the backend estate can support the authentication model before code is written.

Practical implication: Map backend dependencies early, especially around HSMs and secret stores.

Why specifications change the economics of build versus buy

The governance burden is not limited to shipping the first version. FIDO and WebAuthn specifications evolve, and each change can force new testing, validation, and code updates. Built-in-house teams absorb that maintenance cost directly, while vendor-backed implementations spread it across a broader product lifecycle. That does not make buying automatically right, but it changes the economics of ownership. The article's strongest message is that hidden maintenance costs often outweigh the apparent savings of a custom build. Practical implication: budget for future specification maintenance as part of the authentication programme, not as an exception.

Practical implication: Include specification maintenance in the total cost of ownership for passkeys.

NHI Mgmt Group analysis

Passkeys are a governance programme, not just an authentication feature: The article is really about operational durability, not login mechanics. An MVP can validate the protocol path while still leaving future compatibility, support, and maintenance unresolved. That makes passkey planning an IAM architecture decision, not a discrete security experiment. Practitioners should judge the control by whether it survives production change, not whether it works in the first release.

The real build-versus-buy variable is lifecycle ownership: In-house development concentrates the cost of integration, version drift, and backend adaptation inside the organisation. Buying shifts more of that burden into a product lifecycle that already expects specification updates and environment support. The distinction matters because passkeys fail operationally when maintenance is treated as a side task rather than a standing governance function. Teams should compare ownership models, not just implementation effort.

Hybrid models are often the practical middle ground: The article correctly points to a split approach where differentiated experience is custom and the underlying authentication foundation is standardized. That aligns with how mature IAM programmes usually evolve, because not every control layer should be bespoke. The challenge is knowing which parts create business value and which parts merely recreate commodity infrastructure. Practitioners should reserve custom work for the user experience and keep the authentication core predictable.

Passkey governance exposes a broader authentication debt problem: Organisations that frame passwordless adoption as a one-time migration tend to undercount the operational work required to keep the system trustworthy. The underlying assumption is that authentication can be frozen after launch. That assumption fails when device diversity, regulatory expectations, and specification changes keep moving. The implication is that identity teams need to budget for continuous authentication governance, not project closure.

Named concept: passkey maintenance debt: The article surfaces a recurring risk where the apparent simplicity of passwordless adoption hides the ongoing cost of compatibility, testing, and support. That debt accumulates as the environment changes and as standards mature. Practitioners should treat maintenance debt as part of the control design, because it determines whether passkeys remain viable after the pilot phase.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.

What this signals

Passkey programmes fail when teams optimise for the first release instead of the operating model: The article points to a familiar IAM pattern. Organisations get the MVP working, then discover that support, compatibility, and standards change are where the real programme cost sits. Teams planning passwordless rollouts should treat lifecycle ownership as part of the control, not as post-launch administration.

Passkeys expose an authentication maintenance debt that many identity programmes still underbudget: The underlying problem is not simply whether passkeys are secure. It is whether the organisation can keep the control aligned with changing devices, backend systems, and specifications without creating a fragile exception path. That makes passkeys a useful test of IAM maturity, especially where identity architecture is already fragmented.

For practitioners

• Define the production boundary for the MVP Document which devices, app types, and backend dependencies the first passkey release must support, and which ones remain out of scope until later phases.
• Inventory backend authentication dependencies Map the current reliance on cloud hardware security modules, secret stores, and identity infrastructure before deciding whether the programme can be built safely in-house.
• Cost the maintenance burden explicitly Include FIDO and WebAuthn update work, regression testing, and compatibility support in the total cost model instead of treating them as future exceptions.
• Use a hybrid delivery model where it fits Keep commodity authentication plumbing standardised while reserving custom development for areas that affect user experience or business differentiation.

Key takeaways

• Passkey implementations create governance risk when the organisation treats the MVP as the finish line instead of the start of lifecycle ownership.
• The main pressure points are compatibility, backend integration, and specification maintenance, which all expand the true cost of a build decision.
• IAM teams should evaluate passkeys as an operating model question, using hybrid delivery where custom code adds value and standard plumbing reduces long-term fragility.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• WebAuthn: WebAuthn is a browser and platform standard for phishing-resistant authentication using public-key cryptography. It binds the authenticator to the origin and signs a challenge instead of sending a reusable code, which makes replay and relay attacks far harder.
• FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
• Authentication lifecycle: The authentication lifecycle is the full sequence of controls that decide whether an identity is trusted, from sign-up and verification through sign-in, session handling, and recovery. It matters because attackers do not need to beat every control if one stage leaks trust or creates a reusable session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.