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

At a glance

What this is: This is a vendor-authored analysis of build versus buy decisions for passkeys implementation, with the key finding that MVP success does not solve long-term maintenance, integration, and compliance complexity.

Why it matters: It matters because IAM teams need to treat passkeys as a lifecycle and governance decision, not just an authentication feature, especially when integrating with broader NHI and identity programmes.

By the numbers:

• This enterprise deployed FIDO-based passwordless authentication across its mobile apps, achieving 70% faster sign-ins.

👉 Read OneSpan's analysis of build versus buy decisions for passkeys implementation

Context

Passkeys implementation is an IAM and authentication governance problem, not just a user experience upgrade. The issue is whether an organisation can sustain a passwordless model across devices, native apps, web apps, backend systems, and evolving standards without creating a maintenance burden that outlives the initial rollout.

The build-versus-buy question matters because the first release is rarely the hard part. The real test is whether the programme can absorb FIDO and WebAuthn changes, support diverse environments, and avoid brittle dependencies in the authentication stack while still delivering stable access controls.

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 programmes fail after an apparently successful pilot?

A: Pilot success often hides the hard parts of authentication at scale. Failures emerge when device diversity, backend integration, and specification updates turn a simple prototype into an ongoing operational commitment that was never staffed or funded properly.

Q: What should security teams evaluate before adopting passkeys across their applications?

A: They should evaluate backend fit, application compatibility, compliance needs, and the ownership model for ongoing maintenance. If those factors are unclear, the organisation may deliver a working login flow but still fail to operate it reliably over time.

Q: When does a hybrid authentication model make more sense than a full build?

A: A hybrid model makes sense when the organisation wants control over user experience but does not need to rebuild foundational authentication plumbing. It is often the better choice when engineering capacity is limited and long-term supportability matters more than owning every component.

Technical breakdown

Why passkeys MVPs fail after launch

A minimum viable passkeys deployment proves only that authentication can work once in a constrained environment. The wider challenge is version drift, supportability, and specification churn as FIDO and WebAuthn evolve. A home-built implementation can become a dead end when teams must keep pace with browser behaviour, device support, and policy changes without a dedicated roadmap. In practice, authentication is not a one-time integration but a living control plane that must remain reliable as the environment changes.

Practical implication: judge passkeys on lifecycle support, not first-release success.

Passkeys integration across devices, apps, and backend infrastructure

Passkeys must work across native apps, browsers, devices, and the organisation's existing backend stack, including hardware security modules and secret stores. That creates an architecture problem, not just an app development task. The authentication layer has to fit current identity flows, preserve assurance, and avoid forcing invasive code changes into every application path. If the backend cannot support consistent challenge and verification logic, the passkey experience becomes fragmented and operationally expensive.

Practical implication: map backend dependencies before deciding whether to build the control in-house.

Why hybrid authentication architectures are often the practical answer

A hybrid model combines purchased foundational capability with custom components where the organisation needs differentiation. That approach recognises that not every part of authentication creates competitive value, but the underlying security and interoperability layer must be dependable. The question is where internal engineering adds unique value and where it simply recreates solved problems. For most teams, hybrid architecture reduces delivery risk while preserving room for product-specific user experience decisions.

Practical implication: reserve internal build effort for differentiating flows, not core passkey plumbing.

NHI Mgmt Group analysis

Passkeys implementation exposes an identity governance problem that starts after the MVP. The article is right to move the debate beyond initial deployment, because the real failure mode is operational drift. Authentication controls that look complete in a pilot can become fragile when device diversity, backend dependencies, and standards updates arrive at scale. The practical conclusion is that programme owners must evaluate passkeys as a living control rather than a point solution.

Build versus buy is ultimately a control-resilience decision, not a feature preference. The vendor's core argument maps to a familiar IAM pattern: organisations routinely underestimate the hidden work behind integration, maintenance, and compatibility. That matters because authentication failures often show up as fragmented user journeys, inconsistent assurance, or delayed standards adoption. Practitioners should treat implementation choice as a resilience question across the full lifecycle.

Passkeys do not remove governance obligations, they shift where they sit. The move away from passwords reduces some attack surface, but it does not eliminate the need for assurance, lifecycle management, backend trust, and dependency control. In that sense, the programme still needs architecture discipline, just applied to new control points. Teams should align passkey decisions with identity governance rather than treating passwordless as a narrow UX upgrade.

Hybrid architecture is the most realistic operating model for many enterprises. The article's strongest point is that foundational security plumbing and organisation-specific differentiation do not belong in the same build queue. Where teams have limited engineering capacity, hybrid delivery reduces the risk of overbuilding common controls while preserving flexibility for business-specific flows. The conclusion for practitioners is to separate core identity infrastructure from differentiated application design.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• The lifecycle and rotation angle is covered further in Ultimate Guide to NHIs , Key Challenges and Risks, which helps teams translate architecture choices into governance controls.

What this signals

Passkeys should be treated as an identity lifecycle capability, not a one-off authentication project. The organisations that succeed will be the ones that plan for standards change, backend evolution, and support ownership from the start. That is why the governance question is not whether passkeys work, but whether the programme can remain operable after the initial deployment window closes.

The broader signal is that authentication programmes are converging with NHI-style operational thinking. Once credentials, device bindings, and backend trust relationships become part of the design, the control surface behaves more like an identity lifecycle system than a simple login method. Teams that still separate authentication architecture from lifecycle governance will miss the maintenance burden until it becomes expensive.

Identity teams should expect more pressure to justify platform decisions with maintenance economics. Building in-house may look attractive at the point of concept, but the long-term cost is usually carried in updates, compatibility testing, and exception handling. Organisations with constrained engineering capacity should prioritise operating model clarity before they prioritise customisation.

For practitioners

• Set explicit passkey lifecycle criteria before build decisions Define what must remain supportable after MVP launch, including FIDO and WebAuthn updates, device coverage, and operational ownership for changes.
• Inventory backend dependencies early Map how passkeys will integrate with hardware security modules, secret stores, and existing authentication paths before committing engineering effort.
• Separate core controls from differentiating features Use purchased capability for foundational authentication functions and reserve custom development for experience elements that actually differentiate the business.
• Test implementation against compliance and supportability requirements Validate that the chosen approach can satisfy regulatory constraints, device variation, and long-term maintenance without repeated redesign.

Key takeaways

• Passkeys reduce password risk, but they create a governance obligation around compatibility, maintenance, and lifecycle support.
• The main build-versus-buy question is whether your team can sustain FIDO and WebAuthn change over time without creating brittle authentication dependencies.
• A hybrid approach is often the most practical model because it separates foundational control from business-specific experience design.

Key terms

• Passkeys Implementation: The process of deploying passwordless authentication based on FIDO and WebAuthn across applications, devices, and supporting infrastructure. In practice, it includes integration, lifecycle support, compliance alignment, and operational ownership, not just replacing a login screen with a new authenticator.
• Passwordless Authentication: An authentication method that removes passwords and uses stronger cryptographic credentials instead. For security teams, the value is lower phishing exposure, but the control still depends on enrollment, device binding, backend trust, and ongoing maintenance to remain reliable.
• Hybrid Authentication Architecture: A model that combines purchased authentication capabilities with custom-built components. It is useful when organisations want foundational security to be dependable while keeping room to tailor user experience or business-specific flows without rebuilding core identity plumbing.
• WebAuthn: A web standard that lets browsers and platforms support public-key authentication for passwordless login. It defines how authenticators and relying parties exchange challenges and responses, and it must be managed carefully because support and implementation details evolve over time.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by OneSpan: Passkeys implementation, build or buy? Read the original.