Skip to content

Chapter 7 of 716 min readBy Deepak GuptaUpdated

The Future of Passwordless and Passkeys

Predicting the future of technology is a reliable way to look foolish. The archives are littered with confident declarations about videophones replacing email, blockchain replacing banks, and virtual reality replacing offices. So let me be clear about what this chapter is and is not. It is not speculation. It is an evidence-based assessment of where passwordless authentication is heading, grounded in published standards, shipping code, and observable adoption curves. The trends covered here are not "might happen" scenarios. They are already in motion, and the only question is how quickly your organization adapts.

If you have followed the previous chapters, you have the operational knowledge to deploy passkeys today. This chapter is about what comes next: the forces that will reshape passwordless authentication over the next three to five years, and what they mean for the roadmap you are building now.

Where Passkeys Stand Today

The numbers now describe routine use, not experiments. In December 2024 the FIDO Alliance reported that more than 15 billion online accounts could use passkeys. By World Passkey Day in May 2026, it estimated 5 billion passkeys in use worldwide, and by October 2026 that estimate had reached 7 billion. Every major browser (Chrome, Safari, Firefox, Edge) supports WebAuthn natively, and every major operating system can create and manage passkeys.

Metric Current state (November 2026) Source
Online accounts that can use passkeys More than 15 billion (December 2024) FIDO Alliance
Passkeys in use worldwide About 7 billion (October 2026 estimate, up from 5 billion in May) FIDO Alliance
Share of successful sign-ins using a passkey, 15 large consumer services 36% FIDO Passkey Index
Organizations that have deployed or are deploying workforce passkeys 68% FIDO Alliance, State of Passkeys 2026
Operating systems with passkey support iOS 16+, Android 9+, Windows 10 and 11, macOS Ventura+ Platform documentation

These are not pilot numbers. This is mainstream infrastructure. The question has shifted from "can we deploy passkeys?" to "how fast can we migrate?"

Adoption is still uneven. Consumer deployments have outpaced workforce rollouts, partly because consumer flows are simpler and partly because enterprises carry legacy systems that consumer apps do not. In FIDO's 2026 survey of 1,400 enterprise decision-makers, 68% said they had deployed or were actively deploying passkeys for employee sign-in. The rest have not started, and that window is narrowing, as the end of this chapter explains.

The Passkey Index also shows where the next gains come from. Across participants, 38% of all accounts had a passkey, while 36% of sign-ins used one. Eight of the ten participants that report both figures still see fewer passkey sign-ins than enrolled users. Two said their flow shows a password or OTP before offering the passkey, and one estimated that offering the passkey first would roughly double its passkey sign-in share. Making the passkey the default path is the cheapest adoption win available.

Note

If your organization has not started, you are not too late, but you are behind. The enterprises deploying now are building institutional knowledge and working through edge cases that will take you just as long. Starting in 2027 means competing for the same implementation talent and vendor attention as everyone else who waited.

The Post-Quantum Challenge

This is the section that matters most for long-term planning, and the one most organizations are not thinking about yet.

Current passkey implementations rely on elliptic curve cryptography (ECC), specifically the ECDSA algorithm with the P-256 curve. This cryptography is rock-solid against classical computers. Breaking a 256-bit elliptic curve key by brute force is far beyond any classical computer.

Quantum computers change that equation entirely.

Shor's algorithm, running on a sufficiently powerful quantum computer, can break ECC in polynomial time. The "sufficiently powerful" qualifier is doing a lot of work in that sentence. Current quantum computers are nowhere near the required scale. But the trajectory is clear, and the cryptographic community is not waiting for the threat to arrive before preparing the response.

What Is at Risk

Every passkey created today uses cryptographic algorithms that a future quantum computer could theoretically break. This does not mean your passkeys are insecure today. It means that organizations handling data with long-term sensitivity, such as government agencies, healthcare systems and financial institutions, need to plan for a transition to quantum-resistant algorithms before large-scale quantum computers exist. The "harvest now, decrypt later" model means adversaries may already be recording encrypted traffic to decrypt in the future. Signatures are a smaller worry here, because a forged signature only matters while the key is still trusted, but key exchange is exposed today.

