Passkey execution, not awareness, is the real authentication gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: At RSAC 2026, awareness of workforce passkeys was high, but execution still breaks on enrolment, device choice, recovery, and lifecycle management.

Why it matters: It matters because IAM teams cannot treat passkeys as a simple login replacement; they have to design the operational controls that make phishing-resistant authentication work across real users, devices, and recovery paths.

Context

Passkeys are a phishing-resistant authentication method built on FIDO standards, but the governance problem is no longer whether the technology exists. The article’s central point is that organisations still struggle to turn passkey intent into operational identity workflows across enrolment, devices, recovery, and day-to-day support.

For IAM teams, that shifts the discussion from awareness to execution. The real challenge is whether workforce authentication can be introduced without breaking device strategy, recovery processes, or session continuity, especially where shared devices, contractors, and mixed assurance requirements are in scope.

Key questions

Q: Why do passkey rollouts fail even when users understand them?

A: Passkey rollouts usually fail because the surrounding identity operations are not ready. Enrolment, device binding, recovery, and deprovisioning must all work together. If those controls are fragmented, the authentication method may be strong on paper but weak in practice, especially when support teams handle exceptions outside the normal workflow.

Q: How should teams decide between platform and hardware authenticators?

A: Teams should choose by user context, not by convenience alone. Managed endpoints, shared devices, contractors, and high-assurance roles often need different authenticator choices. The right decision depends on device ownership, support model, assurance target, and how tightly the organisation can govern registration and recovery.

Q: What are the biggest passkey implementation mistakes?

A: The biggest mistakes are treating passkeys as a password swap, separating recovery from assurance, and ignoring lifecycle management. When enrolment, support, and deprovisioning are not designed together, organisations create bypass paths that undermine the security benefit they were trying to gain.

Q: How do you know if passkeys are actually improving security?

A: Look for fewer password-reset events, lower phishing exposure on supported journeys, and stable or improving completion rates for enrollment and recovery. If support tickets rise sharply or fallback use dominates, the programme may be shifting risk rather than reducing it. The best signal is improved assurance without degraded account access.

Technical breakdown

Why passkey deployments fail at the identity binding layer

Passkeys only work when the authenticator is bound to the right identity, device state, and recovery path. In practice, that means provisioning, registration, and account recovery have to line up with existing identity lifecycle controls. If those links are weak, the authentication method may be sound while the operating model collapses around it. The article points to a common mistake: treating passkeys as a front-end replacement for passwords rather than as a lifecycle and binding problem. That is why rollout often stalls even when user acceptance is strong.

Practical implication: map enrolment, device binding, and recovery into the same governance flow before broad rollout.

Shared devices, hardware authenticators, and workforce access strategy

Many teams start with platform authenticators because they are convenient, but that approach does not cover every workforce scenario. Shared devices, managed endpoints, contractors, and higher-assurance roles can require hardware authenticators or more deliberate registration choices. The technical issue is not merely device support. It is matching authenticator type to assurance needs, endpoint ownership, and supportability across the full workforce population. That makes passkey strategy an architecture decision, not a user-experience preference.

Practical implication: segment users by device context and assurance need before standardising on one passkey model.

Why authentication is no longer the end of the security model

The article reflects a broader shift from point-in-time login to continuous, context-aware security. Once a user is authenticated, the programme still has to manage sessions, transactions, and real-time risk decisions. That matters because the security boundary increasingly moves beyond the login moment. Passkeys reduce credential phishing risk, but they do not replace session governance or transaction controls. For IAM teams, authentication is becoming the start of enforcement, not the finish line.

Practical implication: pair passkey rollout with session and transaction controls rather than treating authentication as a closed control.

NHI Mgmt Group analysis

Passkey awareness is no longer the limiting factor; operational binding is. The article shows that most teams already understand the value of passwordless authentication, but execution breaks when enrolment, recovery, and device strategy are not aligned. That is an identity governance problem, not a standards problem. The practitioner lesson is to treat passkeys as a governed lifecycle, not a product choice.

Identity binding for passkeys is the real control plane. If the authenticator cannot be bound consistently to the right user, device context, and recovery process, the deployment becomes brittle even when the cryptography is sound. This is where workforce identity, device governance, and help desk operations intersect. The implication is that rollout success depends on the surrounding identity system, not on passkey familiarity alone.

Shared-device and contractor scenarios expose the limits of one-size-fits-all authentication. The article is clear that many teams still think in terms of a single platform authenticator model, while real environments include managed endpoints, shared devices, and higher-assurance users. That creates a governance gap between policy and operational reality. The programme implication is to design for user classes, not just for a universal login pattern.

Continuous authentication thinking will reshape the identity perimeter. Once passkeys are treated as the start of access rather than the finish, session governance and transaction controls become part of the same conversation. That matters as AI systems and agents enter the identity landscape, because the control model cannot stop at initial verification. The practitioner conclusion is that authentication strategy must now extend into runtime access governance.

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 execution now sits at the intersection of identity, device, and support governance. Teams that roll out passwordless authentication without operational clarity often discover that the hardest problems emerge after sign-in, not before it. That is why rollout plans need explicit ownership for enrolment, recovery, and exception handling.

Lifecycle discipline is the differentiator. The organisations that will sustain passkeys are the ones that govern re-registration, device replacement, and account recovery as part of identity lifecycle management rather than as edge cases. If those flows are loose, phishing resistance is diluted by operational workarounds.

For practitioners

• Map the passkey lifecycle end to end Document enrolment, recovery, device replacement, and deprovisioning as one workflow so the authentication method stays governed after first login.
• Classify users by device and assurance profile Separate shared-device users, managed-endpoint users, contractors, and higher-assurance roles before choosing platform or hardware authenticators.
• Align recovery with identity assurance Make account recovery and credential re-issuance follow the same assurance rules as enrolment, or the strongest authenticator will be bypassed through support.
• Extend controls beyond login Tie passkey rollout to session monitoring, transaction checks, and real-time risk handling so authentication is not the last control in the chain.

Key takeaways

• Passkey adoption is being constrained less by understanding of FIDO and more by the operational work needed to deploy it cleanly.
• The main friction points are enrolment, device strategy, recovery, and lifecycle management across real workforce environments.
• Passkeys improve authentication strength, but IAM teams still need session and transaction controls to complete the security model.

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.
• 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.
• Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.
• Continuous authentication: A model where access is re-evaluated after the initial login instead of being trusted for the full session. It uses live signals such as posture, telemetry, and policy to detect when a session should be stepped up, constrained, or revoked.

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.