Notifications
Clear all
Topic starter
10/07/2026 9:18 pm
TL;DR: Passkey adoption is already mainstream, with 87% of enterprises deploying or having deployed it, Google reporting 2.5 billion sign-ins across 800 million accounts, and NIST classifying syncable passkeys as AAL2-compliant, according to Authsignal. The hard part is not support, but operating enrollment, recovery, step-up, fraud detection, and orchestration as one authentication system.
NHIMG editorial — based on content published by Authsignal: World passkey day: How to deliver passkeys at scale in 2026
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Define passkey enrollment as a policy workflow Trigger enrollment at specific moments such as post-login, first registration, or controlled uplift points.
- 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.
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
👉 Read Authsignal's analysis of how to deliver passkeys at scale in 2026 →
Passkey rollout at scale in 2026: what breaks in production?
Explore further
10/07/2026 9:41 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: World passkey day shows passkey scale still depends on orchestration