NIST Post-Quantum Standards

The National Institute of Standards and Technology (NIST) finalized its first post-quantum standards in August 2024, after an evaluation that began in 2016:

  • ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), formerly CRYSTALS-Kyber. This replaces traditional key exchange mechanisms. It is the primary standard for establishing shared secrets over insecure channels.
  • ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly CRYSTALS-Dilithium. This is the primary replacement for digital signature algorithms like ECDSA, which passkeys currently use.
  • SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), formerly SPHINCS+. A backup signature standard based on different mathematical assumptions, providing algorithm diversity in case lattice-based approaches are found to have vulnerabilities.
Warning

The transition is not optional for organizations subject to federal requirements. NIST's draft transition plan, NIST IR 8547, proposes deprecating today's quantum-vulnerable public-key algorithms by 2030 and disallowing them by 2035. The NSA's CNSA 2.0 guidance targets 2035 for national security systems, with some categories, such as web browsers, servers and cloud services, expected to switch by 2033. Your compliance timeline may be shorter than you think.

Timeline for Quantum-Resistant Passkeys

Post-quantum passkeys are not standardized yet. The timeline below is my estimate, not a published FIDO roadmap:

Phase Expected Timeframe What Happens
Specification development 2026-2028 FIDO Alliance integrates ML-DSA into WebAuthn and CTAP specifications
Browser and OS implementation 2027-2028 Platform vendors ship post-quantum passkey support
Ecosystem readiness 2028-2030 Relying parties, authenticators, and identity providers support PQ passkeys
Migration period 2028-2035 Organizations transition existing passkeys to quantum-resistant versions

ML-DSA keys and signatures are much larger than ECDSA's. At the smallest parameter set, ML-DSA-44, a signature is 2,420 bytes and a public key 1,312 bytes, per FIPS 204. An ECDSA P-256 signature is 64 bytes, with a public key of similar size. This has real implications for storage, bandwidth, and performance that the ecosystem needs to absorb. It is an engineering challenge, not a theoretical obstacle.

What Enterprises Should Do Now

You do not need to wait for post-quantum passkeys to ship before taking action. The preparation work starts today:

  1. Inventory your cryptographic dependencies. Know where ECDSA and other vulnerable algorithms are used: not just in authentication, but across TLS, code signing, document signing and API security.
  2. Adopt crypto-agility as an architectural principle. Your systems should be able to swap cryptographic algorithms without redesigning the entire authentication flow. If your passkey implementation is tightly coupled to P-256, you will have a painful migration.
  3. Monitor FIDO Alliance and W3C working groups. The specifications are being developed in the open. Track the progress so you can plan implementation timelines accurately.
  4. Start hybrid deployments where possible. Some protocols already support hybrid classical and post-quantum key exchange. TLS 1.3 with hybrid ML-KEM key exchange is already on by default in current versions of Chrome and other major browsers.

For a comprehensive treatment of post-quantum migration planning, see the Enterprise Post-Quantum Migration Guide.

AI and Authentication Convergence

Artificial intelligence is reshaping authentication from both sides. It strengthens defenses and creates new attack surfaces. Understanding both directions is critical for roadmap planning.

AI-Powered Behavioral Biometrics

Chapter 3 covered behavioral biometrics as an adaptive authentication signal. That technology is evolving quickly, and in my view it is becoming a standard component of enterprise authentication stacks rather than an experiment.

Modern behavioral biometric systems analyze hundreds of signals continuously: typing cadence, mouse movement patterns, touchscreen pressure, device orientation, application usage patterns, and navigation habits. Machine learning models build a behavioral profile for each user and flag anomalies in real time, throughout the session rather than only at login.

The value is that it covers a gap passkeys leave open. An attacker who steals an unlocked device may get past the passkey, but they do not have the owner's behavioral profile. Ask vendors for measured results from deployments like yours rather than headline percentages.

Tip

When evaluating authentication vendors, ask specifically about their behavioral biometrics capabilities. This is becoming a differentiator. A vendor that treats authentication as a point-in-time event is building for 2022, not 2028.

AI Agent Authentication: A New Problem

Here is a challenge that almost no enterprise has solved: how do you authenticate an AI agent?

