Passwords persist because they are universal, cheap to deploy, and easy to understand—not because they work well. People reuse them, attackers phish them, and companies must store password verifiers that become valuable breach targets. Passkeys change that structure. They replace a shared secret with a public-private key pair tied to a particular service, allowing a person to sign in with the same local gesture used to unlock a phone or laptop.
The private key remains in an authenticator, such as a device, password manager, or hardware security key. The website stores a public key and sends a fresh challenge at sign-in; the authenticator signs it after the user approves. Because the credential is scoped to the legitimate relying party, a look-alike phishing site cannot ask the authenticator to produce a valid signature for the real domain. NIST’s 2025 digital identity guidance explains that manually entered one-time codes are not phishing-resistant, while WebAuthn can provide resistance through verifier-name binding (NIST).
Adoption is no longer experimental. A FIDO Alliance survey released in May 2026 estimated that 5 billion passkeys were in active use. Among 11,000 adults in ten countries surveyed in April, 90 percent knew about passkeys and 75 percent had enabled one on at least one account. A separate workforce sample of 1,400 decision-makers found that 68 percent of large organizations were deploying, piloting, or rolling out passkeys (FIDO Alliance). Those are industry-sponsored survey results, not a census of all internet users, but they indicate that platform support has translated into substantial use.
The standards are also maturing. In August 2026, the World Wide Web Consortium published Web Authentication Level 3 as a Recommendation. It defines strong, scoped public-key credentials created with user consent and accessible only to origins belonging to the relying party (W3C). Major operating systems and browsers already implement the earlier WebAuthn and FIDO2 foundations. CISA summarizes the security case bluntly: “The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication” (CISA).
That does not mean every passkey deployment is equivalent. Device-bound passkeys remain on a particular authenticator, offering tight control but requiring a spare key or another recovery route. Synced passkeys travel among a user’s approved devices through a credential manager, making them practical for ordinary consumers. Apple says passkeys in iCloud Keychain are end-to-end encrypted and unavailable even to Apple (Apple). Other ecosystems use their own synchronization and recovery designs. The account protecting that sync fabric becomes consequential, so strong device security and well-designed recovery still matter.
Recovery is where the passwordless promise meets operational reality. A lost phone, closed email account, deceased family member, or employee departure can turn an elegant sign-in flow into a support problem. Services commonly retain fallback methods—passwords, email links, SMS codes, recovery codes, or help-desk verification. An attacker will naturally choose the weakest available path. Organizations therefore need to treat enrollment and recovery as security-sensitive events, notify users when a new passkey is added, and apply extra checks to high-value accounts.
Interoperability has improved, but friction remains. A person may have an iPhone at home, a Windows computer at work, and credentials divided between several managers. Cross-device sign-in can use a nearby phone, yet QR codes and Bluetooth proximity are less seamless than an autofilled password. Shared household accounts, managed enterprise devices, regulated audit requirements, and older applications need tailored designs. Some sites also offer passkeys merely as an additional sign-in option while leaving a phishable password active, limiting the security gain.
For businesses, the sensible transition is staged. Start with administrators and frequently phished users, support both synced and hardware-bound credentials according to risk, inventory fallback routes, and measure completion and recovery rates. NIST now requires verifiers at Authentication Assurance Level 2 to offer at least one phishing-resistant option (NIST). That policy direction matters: passkeys are becoming normal infrastructure, not a novelty.
Metrics should separate availability from use. A service can technically support passkeys while burying enrollment, prompting for a password first, or steering people back to SMS during recovery. Completion time, repeat usage, failed cross-device attempts, fallback frequency, and help-desk recovery volume reveal whether the stronger method is actually becoming the default.
Passwords will not disappear on a product-launch schedule. Legacy systems and account-recovery habits change slowly. But every service that moves primary authentication to an origin-bound key removes password reuse, credential stuffing, and ordinary phishing from that path. The replacement is gradual precisely because authentication is an ecosystem. Its progress is meaningful because the underlying security model is better.