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.
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.
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:
- 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.
- 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.
- 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.
- 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.
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.
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.
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.