AI agents, autonomous software that acts on behalf of users or organizations, are spreading across enterprise environments. They schedule meetings, process invoices, write code, manage infrastructure, and interact with external services. Each of these actions may require authentication, and the traditional model of "a human proves they are who they say they are" does not apply.

AI agents need identity. They need to authenticate to services, prove authorization for specific actions, and maintain audit trails. But they cannot use biometrics, they cannot respond to push notifications, and binding them to hardware authenticators creates operational fragility.

The industry is converging on several approaches:

  • Delegated identity models where an agent inherits scoped permissions from a human principal, with cryptographic proof of the delegation chain
  • Machine identity certificates with short-lived credentials and automatic rotation
  • OAuth 2.0 extensions for non-human actors, including token binding and proof-of-possession mechanisms

This is an area to watch closely. If your organization is deploying AI agents, and most enterprises are, agent authentication needs to be on your roadmap now. Otherwise each team will invent its own approach with shared API keys and long-lived tokens. The Agent Security Map on this site tracks the vendors working on agent identity.

Continuous Authentication Replacing Point-in-Time Checks

The convergence of AI and authentication is accelerating the shift from discrete login events to continuous trust evaluation. Instead of authenticating once and trusting the session for hours, modern systems continuously verify that the authenticated user is still the one using the session.

This model, sometimes called "zero trust authentication," combines passkey-based initial authentication with ongoing behavioral signals, device health checks, and contextual risk analysis. If the trust score drops below a threshold mid-session, the system can step up authentication, limit access to sensitive resources, or terminate the session entirely.

The practical result is that the "login" becomes almost invisible. Users authenticate with a passkey once, and the system maintains trust silently as long as behavior patterns remain consistent. Security improves, and friction decreases. That is not a common combination in security, which is what makes it worth pursuing.

Device-Bound vs. Synced Passkeys: The Evolving Trade-Off

When passkeys first launched, the security community debated synced passkeys, which synchronize across devices through services like iCloud Keychain or Google Password Manager. Purists argued that only device-bound passkeys (which never leave the hardware where they were created) provided true security, because synced passkeys introduced a cloud provider as a trusted third party.

That debate has matured, and NIST's SP 800-63B-4 settled the assurance question: synced passkeys can serve up to AAL2, while AAL3 needs non-exportable keys. The working consensus looks like this:

Attribute Synced Passkeys Device-Bound Passkeys
Security level (NIST) AAL2 AAL3
Recovery if device lost Automatic via cloud sync Requires backup registration
Suitable for Most enterprise use cases, consumer apps High-security environments, regulated industries
User experience Works across the user's devices Per-device enrollment required
Third-party trust Cloud provider manages key sync No third-party dependency
Recommended for Most enterprise scenarios Privileged access, financial systems, classified environments

The trajectory is toward hybrid policies: synced passkeys as the default for most users and applications, with device-bound passkeys required for elevated-privilege scenarios. Identity providers are making this easier with policy controls, such as attestation and authentication-strength rules, that require device-bound passkeys for specific apps or groups.

Tip

Do not let the perfect be the enemy of the good. If you are debating synced vs. device-bound passkeys and it is delaying your deployment, start with synced passkeys for the general workforce. You can layer device-bound requirements for high-security use cases in a subsequent phase. A synced passkey deployed today is infinitely more secure than a password you planned to replace "eventually."

Platform Passkey Support Roadmap

The three major platform vendors, Apple, Google and Microsoft, are expanding their passkey infrastructure on different timelines but toward the same capabilities.

Apple has made passkeys a core part of the Apple ecosystem since iOS 16 and macOS Ventura. iCloud Keychain synchronization works across all Apple devices signed into the same Apple Account. With iOS 26 and macOS 26, Apple added passkey export and import through the FIDO Alliance's Credential Exchange Protocol. Expect deeper enterprise administration controls through 2027.

Google has integrated passkeys into Google Password Manager with synchronization across Android devices and Chrome browsers. Google's approach emphasizes interoperability; its implementation was among the first to support cross-device sign-in with QR codes and Bluetooth proximity. Google is also driving passkey adoption in enterprise through Google Workspace admin controls and Android Enterprise management APIs. Android runs on most of the world's smartphones, per StatCounter, so Google's implementation decisions matter most for reach.

