World passkey day shows passkey scale still depends on orchestration

At a glance

What this is: This is a practitioner-focused analysis of what it takes to run passkeys at enterprise scale, with the key finding that rollout success depends more on orchestration and recovery design than on the credential itself.

Why it matters: It matters because IAM teams need to treat passkeys as part of a wider authentication lifecycle, not a front-end swap, or they risk creating weak recovery paths, brittle step-up policies, and support burden that erodes adoption.

By the numbers:

• 87% of enterprises are deploying or have already deployed them.
• Google reports 2.5 billion passkey sign-ins across 800 million accounts.
• Around half of the world's top 100 websites support them.

👉 Read Authsignal's analysis of how to deliver passkeys at scale in 2026

Context

Passkeys are a phishing-resistant authentication method, but enterprise adoption exposes a broader identity governance problem: the credential is only one part of the operating model. The article argues that scale depends on enrollment timing, recovery, fallback hierarchies, risk-based step-up, and orchestration across channels, which are the controls IAM teams must align.

The primary issue is not whether passkeys work, but whether the surrounding authentication programme can absorb the edge cases that appear after rollout begins. That makes this a human IAM and lifecycle conversation as much as a product choice, because support flows, recovery, and session policy now determine whether passkey deployments become durable or stall in production.

Key questions

Q: How should security teams implement passkeys without weakening account recovery?

A: They should treat recovery as a higher assurance journey than initial sign-in. That means multi-factor recovery, tightly controlled support-assisted verification, and no fallback path that relies on a weaker factor than the passkey itself. If recovery can be social-engineered, the deployment still has a password-shaped hole in the back wall.

Q: Why do passkey deployments still need risk-based step-up?

A: Passkeys reduce phishing risk, but they do not remove session hijacking, insider abuse, compromised devices, or risky behaviour after login. Risk-based step-up keeps low-risk actions frictionless while forcing fresh authentication only when context changes. That is how teams preserve usability without trusting every session equally.

Q: What do security teams get wrong about passkey adoption at scale?

A: They often treat passkeys as a replacement credential instead of a governed authentication system. The result is poor timing for enrollment, weak recovery paths, and fragmented decisions spread across the app, the identity provider, and the helpdesk. Scale comes from orchestration, not from the credential alone.

Q: How should IAM teams measure whether passkeys are actually working?

A: Track adoption, recovery failures, support ticket mix, step-up challenge rates, and takeover attempts together. A healthy rollout shows higher activation, lower password and SMS reliance, and controlled recovery volume without a rise in account abuse. If support load or fraud rises, the programme is not mature yet.

Technical breakdown

Enrollment timing and passkey activation at scale

Passkey enrollment behaves like a policy problem, not a static UI choice. The best results come from triggering enrollment at a moment of user readiness, such as immediately after successful login, rather than hiding it in settings. At scale, teams also need rules for first-time registration, returning users, decline cool-downs, and device context so the prompt appears only when it makes sense. This turns passkey uptake into a governed authentication journey, not a one-off feature launch.

Practical implication: define enrollment triggers and suppression rules centrally, then measure them as policy outcomes rather than UI metrics.

Recovery paths, fallback hierarchy, and channel coverage

Recovery is the part of passkey design most likely to reintroduce weak identity assurance. If a user loses the device or sync ecosystem that stores the passkey, the recovery path must be stronger than the original sign-in factor, otherwise the account can be re-registered through a weaker channel. That is why multi-factor recovery, support-assisted verification, and omnichannel consistency matter. The recovery flow is effectively a second authentication system, and it needs its own assurance model.

Practical implication: review recovery as a privileged journey and remove any fallback that lets an attacker downgrade assurance through email-only or knowledge-based steps.

Risk-based step-up and orchestration across the authentication graph

Passkey scale depends on orchestration because enrollment, recovery, step-up, and fraud signals all share state. A risky action should prompt re-authentication based on context, not on a rigid timer, and the rules need to be maintainable without constant code changes. The architectural pattern described here separates the orchestration layer from the identity provider, which lets the IDP continue issuing sessions while policy logic handles context, factor selection, and lifecycle events across channels.

Practical implication: separate decision policy from identity issuance so you can adjust assurance requirements without rebuilding the application stack.

Threat narrative

Attacker objective: The objective is to preserve account access by exploiting the recovery and fallback layer after initial authentication.

