Passkeys are the post-password authentication credential. They replace both the traditional password and the additional MFA code that authenticator apps produce, with a single cryptographic credential bound to a specific device or synced across the user’s devices through their platform identity system. The standard that defines them, FIDO2 + WebAuthn, has been around for several years; the meaningful change in 2025 and 2026 is that the cross-device sync problem has been solved by the major platform providers, which made passkeys broadly adoptable for consumer use. The result is that an increasing fraction of major services (Apple, Google, Microsoft, GitHub, Amazon, PayPal, every major bank, and a long tail of smaller services) now support passkey login as an alternative or replacement for password-plus-MFA login.
This piece is the companion to our authenticator apps explainer. Where the authenticator apps post answered "why is the TOTP code substantively different from an SMS code," this one answers "what comes after the TOTP code." The piece walks through what passkeys actually are technically, the asymmetric cryptography that gives them their security properties, the platform sync systems that made them usable, the current 2026 adoption landscape, the practical user experience, and the limitations worth understanding before committing to a passkey-first authentication posture.
The short version is that passkeys are the right authentication primitive for the threats that matter most in 2026. They eliminate password phishing entirely (because there’s no password to phish), eliminate the SMS interception and SIM swapping risks that affect SMS MFA, and provide a usable cross-device experience that the earlier hardware-key-only FIDO implementations did not. The migration to passkeys is not yet complete (many services don’t support them, some that do support them poorly), but the direction is clear and the broader user base is gradually transitioning.
What passkeys actually are
A passkey is a pair of cryptographic keys: a private key and a public key. The private key is generated on the user’s device and stays on that device (or in the user’s platform-synced credential storage). The public key is sent to the service when the user creates the passkey and is stored by the service.
At login time, the service sends a challenge (a random string) to the user’s device. The device uses the private key to sign the challenge. The signature is sent back to the service. The service verifies the signature using the stored public key. If the signature is valid, the user is authenticated.
The defining property of this mechanism: the private key never leaves the user’s device, and the service never sees the private key. The service stores only the public key, which is useless to an attacker. A data breach that exposes the service’s user database does not expose any credentials the attacker can use to log in. There is no password to phish because there is no password.
This is the substantive security property of passkeys. It is qualitatively different from passwords (which are shared secrets that both sides know) and from TOTP codes (which are derived from a shared secret). The asymmetric cryptography means there is no shared secret at all; there is only the user’s private key and the service’s public key, and the two never meet.
The FIDO2 + WebAuthn standards
The standards that define passkeys are FIDO2 and WebAuthn, both developed by the FIDO Alliance (a consortium of major technology companies, financial institutions, and security vendors).
WebAuthn is the W3C-standardized API that web browsers expose to websites for cryptographic authentication. When a website wants to register a passkey or authenticate with one, it calls WebAuthn APIs in the browser. The browser handles the user interaction (showing a prompt, collecting biometric or PIN verification) and the cryptographic operations.
FIDO2 is the broader specification that includes WebAuthn plus the device-side protocols (CTAP, the Client-to-Authenticator Protocol) that let external devices like hardware security keys participate. Together they define how passkeys work end-to-end.
The standards are mature, broadly implemented, and not subject to vendor lock-in in the architectural sense (any compliant browser and any compliant authenticator can interoperate). The practical adoption has been gated by the sync problem, not by the standards.
The sync problem and how it got solved
The original FIDO authentication model was device-bound: the private key was generated on a specific hardware device (a YubiKey, a phone, a laptop’s TPM) and stayed there. This was secure but operationally painful: if you lost the device or wanted to log in from a different device, you had to enroll the new device separately. For high-value accounts at enterprises with hardware-key issuance programs this was acceptable; for consumer use it was a non-starter.
The breakthrough that made consumer passkeys viable was the platform sync model. The major platform providers (Apple, Google, Microsoft) built credential synchronization into their identity systems:
Apple iCloud Keychain syncs passkeys across all the user’s Apple devices (iPhone, iPad, Mac). When the user creates a passkey on one device, it’s available on the others. The sync is end-to-end encrypted so Apple cannot see the credentials.
Google Password Manager syncs passkeys across the user’s Google account, including Android devices, Chrome browsers on any platform, and ChromeOS devices. The sync is similarly end-to-end encrypted.
Microsoft account / Windows Hello syncs passkeys across the user’s Microsoft account on Windows devices and where the user is signed into Edge.
1Password, Bitwarden, Dashlane, and other password managers support passkey sync across devices, often as a more cross-platform option than the platform-specific syncs (works the same across Apple, Google, and Microsoft ecosystems).
The sync model preserves the security property that the credential never leaves the user’s control (it’s end-to-end encrypted in the sync) while removing the operational pain of device-bound credentials. A user with a passkey on their iPhone can log in from their Mac because the passkey is also on the Mac through iCloud Keychain.
The trade-off is that the user is now trusting their platform provider’s identity system to keep the synced credentials secure. The major platforms have invested heavily in this; the trust is reasonable for most users. For users who don’t want to trust any single platform, the third-party password manager option (especially 1Password and Bitwarden) provides cross-platform sync that doesn’t tie them to a single ecosystem.
The user experience
The user experience of a passkey login, when it works well:
The user navigates to a website and clicks "Sign in." The website shows a login form, but instead of (or alongside) the password field, it shows a "Sign in with passkey" button. The user clicks it. The browser (or the operating system) shows a prompt asking the user to verify with their biometric or device PIN. The user uses Face ID or Touch ID or types the PIN. The browser confirms the passkey login to the website. The user is logged in.
The whole sequence is typically 5 to 10 seconds. There is no password to remember or type. There is no authenticator app to open or code to read. The biometric verification confirms the user is the device owner, and the cryptographic exchange confirms the device is registered with the service.
When the experience works, it’s substantially better than password-plus-MFA. The user effort is one biometric tap, compared to typing a password, opening an authenticator app, reading a code, and typing the code.
The experience has rough edges. Different browsers and platforms handle passkeys slightly differently. Cross-device passkey sign-in (using a passkey from one device to sign in on another device) sometimes requires QR-code scanning that’s clunky. Some websites have implemented passkey support poorly enough that the user experience is worse than the password equivalent. The category is still maturing.
Adoption status in 2026
The major services that have shipped meaningful passkey support as of mid-2026:
Platform identity providers: Apple ID, Google account, Microsoft account, GitHub, GitLab, Bitwarden, 1Password.
Financial services: PayPal, most major US banks (Chase, Bank of America, Wells Fargo, Capital One have native support; smaller banks vary), Robinhood, Coinbase, most major cryptocurrency exchanges.
Major consumer services: Amazon, eBay, Best Buy, Target, Walmart (with varying quality), Shopify accounts (both merchant and customer side).
Productivity and SaaS: Slack, Notion, Atlassian, Salesforce, HubSpot, Zoom, most major CRM and project management tools.
Social and content: X (formerly Twitter), Facebook, Instagram, LinkedIn (limited rollout), YouTube via Google account, TikTok, Reddit.
Developer infrastructure: GitHub, GitLab, Bitbucket, the major cloud providers (AWS Console, Google Cloud Console, Azure), the major package managers (npm, PyPI).
The adoption is broad across major services but not yet universal. A user attempting to go fully passwordless will encounter a long tail of smaller services that don’t support passkeys yet, where they’ll fall back to password + TOTP or password + SMS. The migration is real but is gradual rather than complete.
The major services have generally implemented passkey support as an addition to password-plus-MFA rather than as a replacement. Users can opt in to passkey-only login on some services, but most services still allow password login as a backup, which means password-related risks aren’t fully eliminated even after the user adopts passkeys.
How passkeys differ from authenticator app TOTP
The substantive comparison with the authenticator apps covered in the companion piece:
Passkeys use asymmetric cryptography; TOTP uses a shared secret. The TOTP secret is on both the user’s device and the service’s server. If the service is breached, the secret is exposed (though attackers would need the secret to generate codes, and most attackers don’t get the secret database). Passkeys store only the public key on the service side, which is useless to an attacker.
Passkeys eliminate the password; TOTP supplements it. With password-plus-TOTP, the user still has a password that can be phished or breached. The TOTP makes the password less valuable to an attacker, but the password remains a credential. Passkeys remove the password entirely.
Passkeys are phishing-resistant in a way TOTP is not. A phishing site can capture a TOTP code (the user types it in, the site forwards it to the real service). A phishing site cannot capture a passkey because the cryptographic exchange is tied to the actual domain; the browser refuses to use a passkey on the wrong domain.
Passkeys require platform support; TOTP works anywhere. The major operating systems and browsers support passkeys, but specific older devices or air-gapped environments may not. TOTP works on any phone with an authenticator app.
Passkeys have a sync model; TOTP secrets are device-bound by default. Modern authenticator apps offer cloud sync, but the original pattern was device-bound. Passkeys are sync-first.
The honest reading: passkeys are strictly better than password+TOTP for the threats that matter most. The adoption gap is what’s preventing universal use; for services that support both, passkeys are the right choice. For services that only support password+TOTP, the existing pattern remains appropriate until passkey support arrives.
Limitations and known issues
A few specific limitations worth being explicit about:
Cross-platform sync between ecosystems is awkward. A passkey synced through iCloud Keychain doesn’t automatically sync to Google Password Manager. A user who switches phone platforms (Android to iPhone) has to re-enroll passkeys on the new platform. Cross-platform users typically use a third-party password manager (1Password or Bitwarden) to bridge this gap.
Account recovery is complicated. If a user loses access to their platform identity (forgets the Apple ID password, gets locked out of the Google account), they may lose access to all the passkeys synced through that identity. The recovery paths exist but are typically more elaborate than password recovery. Backing up recovery codes for important accounts is essential.
Some services implement passkey support poorly. A service that requires the user to set up a passkey but also requires the user to keep their password as a backup hasn’t eliminated the password’s risk surface. A service that only allows passkey login on the device where the passkey was created hasn’t taken advantage of the sync. The implementation quality varies across services.
Hardware key advocates have concerns about syncing. A passkey synced through a cloud service is theoretically less secure than a hardware-key-bound passkey because the cloud service is in the trust chain. For most users this is an acceptable trade-off (the platform providers’ security is very strong); for high-stakes accounts, hardware keys remain the more conservative choice.
Older browsers and platforms don’t support passkeys. A user with an older operating system or browser will have a degraded experience. The major platforms have brought passkey support to recent versions; older versions remain on password-based authentication.
Enterprise IT policies sometimes block passkeys. Some enterprise environments disallow consumer-grade authentication (iCloud Keychain, Google Password Manager) for compliance reasons. These environments typically use enterprise-managed hardware keys or the enterprise version of platform passkey storage instead.
Phishing-resistance is partial without proper service implementation. Passkeys are phishing-resistant when the browser correctly validates the domain. Services that have implemented passkey support incorrectly can create attack vectors that defeat the phishing resistance. This is a service-implementation issue rather than a passkey-architecture issue, but it affects what users actually experience.
The migration path
For users deciding how to migrate to passkeys:
Start with high-value accounts. Email (because email is the recovery path for everything else), financial accounts, primary social media accounts. The services where passkey support is most mature and the security improvement is most valuable.
Use passkeys where they’re available; keep password+TOTP where they’re not. The migration is gradual. There’s no need to wait for universal passkey adoption to start using passkeys on the services that already support them.
Pick a passkey storage strategy. Either commit to a platform identity provider (Apple, Google, Microsoft) and use their built-in passkey sync, or use a third-party password manager (1Password, Bitwarden) that supports passkeys cross-platform. Most users benefit from the third-party approach because it provides cross-platform sync without locking them into a single ecosystem.
Don’t remove the password right away. Even when a service supports passkey-only login, keep the password as a recovery option until you’re confident in the passkey setup. The password risk is real but the migration risk of getting locked out of your account is also real.
Save recovery codes. Every service that supports passkeys provides backup recovery codes. Save them in your password manager or in a secure offline location.
Test the recovery path. Before you commit to a passkey-only login, verify that you can recover the account if you lose your devices. This is the single most-skipped step in passkey adoption and the most likely to cause future problems.
Frequently asked questions
Are passkeys really more secure than passwords + TOTP? Yes, for the threats that matter most. They eliminate password phishing entirely and are not vulnerable to the SS7 or SIM swap attacks that affect SMS MFA. They are also more resilient to phishing in general because the cryptographic exchange is tied to the actual domain.
Can I use a passkey on multiple devices? Yes, through the platform sync (Apple, Google, Microsoft) or through a cross-platform password manager (1Password, Bitwarden). The original device-bound model has been superseded by the sync model for most consumer use.
What if I lose all my devices? Account recovery depends on the service. Most services provide recovery codes during passkey setup; keep these. The platform identity providers also have account recovery flows (sometimes involving identity verification through a trusted contact or a recovery key). Test these before you commit to passkey-only login.
Do I need to delete my password when I add a passkey? Not immediately. Most services allow you to have both a password and a passkey simultaneously. Delete the password once you’re confident in the passkey setup. Some users keep the password indefinitely as a backup; this defeats some of the security improvement but is operationally safer.
Are passkeys compatible with hardware security keys? Yes. A hardware key like a YubiKey can store passkeys and is the most secure option (the private key never leaves the hardware). The trade-off is that hardware keys aren’t sync-enabled, so you need backup keys to handle loss.
Can attackers steal my passkey? Theoretically, by compromising your device or your platform identity. Practically, both of these require either physical access to the device with the biometric or a substantial compromise of the platform identity system. The attack surface is much smaller than for passwords, which are stealable through many more paths.
Why does the browser show a passkey prompt sometimes when I don’t want to use it? The browser is offering to use a stored passkey it has access to. You can usually decline and proceed with password login, though some browsers make this harder than others. Better browsers let you configure passkey behavior per-site.
How does this affect enterprise IT? Enterprises that have invested in centralized identity (Okta, Azure AD, similar) can integrate passkey support into their identity provider, which gives users a single passkey that works across all their enterprise applications. The enterprise rollout is generally slower than the consumer rollout but is happening.
What about syncing passkeys across Apple and Google devices? Cross-platform sync requires a third-party password manager. 1Password and Bitwarden are the major options; both work on iOS, Android, Windows, Mac, and Linux. The platform-specific syncs (iCloud Keychain, Google Password Manager) don’t cross between ecosystems.
Should I use passkeys for everything that supports them? Yes, with the caveat of saving recovery codes for the high-stakes accounts. The security improvement is real and the user experience is generally better. Adoption is gradual; use passkeys where they’re available and password+TOTP where they’re not.
This piece is the companion to our authenticator apps explainer. Together they cover the practical security thread from "why MFA matters" through "what comes after passwords."
