TL;DR: Passkeys reached mainstream adoption in 2025, with nearly 70% of users holding at least one passkey, while regulators in the UAE, India, the Philippines, and the US moved away from SMS OTP and toward phishing-resistant authentication, according to Authsignal. Passwordless is no longer a pilot topic; it is becoming the baseline for identity programmes that need to survive fraud pressure and compliance deadlines.
At a glance
What this is: This is an Authsignal analysis of how passkeys became mainstream in 2025 as governments and standards bodies pushed organisations away from SMS OTP and toward phishing-resistant authentication.
Why it matters: It matters because IAM teams now have to treat passwordless and phishing-resistant MFA as a governance baseline for human identity, not a future-state experiment.
By the numbers:
- Nearly 70% of users would have at least one passkey by the end of 2025, according to Authsignal.
- Passkeys reached a 93% login success rate compared to 63% for traditional authentication methods, according to Authsignal.
- The passwordless authentication market reached $24.1 billion in 2025 and is projected to grow to $55.7 billion by 2030, according to Authsignal.
Context
Passkeys are phishing-resistant, passwordless authenticators that bind a login to a device and cryptographic key pair rather than a shared secret. The governance question in 2025 is no longer whether the technology works, but whether identity programmes can retire SMS OTP, step up to stronger authenticators, and still keep user friction under control.
Authsignal's article frames 2025 as the year regulation, platform support, and consumer adoption finally moved in the same direction. For IAM and MFA teams, that convergence matters because the authentication baseline is shifting from optional hardening to policy-backed expectation, especially in financial services and other regulated environments.
The article is strongest when it connects adoption pressure to operational reality: migration paths, not just technology preference, now determine whether organisations can meet deadlines and reduce account takeover risk.
Key questions
Q: What should IAM teams do first when OTP and SMS MFA are still in use?
A: Start by moving privileged users, administrators and anyone who can reset access into phishing-resistant MFA first. That sequence reduces the highest-impact takeover paths before broader rollout begins, and it creates a real operational example for user support, recovery and device provisioning across the rest of the programme.
Q: Why do SMS OTPs create higher fraud and recovery risk than device-bound authentication?
A: SMS OTPs only prove control of a phone number, and that signal is easier to spoof, intercept, or divert than a cryptographic credential tied to a device. They also depend on telecom and third-party infrastructure, which expands the attack surface and complicates accountability when fraud occurs. Device-bound authentication keeps credentials local and is harder to redirect.
Q: How can IAM teams tell whether passkey adoption is actually working?
A: Look for lower password-reset volume, shorter login times, reduced phishing-related incidents, and a declining share of applications that still require phishable methods. A healthy programme also shows stable recovery outcomes when devices are lost or replaced. If those signals do not move together, adoption is cosmetic rather than architectural.
Q: Should organisations treat phishing-resistant MFA as a compliance issue or an architecture issue?
A: Both, but the architecture comes first. Regulations and standards are now pushing toward phishing-resistant authentication, yet the control only works when enrollment, recovery, device trust, and exception handling are designed together. If those pieces are separate, compliance will be fragile and user friction will rise.
Technical breakdown
Why SMS OTP became a weak second factor
SMS OTP depends on a channel that can be intercepted, relayed, or socially engineered, so it never created a strong possession signal on its own. In practice, the code often proves only that a message reached a number, not that the right person or device approved the transaction. That is why regulators increasingly treat SMS and email OTP as insufficient for high-risk authentication. Once attackers can phish, SIM-swap, or redirect the code, the factor becomes vulnerable by design rather than by implementation error.
Practical implication: retire SMS OTP from high-risk journeys and treat it as a legacy compatibility path only where regulation still allows it.
How passkeys change phishing-resistant authentication
Passkeys use public-key cryptography, with the private key stored on the user's device or in a synced credential manager and the server holding only the public counterpart. Because the credential is origin-bound and non-exportable in stronger forms, the secret is not reusable in the way passwords and one-time codes are. That makes phishing far harder, and it is why NIST's SP 800-63-4 now requires phishing-resistant options at AAL2 and non-exportable private keys for AAL3. Synced passkeys also matter because they reduce adoption friction without abandoning the cryptographic model.
Practical implication: prioritise phishing-resistant authenticators for any user population that handles money, privileged actions, or regulated data.
Why migration, not capability, is the real bottleneck
The article shows that the blocker was never only authentication strength. It was the gap between existing user populations and the operational effort needed to move them without breaking login journeys, account recovery, or support workflows. Apple's passkey APIs, signal updates, and automatic upgrades matter because they reduce lifecycle friction after initial enrollment. That is the real lesson for identity teams: adoption rises when enrollment, recovery, and manager updates are designed as one governed flow rather than separate projects.
Practical implication: map the full passkey lifecycle, including enrolment, recovery, revocation, and migration from password-based accounts.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SMS OTP is now a governance liability, not merely a weaker factor. The article shows that regulators are no longer treating text-message codes as an acceptable control for high-risk authentication. That matters because many identity programmes still use SMS as a fallback that feels convenient but creates a shared-secret style failure mode. Practitioners should read this as a signal to reclassify SMS OTP from default MFA to legacy exception handling.
Passkeys are becoming the practical bridge between fraud reduction and user experience. Authsignal's numbers point to adoption at scale, but the deeper issue is control durability: passkeys reduce phishing exposure without making every login a support event. That is why they are increasingly the control that can satisfy both security teams and product owners. The practitioner conclusion is that passwordless is no longer a UX luxury; it is the control model that can survive real-world fraud pressure.
Phishing-resistant authentication is moving from best practice to baseline expectation. NIST SP 800-63-4 now requires a phishing-resistant option at AAL2 and non-exportable keys at AAL3, which changes the bar for regulated environments. That does not just raise the floor for authentication strength. It also narrows the acceptable design space for MFA programmes that still rely on interceptable channels. Teams should assume the policy window is closing, not opening.
Passkey adoption exposes a new lifecycle governance problem: migration without account friction. The hardest part is no longer proving cryptographic superiority. It is governing the transition path from passwords and OTPs to passkeys across enrolment, recovery, device changes, and credential manager updates. This is a lifecycle problem, not a feature problem, and identity leaders need to treat it that way.
Identity programmes that delay passwordless will carry compounding exception debt. The more exceptions an organisation preserves for SMS OTP, the more support, fraud, and policy inconsistency it inherits later. That creates a split estate where risk-based authentication is only partially true. Practitioners should expect the cost of delay to rise as regulators, platforms, and user expectations converge on phishing-resistant MFA.
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
Phishing-resistant MFA is becoming the default design target for regulated identity programmes. Teams should assume that SMS OTP will increasingly be treated as a compatibility layer rather than a strategic control. The practical shift is from factor diversity to factor resistance, with recovery and exception handling carrying more governance weight than before.
Passwordless adoption now depends on lifecycle governance as much as on cryptography. The control succeeds when enrolment, migration, account recovery, and device change events are managed as one policy surface. IAM teams that keep those events fragmented will preserve friction even if the underlying authenticator is strong.
For practitioners
- Retire SMS OTP from high-risk journeys Remove text-message and email codes from flows that protect payments, account recovery, and privileged access. Keep them only where no stronger alternative is yet feasible, and track every exception as a temporary governance decision.
- Prioritise phishing-resistant MFA for regulated users Move customers, staff, and administrators who handle financial transactions or sensitive actions onto passkeys or other phishing-resistant authenticators first. Use risk-based step-up only where the journey still requires layered controls.
- Design passkey lifecycle governance end to end Treat enrolment, recovery, revocation, account changes, and credential-manager updates as one lifecycle, not separate projects. The article's migration examples show that adoption fails when lifecycle events are not synchronised.
- Document exception handling before compliance deadlines List every market, product line, and user population still dependent on OTP, then map each one to a dated removal plan. This is especially important where regulators have already signalled a shift away from shared-code authentication.
Key takeaways
- Passkeys moved from early-adopter status to mainstream authentication in 2025, and the article shows that this shift is being reinforced by both regulators and platform changes.
- The central governance problem is no longer whether passwordless works, but how quickly organisations can replace SMS OTP without breaking account recovery and user journeys.
- IAM and MFA teams should treat phishing-resistant authentication as the new baseline for high-risk access, then manage exceptions as temporary and explicitly owned.
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 CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | The article centres on phishing-resistant authentication and MFA policy. |
| Recommendation — Adopt phishing-resistant authenticators for high-risk journeys and phase out SMS OTP where stronger options exist. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authentication controls in the article directly affect access assurance. |
| Recommendation — Align authentication methods to access risk and remove shared-code factors from sensitive workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is about controlling how users authenticate and transition between methods. |
| Recommendation — Govern account authentication methods and exceptions as part of account lifecycle management. | ||
| OWASP ASVS | V6 — Authentication | Passkeys and OTP replacement are core authentication-verification concerns. |
| Recommendation — Verify that sensitive journeys use phishing-resistant authentication instead of interceptable one-time codes. | ||
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.
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Sms Otp: A one-time password delivered by text message and used as a possession-style second factor. It is widely deployed but increasingly treated as weak for high-risk access because the delivery channel can be intercepted, redirected or replayed outside the bank’s control.
- 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.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org