1. Entry occurs through a legitimate sign-in path that successfully authenticates the user but does not yet establish durable assurance across the full account lifecycle.
2. Credential access and persistence emerge when weak recovery lets an attacker re-register access or replace the enrolled factor after compromise.
3. Impact is account takeover or support burden, because the attacker keeps a trusted authentication path while the organisation believes passkeys have solved the risk.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passkeys do not reduce identity complexity, they relocate it. The article shows that the credential itself is only one control point in a larger authentication graph. Enrollment, recovery, step-up, and support all become part of the governance surface, which means IAM programmes must manage the full lifecycle rather than the login event.

Recovery is the real assurance boundary in passkey programmes. If a user can regain access through a weaker factor than the passkey, the organisation has created a downgrade path that undermines the entire deployment. That failure mode is familiar in NHI governance too: the control that matters is the one that survives the loss of the primary credential, not the one that looks strongest on day one.

Orchestration is the named concept that separates passkey adoption from passkey operations. This is the policy layer that decides when to enroll, when to step up, when to suppress, and when to recover across channels. Without it, teams end up with disconnected authentication decisions that are hard to audit, hard to tune, and easy to bypass.

Passkey scale is now a lifecycle problem, not an authentication feature problem. The article’s production lessons line up with NIST SP 800-63 and NIST CSF thinking: assurance only holds if identity proofing, authenticators, recovery, and session management are governed together. Practitioners should treat passkeys as part of continuous identity operations, not a one-time migration milestone.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Passkey programmes run into the same operational problem when recovery and orchestration are treated as assumptions rather than governed controls, which is why the Ultimate Guide to NHIs remains relevant to lifecycle design.

What this signals

Orchestration debt: passkey programmes accumulate hidden governance debt when enrollment, recovery, and step-up are implemented as separate flows rather than one policy system. That debt shows up first in support, then in fraud, then in inconsistent assurance across channels. The organisations that mature fastest are the ones that treat policy composition as part of identity architecture, not an afterthought.

The operational signal to watch is whether passkey adoption reduces password and SMS reliance without increasing recovery exceptions or helpdesk dependency. If the support queue changes shape but not volume, the programme may be shifting risk rather than lowering it. That is a strong indicator that the surrounding authentication lifecycle still needs redesign.

For practitioners

• Define passkey enrollment as a policy workflow Trigger enrollment at specific moments such as post-login, first registration, or controlled uplift points. Use decline cool-downs and device awareness so the prompt is governed rather than sprayed across the user journey.
• Strengthen recovery above the original sign-in factor Map every recovery path to a higher assurance level than the passkey itself, and remove email-only or knowledge-based fallback that can be socially engineered.
• Separate orchestration from session issuance Keep passkey, MFA, recovery, and step-up logic in a policy layer that can be tuned without redeploying the application or modifying the identity provider directly.
• Use contextual step-up for high-risk actions Require fresh authentication for sensitive actions using device, network, velocity, and behavioural signals instead of a fixed re-authentication timer.
• Measure support and fraud outcomes together Track recovery-related tickets, SMS reduction, passkey activation, and takeover attempts as one operational set so you can see whether adoption is creating hidden risk.

Key takeaways

• Passkey adoption is already mainstream, but production success depends on the surrounding authentication lifecycle, not the credential alone.
• Recovery is the critical assurance boundary, because any weaker fallback can undermine a phishing-resistant front door.
• IAM teams should govern enrollment, orchestration, and step-up as one system if they want passkeys to scale without hidden risk.

Key terms

• Passkey Orchestration: The policy layer that coordinates enrollment, recovery, step-up, and support decisions around passkeys. In practice, it keeps authentication behaviour consistent across channels, devices, and risk states instead of scattering logic across the app, the identity provider, and the helpdesk.
• Recovery Downgrade Path: A fallback route that lets a user regain access with weaker assurance than the original authentication method. In passkey programmes, this is the most common place where phishing resistance is lost, because attackers target the easiest recovery channel rather than the strongest credential.
• Risk-Based Step-Up: A context-aware re-authentication pattern that asks for stronger verification only when an action or session looks risky. It preserves usability for routine activity while forcing fresh assurance for sensitive actions, unusual device signals, or suspicious behaviour.

What's in the full article

Authsignal's full article covers the operational detail this post intentionally leaves for the source:

• Rule-driven passkey uplift timing and prompt suppression logic for real deployment scenarios
• Recovery design patterns that avoid password-style fallback while preserving support operability
• No-code step-up rules, backtesting, and policy composition details for contextual authentication
• Architecture examples showing how orchestration sits alongside existing identity providers

👉 Authsignal's full post covers the rollout mechanics, recovery design, and orchestration choices behind production passkey deployment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.