Passkeys Crossed the Tipping Point — Passwords Are Losing

For years, the passwordless future was a PowerPoint slide — promising, perpetually "coming soon," and never quite arriving. That changed. By mid-2026, passkeys have crossed the line from experimental feature to default authentication for hundreds of millions of accounts. Google, Apple, Microsoft, Amazon, GitHub, Shopify, PayPal, and WhatsApp have all either defaulted to passkeys or made them the primary recommended credential. The transition is not theoretical anymore. It is happening, and the security data backing it is striking.

What Passkeys Actually Are

Passkeys are an implementation of the FIDO2/WebAuthn standard, a specification jointly developed by the FIDO Alliance and the W3C. At their core, passkeys use asymmetric public-key cryptography: when you register a passkey with a service, your device generates a keypair. The private key never leaves your device (or your synced keychain). The service stores only the public key. When you authenticate, the service sends a cryptographic challenge; your device signs it with the private key; the server verifies the signature with the stored public key.

No password is transmitted. No shared secret exists on the server to steal. A database breach that leaks every stored credential leaks only public keys — worthless to an attacker without the corresponding private keys that remain on users' devices.

Device-Bound vs. Synced Passkeys

There are two fundamentally different deployment models, and the distinction matters for both security and usability:

• Device-bound passkeys (also called hardware-bound or non-discoverable credentials) are stored in a hardware security module — a TPM chip on Windows, the Secure Enclave on Apple silicon, or a FIDO2 hardware key like a YubiKey. The private key is physically non-exportable. If the device is lost, the passkey is gone. This is the highest-security model and is appropriate for enterprise, high-value accounts, and security-conscious individuals willing to manage backup keys.
• Synced passkeys are stored in a cloud-backed keychain — Apple's iCloud Keychain, Google Password Manager, or a third-party manager like 1Password or Bitwarden. The private key material is encrypted, synced across your devices, and can survive device loss. This sacrifices a narrow hardware-attestation guarantee in exchange for dramatically better usability and recovery. For the vast majority of consumer use cases, synced passkeys represent an enormous security improvement over passwords with essentially no meaningful real-world downside.

The FIDO Alliance's 2023 specification update formally standardized synced passkeys after recognizing that hardware-only passkeys created an adoption barrier that kept users on passwords — the worst outcome for overall security.

The Authentication Flow, Step by Step

Understanding what happens under the hood during a WebAuthn authentication helps clarify why phishing attacks fail against passkeys:

• Registration: The browser calls navigator.credentials.create() with a challenge from the server. The authenticator (device, platform, or hardware key) generates a keypair scoped to the exact relying party ID (the domain). The public key and a credential ID are sent to the server and stored.
• Authentication: The server issues a fresh random challenge. The browser calls navigator.credentials.get(). The authenticator checks that the origin and relying party ID match exactly — a passkey registered for google.com will refuse to sign a challenge from g00gle.com. After biometric or PIN verification, the private key signs the challenge. The server verifies the signature.
• The phishing barrier: Because the passkey is bound to the exact origin at registration time, a phishing site cannot intercept or replay credentials. Even if a user is tricked into visiting a lookalike site, the authenticator refuses to produce a valid signature for a different origin. This is the mechanism behind the near-zero phishing rate for passkey accounts.

Adoption Numbers: What the Data Shows

Google reported at Google I/O 2024 that over 800 million Google accounts had passkeys enabled, up from 400 million at the end of 2023. By early 2025, Google began prompting users to create passkeys during sign-in flows and started defaulting new account sign-ups to passkey-first. Internal Google data cited in their security blog showed that passkey sign-ins were completing at a rate 4x faster than password + SMS 2FA flows.

More importantly: Google's internal phishing metrics for accounts that had migrated to passkey-only authentication showed phishing compromise rates approaching zero — compared to a baseline of password accounts where even with 2FA, SIM-swap and AiTM (adversary-in-the-middle) phishing attacks continued to succeed.

Apple shipped passkey support in iOS 16 and macOS Ventura (2022) and by 2025 had made passkeys the default suggested method in Safari's credential manager. Microsoft enabled passkeys for consumer Microsoft accounts in 2023 and expanded to Entra ID (Azure AD) for enterprise in 2024. GitHub made passkeys generally available in 2023 and has seen particularly strong adoption among developer accounts — a high-value target segment where phishing resistance is critical.

Platform and Ecosystem Support

Apple: iCloud Keychain Passkeys

Apple's implementation syncs passkeys end-to-end encrypted through iCloud Keychain. Passkeys work across iPhone, iPad, Mac, and — since iOS 17 — can be shared with family members or used on non-Apple devices via QR code proximity authentication. The Secure Enclave enforces biometric verification (Face ID or Touch ID) before any signing operation. Apple also supports hardware security keys as passkey authenticators via their platform authenticator API.

Google: Password Manager Passkeys

Google Password Manager now syncs passkeys across Android and Chrome on any platform, including Windows and macOS. The sync is end-to-end encrypted with the user's Google account PIN. A significant 2024 addition: Google began supporting passkey export in some flows and added passkey support to their Advanced Protection Program — previously the exclusive domain of physical security keys.

Windows Hello

