Should organisations build or buy a passkey solution?

Why This Matters for Security Teams

passkey are often framed as a simple replacement for passwords, but the build-or-buy decision is really about who will own authentication policy, recovery, telemetry, and lifecycle risk. That matters because identity mistakes do not stay confined to the login layer. When access is poorly governed, it spills into privilege sprawl, weak recovery paths, and inconsistent enforcement across apps, devices, and partner flows. NHI Mgmt Group’s Ultimate Guide to NHIs — The NHI Market shows why this ownership problem matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames.

For security teams, the key question is not whether passkeys are stronger than passwords, but whether the organisation can sustain assurance over time. A purchased platform may accelerate rollout, yet it still needs policy, auditability, fallback controls, and integration with broader identity governance. That aligns with the direction of the NIST Cybersecurity Framework 2.0, which emphasises governance, protection, and continuous improvement rather than one-time deployment. In practice, many security teams encounter passkey drift only after recovery failures, account takeovers, or inconsistent admin exceptions have already been embedded into production.

How It Works in Practice

Building a passkey solution usually means taking on the WebAuthn layer, device binding logic, recovery design, attestation policy, logging, and the edge cases around lost devices, shared endpoints, and regulated users. Buying typically shifts the cryptography and UX burden to a vendor, but it does not remove internal responsibility. The organisation still has to decide who can register authenticators, what assurance level is acceptable, how step-up works, how recovery is verified, and when to force re-enrolment. That is why passkey programs should be treated as an identity control plane decision, not a product purchase.

Current guidance suggests using standards-based architecture wherever possible. The NIST Cybersecurity Framework 2.0 is useful for mapping passkey work to governance and protection outcomes, while implementation teams can use the same discipline reflected in NHI guidance from Ultimate Guide to NHIs — The NHI Market to avoid treating credentials as isolated objects. A practical evaluation usually includes:

• Whether the team can own secure recovery without introducing weaker fallback methods.
• Whether the solution supports phishing-resistant authentication across all user populations.
• Whether policy, reporting, and audit logs can be integrated with existing IAM and PAM controls.
• Whether the organisation can enforce lifecycle events such as revocation, re-enrolment, and exception handling.

Buying is often the better default when speed, compliance, and operational maturity matter more than deep customisation, but only if the vendor model fits enterprise governance. These controls tend to break down in highly distributed environments with complex legacy apps and outsourced support, because recovery and exception handling become inconsistent across channels.

Common Variations and Edge Cases

Tighter control often increases engineering and governance overhead, requiring organisations to balance custom assurance against delivery speed. That tradeoff becomes sharper in regulated industries, mergers, or environments with multiple authentication domains. There is no universal standard for this yet on whether every passkey function should be built in-house or bought as a service, so current guidance suggests deciding by operating model rather than technical pride. If the organisation cannot support lifecycle ownership, a bespoke build can become an expensive way to create a fragile control.

Some edge cases favour building. Large platforms with their own identity stack may need custom assurance tiers, brand-specific user journeys, or integration with zero trust policies that are difficult to express in a packaged tool. Other cases favour buying, especially where teams need rapid deployment, mature recovery workflows, and external certification support. The main risk is assuming a vendor will solve governance automatically. Security teams still need policy for device registration, fraud review, access revocation, and exception approval. The NHI market guidance from Ultimate Guide to NHIs — The NHI Market reinforces a broader pattern: control without lifecycle ownership does not hold up for long, even when the front-end authentication looks modern.

For most organisations, the right answer is a hybrid one: buy the baseline passkey capability, then build the policy, recovery, and assurance layers that reflect internal risk tolerance. That is the point where passkeys stop being a login feature and become a durable identity control.

Related resources from NHI Mgmt Group

• How can organisations decide whether to buy a standalone red teaming tool or a broader platform?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?