Passkeys, passwordless adoption and the identity trade-off for IAM teams

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: Authentication choice is increasingly a governance and rollout decision, not only a user-experience one.

Why it matters: It matters because IAM teams have to weigh phishing resistance, recovery design, user migration, and control fit as passkeys move into mainstream workforce and consumer authentication.

By the numbers:

• Gartner found that 72% of authentication-related inquiries in 2025 were about passwordless authentication.
• Passkeys were shown with a 93% login success rate compared with around 63% for passwords.

Context

Passwordless authentication is becoming a mainstream IAM design choice rather than a specialist option. In practice, that means teams are no longer deciding only whether to remove passwords, but how to handle enrollment, recovery, device change, and policy enforcement across different user populations.

Passkeys matter because they change the balance between usability and control. Syncable passkeys and device-bound passkeys support different operating models, so the governance question is not whether to adopt passkeys everywhere, but which passkey pattern fits the risk, regulatory, and support model of each use case.

For IAM programmes, the core issue is adoption path. Introducing passkeys alongside existing methods may reduce disruption, but it also creates a mixed-authentication state that has to be governed deliberately until the transition is complete.

Key questions

Q: How should security teams roll out passkeys without creating support problems?

A: Start with recovery design, user communication, and help desk readiness. Passkeys usually fail at adoption when teams skip operational planning and treat the rollout as a simple login change. Define re-enrolment, backup authentication, and revocation steps before expansion, then stage deployment by user group and risk level.

Q: When do passkeys create more operational risk than they reduce?

A: They create more risk when teams deploy them before defining device loss recovery, origin stability, and cross-platform testing. In that state, passwordless login can increase lockouts, support calls, and exception handling even if the cryptography is sound.

Q: What breaks when passkey recovery is not governed properly?

A: The programme falls back to the weakest legacy recovery path, which attackers often target first. If help-desk verification, device replacement, or fallback login is inconsistent, the user can still be phished or socially engineered even when the primary login is passkey-based.

Q: Should organisations build or buy a passkey solution?

A: Choose based on operating capacity, not ideology. Building can give tighter control and customisation, but it demands more engineering and governance ownership. Buying can speed deployment, but the organisation still has to own policy, recovery, assurance, and long-term authentication strategy.

Technical breakdown

Syncable passkeys versus device-bound passkeys

Passkeys are FIDO credentials stored on a device or in a synced credential store, but the control model differs depending on whether they can move across devices. Syncable passkeys improve portability and reduce recovery friction, while device-bound passkeys give tighter possession binding and clearer endpoint control. The technical trade-off is between user continuity and stronger device assurance. In regulated environments, that trade-off affects how authentication assurance, recovery, and device trust are balanced across populations.

Practical implication: classify use cases by assurance need before standardising on one passkey model.

Why passkey rollout is usually hybrid first

Most organisations do not replace passwords overnight. They introduce passkeys alongside existing authentication methods, which creates a hybrid authentication estate during migration. That estate needs policy logic for enrollment, fallback, recovery, and step-up decisions so users do not get stranded when a device changes or a passkey is unavailable. The technical challenge is less about the passkey protocol itself and more about operating two authentication paths without weakening assurance.

Practical implication: design explicit fallback and recovery flows before enabling passkeys at scale.

Build versus buy for passkey delivery

Passkey deployment is not just a protocol decision. Organisations have to decide whether to build orchestration, enrollment, recovery, and policy handling themselves or use an external solution that abstracts some of that complexity. The architectural question is about scalability, speed, internal maintenance, and long-term flexibility. In IAM terms, this is a control boundary decision, because the implementation choice determines how much of the authentication lifecycle stays inside the identity stack versus a separate platform.

Practical implication: evaluate whether your team can sustain the lifecycle and support burden of a custom passkey architecture.

NHI Mgmt Group analysis

Passkeys are now an authentication governance issue, not just a login improvement. Once organisations move beyond pilot use, the real question becomes how authentication policy, fallback paths, and recovery workflows are governed across mixed populations. That is where IAM teams must stop treating passwordless adoption as a feature choice and start treating it as an operating model decision.

Passkey migration exposes the hidden cost of hybrid authentication states. Passwords rarely disappear at the same pace as passkeys are introduced, so teams end up supporting parallel controls, exception handling, and support processes for longer than planned. The result is a governance burden that is easy to underestimate and hard to reverse.

Phishing resistance is only one part of the control story. Passkeys strengthen the authentication factor itself, but the surrounding lifecycle still matters: enrollment, device replacement, account recovery, and policy exceptions all become part of the risk surface. The practical conclusion is that passwordless success depends on identity operations, not on the credential format alone.

The build versus buy decision is really about control ownership. A custom approach may preserve design flexibility, but it also shifts more lifecycle responsibility into the organisation's IAM team. A purchased approach may reduce implementation effort, yet it still requires the same governance decisions about assurance, integration, and support boundaries.

Passwordless transition debt: the period where organisations keep passwords alive while passkeys are being adopted is a real governance phase, not a temporary inconvenience. During that phase, teams carry duplicated authentication paths, unclear recovery expectations, and inconsistent user experiences. The implication is that transition management needs the same discipline as steady-state identity architecture.

What this signals

Passwordless adoption is becoming a control-plane decision. Teams should expect passkey deployment to touch policy, recovery, support, and exception handling, not just authentication UX. The practical risk is treating passwordless as a narrow login project and underfunding the operating model required to keep it stable.

Hybrid authentication states deserve a named governance period. When passwords and passkeys coexist, the organisation needs clear ownership for fallback paths, user migration, and recovery design. Without that discipline, the transition phase becomes a long-lived support burden rather than a controlled change.

Passkey rollout should be measured by operational signals, not adoption slogans. Help desk load, fallback frequency, and recovery volume tell you whether passwordless is reducing friction or moving it into another part of the identity stack.

For practitioners

• Map authentication populations by assurance need Separate consumer, workforce, privileged, and regulated journeys before selecting a passkey model. Use different policy settings for device-bound and syncable credentials where the risk profile differs.
• Design fallback and recovery paths first Document what happens when a passkey is lost, a device changes, or a user must switch factors. Recovery should preserve assurance without forcing insecure bypasses.
• Run passkeys in parallel with existing methods Introduce passwordless options alongside current authentication so adoption can scale without forcing a hard cutover. Govern the coexistence period explicitly so exception handling does not become permanent.
• Decide who owns the passkey lifecycle Assign clear ownership for enrollment, support, recovery, and policy exceptions. If those responsibilities are split across teams or vendors, the operational model needs documented handoffs.
• Measure adoption beyond sign-in success Track fallback usage, recovery volume, help desk load, and failure rates by user segment. Those signals show whether passkeys are reducing friction or merely shifting it elsewhere.

Key takeaways

• Passkeys are changing IAM planning because authentication design now affects governance, support, and rollout strategy, not just login experience.
• The biggest implementation risk is the transition period, when passwords and passkeys coexist and control ownership can become unclear.
• Teams that want passwordless success need explicit policies for recovery, fallback, and lifecycle ownership before they scale adoption.

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.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• Device-Bound Passkey: A device-bound passkey is a FIDO credential tied to one physical device and generally stored in hardware-backed secure components. The value for enterprise security is lifecycle control, because the credential is easier to inventory, constrain, and revoke without relying on cloud sync paths.
• Syncable Passkey: A syncable passkey is a passkey that can move across a user’s devices through a trusted ecosystem. It improves convenience and recovery, but it also broadens the portability of the credential, which matters when the organisation needs stronger device-level control or tighter assurance boundaries.

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.