Windows Hello provides device-bound passkeys tied to the TPM chip and unlocked via face recognition, fingerprint, or PIN. Microsoft's implementation is tightly integrated with the Windows credential store. In enterprise environments, Windows Hello for Business extends this to certificate-based authentication with Entra ID, enabling passwordless flows in managed corporate environments.

Third-Party Password Managers

Both 1Password and Bitwarden added passkey storage in 2023-2024, treating passkeys as a new credential type alongside passwords. This is significant: it decouples passkey storage from platform vendors, enables cross-platform passkey use without Google or Apple lock-in, and gives enterprises a path to manage passkeys in existing vault infrastructure. Bitwarden's open-source implementation has been independently audited.

The Hard Problems That Remain

Device Loss and Account Recovery

Device loss is the most emotionally salient obstacle to passkey adoption. The correct answer — and one that requires explicit user education — is to register multiple passkeys on different devices or authenticators before you need them. Register a passkey on your phone, your laptop, and a hardware key stored somewhere safe. Most services that implement passkeys well prompt for this. But the reality is that most users register a single passkey and discover the recovery problem only when their device is gone.

For synced passkeys, iCloud Keychain and Google Password Manager both have account recovery mechanisms. If you lose your iPhone but can recover your iCloud account (via a recovery key or trusted device), you recover your passkeys. This moves the security boundary from device possession to account security — which can be a regression if your iCloud or Google account has weak security. The solution is to treat your primary cloud account as a high-security root: strong recovery key, hardware 2FA, nothing weaker.

Enterprise Rollout: Active Directory and LDAP

Enterprise environments present genuine complexity. Legacy applications that authenticate against Active Directory or LDAP do not speak WebAuthn. Bridging passkeys to these environments requires either federation through an identity provider (Entra ID, Okta, Ping Identity) that can translate WebAuthn authentication into SAML or OIDC tokens, or waiting for application modernization. Most large enterprises are in a hybrid state: passkeys for cloud-native apps and SSO portals, passwords or smart cards for legacy line-of-business apps. Full enterprise passkey rollout is a multi-year program, not a configuration switch.

Android/iOS Interoperability

Cross-platform passkey use — signing in on an iOS device with a passkey stored on an Android phone, or vice versa — works via the CTAP2 hybrid transport (Bluetooth-proximity QR code flow). In practice this works reliably when both devices are modern, Bluetooth is on, and the user understands what they are doing. It is not seamless for less technical users and adds friction in scenarios like borrowing someone's device. This is an area where the UX still lags the underlying cryptographic capability.

Legacy Devices Without Biometrics

Passkeys require some form of user verification — biometrics (fingerprint, face) or a device PIN. Devices without biometric sensors can use a PIN, but a short PIN on an old Android device is a weaker user verification than Face ID. Hardware security keys (FIDO2 keys with PIN + touch) solve this for users willing to carry one, but adoption among non-technical users is minimal.

The Developer Perspective: Implementing WebAuthn

If you are building authentication, WebAuthn implementation is now well-supported. The mature, actively maintained libraries in 2026 include:

• SimpleWebAuthn (TypeScript/Node.js) — the most widely used JS library, handles both registration and authentication, excellent documentation, handles the ceremony correctly including challenge verification and credential storage patterns.
• py_webauthn (Python) — the reference Python implementation, used in Duo Security's stack, supports both FIDO2 and the older U2F for backward compatibility.
• webauthn4j (Java) — the mature Java library used by Spring Security's WebAuthn support; handles attestation validation, metadata service integration, and works well in Spring Boot applications.
• go-webauthn/webauthn (Go) — the standard Go implementation, clean API, actively maintained.

Browser compatibility is now a non-issue for the core WebAuthn API: Chrome 67+, Firefox 60+, Safari 14+, and Edge 18+ all support it. The remaining compatibility gap is in conditional UI (autofill-driven passkey prompts), which requires slightly newer browser versions but is now widely deployed.

Key implementation mistakes to avoid: not binding the challenge to the session server-side (replay attack vector), not verifying the rpId and origin in server-side validation, skipping attestation validation in high-security contexts, and not implementing multi-device registration flows from the start.

Practical Recommendations

Enable passkeys on your highest-value accounts first, in this order of priority:

• Email provider — your email is the recovery mechanism for everything else. A compromised email account cascades to every other account. Enable passkeys on Gmail or iCloud Mail immediately.
• Password manager — if your password manager supports passkey login (1Password and Bitwarden do), enable it. This is the master key to your credential vault.
• Financial accounts — banks and brokerages that support passkeys (an expanding list) should be converted. Check your institution's security settings.
• Developer infrastructure — GitHub, AWS IAM Identity Center, and similar platforms where a compromise could have supply-chain consequences.

On the device-bound vs. synced question: for most people, synced passkeys are the right choice. They are vastly more secure than passwords, resist phishing completely, and survive device loss via account recovery. Device-bound passkeys on hardware keys are appropriate for accounts with exceptional security requirements — privileged admin access, financial institutions, or people with specific threat models (journalists, activists, executives).

Passwords are not dead yet. Legacy systems, poorly implemented "passkey" flows that fall back to passwords too easily, and the long tail of sites that have not adopted WebAuthn mean passwords will persist for years. But for the accounts that matter most, the transition has already happened. The question is no longer whether to move to passkeys. It is how fast.