What is the difference between building passkeys from scratch and using a managed workflow to deploy them?

Why This Matters for Security Teams

Passkeys are often treated as a simple authentication upgrade, but the build-versus-managed choice changes how much identity engineering, verification logic, and operational ownership the team must carry. Building from scratch can fit unusual policy needs, yet it also puts protocol handling, attestation decisions, recovery design, and audit evidence in the team’s hands. A managed workflow reduces delivery risk, but it may constrain how finely the organisation can tune enrollment, lifecycle, and user experience.

This tradeoff matters because passkeys sit inside a wider identity control plane, not just a login screen. Security teams still need to answer who can enroll, how devices are trusted, how lost credentials are handled, and what evidence exists for assurance reviews. The difference is especially clear when measured against broader identity governance expectations in the NIST Cybersecurity Framework 2.0 and the lifecycle and offboarding emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful reminder that control gaps often start in lifecycle design, not in cryptography.

In practice, many security teams discover the hidden cost of “simple” authentication only after enrollment exceptions, recovery failures, or audit requests expose how much was left implicit.

How It Works in Practice

Building passkeys from scratch usually means the team implements the relying party logic, server-side verification, registration and authentication ceremonies, storage for public keys and metadata, and the policies that govern recovery and device trust. That approach gives maximum control over UX and integration, but it also means the team owns every edge case, including attestation policy, synchronised credential behaviour, and account recovery flows.

A managed workflow abstracts much of that work behind hosted screens, SDKs, or reusable components. The provider handles protocol details and often ships a faster path to production, while the team focuses on policy decisions such as which users are eligible, whether specific device classes are allowed, and what assurance level is required. Current guidance suggests teams should evaluate the workflow using the same identity governance lens they would apply to any sensitive access path, including logging, segregation of duties, and recovery controls.

• Use custom builds when you need deep control over policy, branding, or unusual integration paths.
• Use managed workflows when speed, consistency, and reduced implementation risk matter more than granular control.
• Treat enrollment, recovery, and revocation as first-class lifecycle events, not secondary support tasks.
• Document who can override policy, because recovery paths often become the weakest trust boundary.

The operational difference becomes clearer when mapped to control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and the lifecycle guidance in NHI Lifecycle Management Guide. The practical test is whether the chosen workflow lets the organisation prove enrollment integrity, recovery governance, and revocation discipline without relying on manual workarounds. These controls tend to break down in highly regulated environments with custom attestation requirements and legacy directories because the managed path may not expose enough policy hooks.

Common Variations and Edge Cases

Tighter control over passkey implementation often increases engineering and assurance overhead, so organisations must balance customisation against delivery speed and support burden. There is no universal standard for how much should be outsourced yet, especially when passkeys are being introduced alongside legacy MFA or phased identity modernization.

Some teams need a hybrid model: managed enrollment for most users, but custom policy layers for administrators, contractors, or high-assurance workflows. Others discover that migration complexity, not passkey protocol design, is the real issue because existing recovery methods, help desk processes, and device trust rules were never designed for passwordless authentication. The right choice depends on whether the organisation is optimising for speed, compliance evidence, or deep control over the authentication journey.

For broader governance context, the lifecycle and audit discussion in Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful when passkeys must satisfy assurance reviewers, and the breach patterns in Top 10 NHI Issues help illustrate how lifecycle gaps become security gaps. The hard edge case is a mixed estate with legacy authentication, strict audit obligations, and limited identity engineering capacity, because managed workflows may accelerate rollout while still leaving recovery and exception handling under-defined.

Related resources from NHI Mgmt Group

• What is the difference between keeping secrets in Sealed Secrets and using an external secrets manager with GitOps?
• What is the difference between governance controls in a self-hosted gateway and a managed gateway?
• What is the difference between securing enterprise applications with point tools and using ASPM?
• What is the difference between Kubernetes Secrets and externally managed secrets for workload access?