TL;DR: Passkeys now account for 62% of one million 2025 authentication challenges, with autofill at 65%, according to Authsignal, while the FIDO Alliance reports more than 1 billion people have activated at least one passkey and consumer awareness rose from 39% to 57%. The governance issue is no longer readiness but rollout design: adoption is happening faster than many IAM programmes have adjusted.
At a glance
What this is: This is an analysis of passkey adoption at enterprise scale, showing that passkeys have crossed from pilot to mainstream use and are now the dominant authentication method in the sample data.
Why it matters: It matters because IAM teams responsible for human authentication, account recovery, and migration away from passwords need to plan for passkeys as a live operating model, not a future option.
By the numbers:
- In a sample of one million transactions in 2025, passkeys accounted for 62% of all authentication challenges.
- Consumer awareness of passkeys jumped from 39% to 57% in just two years, according to the FIDO Alliance.
- Over 95% of iOS and Android devices are passkey-ready, according to Authsignal.
👉 Read Authsignal's analysis of what millions of passkey transactions reveal
Context
Passkeys are a human identity control that replaces password-based sign-in with cryptographic authentication tied to a device or platform authenticator. The core problem this article addresses is whether the enterprise authentication stack, user experience, and rollout strategy are keeping pace with adoption that is now visibly moving into the mainstream.
That matters because passkey programmes do not succeed or fail on cryptography alone. They succeed when IAM teams align enrollment timing, recovery flows, support operations, and policy decisions across web and mobile channels, with phishing-resistant authentication as the target state rather than a side project.
Key questions
Q: How should organisations roll out passkeys without creating new fallback risk?
A: Start with platform readiness, then govern every fallback path as part of the authentication control. If SMS, email OTP, or manual resets remain available, they must be risk-rated, monitored, and limited so they do not become a permanent weaker alternative to passkeys.
Q: When do passkeys deliver the most value in an IAM programme?
A: Passkeys deliver the most value when an organisation wants to reduce phishing exposure and password dependence across a large user base. They are most effective when enrollment, support, and recovery are already aligned, because weak exception handling can erase much of the security gain.
Q: What do IAM teams get wrong about passkey adoption?
A: Teams often assume adoption is mainly a user-education problem, but the article shows readiness, platform support, and rollout design matter just as much. If the journey is fragmented across devices or channels, users may accept the feature and still fall back to weaker sign-in methods.
Q: How do passkeys compare with password-based multifactor sign-in for risk reduction?
A: Passkeys reduce reliance on shared secrets and are resistant to common phishing paths that undermine passwords and OTP-based flows. The practical difference is that passkeys move the primary verification step to a cryptographic authenticator, which is harder to replay or intercept.
Technical breakdown
Why passkeys change human authentication economics
Passkeys replace shared knowledge secrets with asymmetric cryptographic credentials bound to an authenticator, which removes the password as the primary attack surface for phishing and replay. In practice, the user proves possession and device presence, while the relying party validates the cryptographic response rather than a memorised secret. That shifts authentication from something users remember to something their platform attests. The deployment challenge is not the protocol itself but how the organisation handles enrollment, fallback, and recovery without recreating password-era risk through weaker backup paths.
Practical implication: treat passkeys as a primary authentication control and map every fallback path to the same assurance level.
Device readiness and the rollout constraint
The article’s device-readiness claim points to a common misconception in identity programmes: teams assume adoption depends mainly on user willingness, when the real blocker is often whether the environment already supports the authenticator. For passkeys, operating system support, browser compatibility, and synced credential availability determine whether sign-in can scale without forcing exceptions. Once the platform baseline is there, the limiting factor becomes policy design and user journey consistency across channels. That makes rollout architecture, not just product selection, the decisive variable for success.
Practical implication: inventory platform support before rollout and eliminate channel-specific exceptions that fragment the experience.
Why adoption depends on timing, trust, and support design
Passkey adoption is influenced by when the option is presented, how it is explained, and what happens if the user cannot complete enrollment. The article shows that users respond to convenience and speed language more readily than cryptographic detail, which is consistent with broader identity behaviour: people adopt controls that feel understandable and low-friction. For security teams, that means communication, help desk scripting, and recovery design are part of the control plane, not just change-management extras. If support paths are clumsy, users return to less secure channels even when passkeys are available.
Practical implication: design the enrollment and recovery journey as an identity control, not a communications afterthought.
NHI Mgmt Group analysis
Passkeys are now a mainstream human identity control, not an experimental add-on. When a sample of one million transactions shows 62% passkey usage, the question changes from whether users will adopt the method to whether the organisation can govern it consistently across accounts, devices, and fallback paths. The practical conclusion is that password migration programmes now need passkey operating models, not pilots.
The real implementation challenge is no longer cryptographic readiness, but governance of recovery and exception handling. The article’s device-readiness data shows the ecosystem is broadly prepared, which means residual risk concentrates in alternate sign-in paths, support overrides, and partial rollouts. In IAM terms, the weakest link becomes the path that reintroduces password-era assumptions after the primary authenticator has been replaced. Practitioners should treat those exceptions as first-class policy objects.
Human authentication success depends on how the control is introduced, not just how strong it is. Users adopt controls they understand, and adoption rises when passkeys are framed around convenience, speed, and reduced friction rather than abstract security claims. That places IAM, UX, and service desk ownership in the same governance conversation. The implication is clear: passkey success is a programme design problem, not a feature toggle.
Passkey scale will expose identity programmes that still depend on password-shaped fallback logic. Once a majority of sign-ins move to phishing-resistant authentication, the programme starts to fail at the boundaries where users are forced back into SMS, email OTP, or manual reset workflows. That creates an identity inconsistency, not just a usability issue. Practitioners should assume the edge cases will define the control’s real security posture.
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 behaviour gap that persists even where governance exists.
- For a broader identity lens, Ultimate Guide to NHIs - The NHI Market is the right place to map how identity programmes expand beyond human sign-in.
What this signals
Passkey adoption is becoming a baseline expectation for human IAM, which means teams should stop treating passwordless as a niche modernisation stream and start treating it as an authentication operating model. The real work is no longer proving the technology can function, but removing the organisational friction that blocks consistent use across web, mobile, and support channels.
Passwordless recovery debt: as passkeys scale, the hidden risk moves into recovery, exception handling, and manual reset processes that were designed for passwords. If those paths remain weak, the organisation has only replaced the primary credential while leaving the escape hatches intact.
The policy question is now whether the organisation can make phishing-resistant authentication the default without creating a support burden that sends users back to weaker methods. That requires explicit ownership across IAM, service desk, and application teams, plus measurement of abandonment, fallback use, and enrollment success.
For practitioners
- Inventory passkey readiness across devices and browsers Confirm which endpoints already support platform authenticators, synced passkeys, and conditional enrollment. Remove channel gaps between mobile and web before expanding to broader populations.
- Redesign recovery and fallback flows Map every backup path that can bypass passkey assurance, including help desk resets, SMS OTP, and email-based recovery. Align those paths with policy so they do not become a weaker parallel authentication system.
- Roll out passkeys in high-value segments first Prioritise users with frequent authentication activity or access to sensitive data, then use adoption and support metrics from those groups to refine the broader rollout. The article’s timing lesson suggests early champions matter.
- Update support scripts and user education Train service desk teams to explain passkeys in simple language focused on speed, convenience, and recovery steps. Clear messaging and consistent support reduce abandonment and prevent users reverting to weaker methods.
Key takeaways
- Passkeys have crossed into mainstream human authentication, which makes rollout governance more important than pilot enthusiasm.
- The biggest risk is not passkey cryptography itself but the fallback paths, recovery flows, and support overrides that can reintroduce weaker authentication.
- IAM teams should focus on readiness, user journey design, and service desk alignment if they want passkey adoption to hold at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B | Passkeys are phishing-resistant authenticators governed by digital identity guidance. |
| NIST Zero Trust (SP 800-207) | Passkeys support continuous verification in zero trust identity flows. | |
| NIST CSF 2.0 | PR.AC-7 | Authentication and access verification are central to this human identity change. |
| NIST SP 800-53 Rev 5 | IA-2 | Identification and authentication controls directly apply to passwordless sign-in. |
Treat passkey adoption as an access control change and measure fallback usage and recovery exposure.
Key terms
- Passkey: A passkey is a phishing-resistant credential used for human sign-in, based on public-key cryptography rather than a shared password. The authenticator typically lives on a device or platform service and confirms possession and user presence before releasing a signed assertion to the relying party.
- Phishing-Resistant Authentication: Phishing-resistant authentication is a sign-in method that cannot be easily captured and replayed by an attacker through a fake login page or intercepted one-time code. It matters because it shifts identity assurance away from secrets that users type and toward cryptographic proof bound to the real authenticator.
- Authentication Fallback Path: An authentication fallback path is any alternate method that lets a user regain access when the primary method fails. In passkey programmes, fallback paths can become the real security weak point if they are easier to abuse, less monitored, or governed at a lower assurance level than the primary authenticator.
What's in the full article
Authsignal's full blog covers the operational detail this post intentionally leaves for the source:
- Observed enrollment patterns across enterprise customers, including the timing and prompt styles that improved adoption.
- Operational examples of how passkeys were rolled out across mobile and web channels without fragmenting the user journey.
- Support and call centre effects after passkey deployment, including reduced password-reset demand.
- Practical messaging lessons on how to explain passkeys to users in ways that improve opt-in rates.
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.
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org