Microsoft has built toward passwordless for years through Windows Hello. In 2025 it added passkey syncing through Microsoft Password Manager in Edge on Windows 10 and 11. In 2026 it made passkeys the default in Entra ID: users enabled for SMS or voice were auto-enabled for passkeys on September 1, 2026, and Microsoft-provided SMS and voice MFA retires for most users on February 1, 2027. Conditional Access can require phishing-resistant methods per app and group. For organizations invested in the Microsoft ecosystem, that native integration reduces deployment friction significantly.

The convergence point is portability: moving passkeys between providers without re-enrollment. The FIDO Alliance's Credential Exchange Protocol (CXP), first published as a draft in late 2024, addresses it. Apple shipped CXP-based import and export in iOS 26 in September 2025, and password managers such as Bitwarden support it. Expect remaining platforms to follow.

Enterprise Adoption Curve: Where We Are Now

Mapped against a standard technology adoption curve, my reading is that enterprises are in the "early majority" phase as of 2026. The innovators deployed between 2020 and 2022. Early adopters ran serious pilots in 2023-2024. The early majority began production deployments in 2025, and that wave is accelerating.

Adoption Phase Timeline Characteristics
Innovators 2020-2022 Security-focused tech companies, FIDO Alliance members
Early Adopters 2023-2024 Large enterprises with dedicated identity teams, financial services
Early Majority 2025-2026 Fortune 500 companies, regulated industries, government agencies
Late Majority 2027-2028 Mid-market enterprises, organizations with complex legacy environments
Laggards 2029+ Organizations with extreme legacy constraints or no regulatory pressure

The pattern in earlier authentication transitions, from passwords to MFA and from on-premises to cloud identity, is that the late majority pays the highest price. They compete for the same implementation resources as everyone else, but with less institutional knowledge, fewer vendor concessions, and tighter timelines driven by compliance deadlines that early movers had years to prepare for.

For a detailed deployment framework, including phased rollout strategies and legacy system integration patterns, see the Enterprise Passkey Deployment Playbook.

What This Means for Your Roadmap

Let me close with three actionable directives that should inform your authentication strategy today.

Build for Passkeys-First Today

If your current roadmap still treats passkeys as an "alternative login method" alongside passwords, flip that framing. Passkeys should be the primary authentication method, with passwords as the legacy fallback that you are actively working to eliminate. Every new application should launch with passkeys as the default. Every existing application should be on a migration timeline.

The infrastructure is ready. The standards are mature. The user experience is demonstrably better. The security improvement is measurable. There is no technical reason to wait.

Plan for Post-Quantum Migration

You do not need to deploy post-quantum passkeys today; they are not standardized yet. But you do need to ensure your architecture can accommodate them when they arrive. That means:

  • Abstracting cryptographic operations behind interfaces that can be swapped
  • Avoiding hard dependencies on specific key sizes or algorithm parameters
  • Building credential management systems that can handle larger keys and signatures
  • Including post-quantum migration in your 3-5 year technology roadmap

The organizations that will have the smoothest transition are the ones designing for crypto-agility now, not the ones who will need to retrofit it under deadline pressure in 2029.

The Migration Window Is Narrowing

Every month that passes, the gap between organizations that have deployed passkeys and those that have not grows wider. The early movers are refining their implementations, collecting data on user adoption patterns, training their helpdesk teams, and integrating passkeys deeper into their application ecosystems. They are building competitive advantages in security posture, user experience, and operational cost.

Meanwhile, the threat landscape continues to evolve. Phishing attacks are becoming more sophisticated, credential marketplaces are growing, and AI-powered attacks are lowering the barrier for adversaries. Passwords are not getting safer with time. They are getting more dangerous.

Warning

The cost of deploying passkeys today is an investment. The cost of deploying passkeys in 2028, after a credential breach that could have been prevented, is a remediation expense. The technology is identical. The business context is entirely different.

The future of passwordless authentication is not a mystery. The standards are published. The platforms are ready. The cryptographic evolution is mapped out. The adoption curve is well understood. What remains is execution, and that part is entirely within your control.