Passkeys are finally becoming mainstream
Passwordless sign-in has moved from an early-adopter feature to a serious authentication strategy, but the hard work is now migration, recovery, and trust.
Passwords have been declared dead so many times that the phrase barely means anything anymore.
For years, the replacement story was always just around the corner. Biometrics would replace passwords. Security keys would replace passwords. One-time codes would replace passwords. Password managers would make passwords painless enough that we could stop worrying about them.
Yet passwords stayed.
They stayed because they were universal. Every browser understood them. Every device could type them. Every support team knew how to reset them. Every application already had a password field, a database column, a recovery flow, and years of operational knowledge built around the same flawed credential.
Passkeys are different because they are no longer just a promising security standard. They have reached the point where billions of credentials are in use, every major platform supports them, enterprise identity systems can deploy them, and users increasingly encounter them in normal account flows.
The FIDO Alliance reported in May 2026 that an estimated 5 billion passkeys were in active use. Its consumer survey found that 90 percent of respondents were familiar with passkeys and 75 percent had enabled them on at least some accounts. In the workforce survey, 68 percent of organizations said they were deploying, piloting, or rolling out passkeys for employee authentication.
That is not the end of passwords.
It is the start of a serious migration away from them.
The interesting question is no longer whether passkeys work. They do.
The interesting questions are harder:
How do passkeys actually prevent phishing?
What happens when a user loses a device?
Are synced passkeys safe enough for enterprise use?
How should applications support users who are not ready?
What happens to account recovery?
How do teams migrate without creating a confusing login page?
When should a company require device-bound credentials instead?
Does password fallback cancel the security benefit?
This article looks at those questions from a product and engineering perspective.
Why passkeys crossed the mainstream threshold
Passkeys did not become mainstream because one company launched a new login button.
They became mainstream because several parts of the ecosystem matured at the same time.
The major platforms now agree on the model
Passkeys are built on the FIDO2 stack, which combines Web Authentication, usually called WebAuthn, with the Client to Authenticator Protocol, or CTAP.
WebAuthn defines how a website or application creates and uses public-key credentials. CTAP defines how a client platform communicates with authenticators, including built-in device authenticators, phones, and hardware security keys.
Apple, Google, Microsoft, browser vendors, password managers, and identity providers now support the same basic model.
Apple supports passkeys through iCloud Keychain and external credential providers. Google Password Manager syncs passkeys across Android and Chrome environments. Windows provides native passkey creation and management. Microsoft Entra supports both device-bound and synced FIDO2 passkeys. Third-party password managers can store passkeys on supported systems.
That shared platform support matters more than any single product announcement.
Authentication is an ecosystem problem. A credential only becomes practical when it works across browsers, operating systems, applications, credential managers, and devices.
Passwords won because they worked everywhere.
Passkeys are now close enough to that level of availability to become a default rather than an experiment.
The adoption numbers are no longer small
The FIDO Alliance's 2026 report surveyed 11,000 consumers and 1,400 workforce decision-makers across ten countries. It reported:
| Signal | 2026 result |
|---|---|
| Estimated passkeys in active use | 5 billion |
| Consumers familiar with passkeys | 90% |
| Consumers who enabled passkeys on some accounts | 75% |
| Consumers who regularly use passkeys when available | 49% |
| Organizations deploying, piloting, or rolling out passkeys | 68% |
| Organizations that see fully passwordless authentication as the goal | 82% |
The details matter.
Awareness is not the same as understanding. Enabling a passkey on one account is not the same as abandoning passwords. Piloting passkeys is not the same as completing an enterprise migration.
Still, these are mainstream adoption signals.
Passkeys are no longer limited to security teams, developers, and users carrying hardware keys.
They are becoming part of normal account creation and sign-in.
User experience finally became competitive
Security improvements often fail when they make login harder.
Passkeys have a chance because the secure action can also be the easier action.
A user can sign in by unlocking a device with a fingerprint, face scan, PIN, or pattern. The relying party does not receive the biometric data. The local device uses that gesture to unlock the private key and produce a cryptographic signature.
Microsoft reports that, in its Entra experience, synced passkeys were significantly faster and more successful than legacy password plus MFA flows. Its documentation says users completed synced passkey sign-in in about 3 seconds compared with 69 seconds for a password plus traditional MFA combination, with a 95 percent sign-in success rate compared with 30 percent for the legacy flow.
Vendor-reported measurements need context, but the direction is believable. Passkeys remove several fragile steps:
Remember a password
Enter the password correctly
Wait for a code
Switch apps
Copy the code
Return to the login screen
Hope the code has not expired
Repeat after a mistake
A case study published by Google reports that Dashlane saw a 92 percent conversion rate when users were offered an available passkey, compared with 54 percent for automatic password sign-in opportunities. Dashlane also reported a 63 percent conversion rate for passkey registration opportunities compared with roughly 25 percent for password-save prompts.
Passkeys are succeeding because they are not merely more secure.
When the flow is designed well, they are easier.
Portability and management are improving
Early passkey criticism focused heavily on ecosystem lock-in.
A passkey saved to one platform account did not necessarily move easily to another credential manager. A user switching ecosystems could end up with confusing recovery paths or duplicate credentials.
That problem is not completely gone, but the ecosystem is improving.
Apple now describes support for secure passkey import and export between password managers. W3C work on passkey endpoints aims to make enrollment and management pages discoverable to credential managers. Password managers increasingly support passkey storage, synchronization, and cross-device use.
The result is a system that feels less like a credential trapped on one phone and more like an authentication method that can survive device changes.
Mainstream does not mean complete
The 5 billion figure is a milestone, not proof that passwords are gone.
Many services still keep passwords as fallback. Many users do not know where their passkeys are stored. Cross-platform behavior can still be confusing. Recovery can still fall back to weak channels. Enterprise requirements vary. Shared-device and regulated environments need stronger controls.
Passkeys are mainstream because the default path is now viable.
The next phase is about making the whole account lifecycle secure.
How passkeys actually work
The best way to understand passkeys is to forget the fingerprint for a moment.
A fingerprint is not the passkey.
Face ID is not the passkey.
A device PIN is not the passkey.
Those are local methods used to unlock the authenticator.
The passkey itself is a public-key credential.
Registration creates a key pair
When a user creates a passkey, the application asks the browser or operating system to create a WebAuthn credential.
The authenticator creates a cryptographic key pair:
A private key, which stays with the authenticator or protected credential provider
A public key, which is sent to the relying party and stored with the user's account
The server does not receive the private key.
It also does not need the user's fingerprint, face data, or device PIN.
The server stores data such as:
Credential ID
Public key
User handle
Signature counter where applicable
Authenticator metadata where applicable
Creation time
Friendly device or provider label
Backup and transport-related flags where available
The exact implementation depends on the WebAuthn library and policy.
Authentication proves possession of the private key
During sign-in, the server generates a fresh random challenge.
The authenticator signs that challenge with the private key after the user unlocks it locally. The server verifies the signature using the stored public key.
The challenge prevents replay.
An attacker cannot capture one successful response and reuse it later because the next login uses a different challenge.
Origin binding blocks normal phishing flows
This is the feature that makes passkeys fundamentally different from passwords and one-time codes.
A password is a shared secret. The user can type it into the real site or a fake site. The fake site can steal it.
A one-time code is also transferable. A phishing page can ask for the code and relay it to the real service.
A passkey is scoped to a relying party.
A credential created for example.com cannot be used by examp1e.com, even if the fake site looks identical.
The browser and authenticator jointly enforce this relationship.
This is why passkeys are described as phishing-resistant.
The protection is not based on the user noticing a suspicious URL.
The credential itself will not authenticate to the wrong relying party.
The biometric never goes to the server
Passkey interfaces often display Face ID, fingerprint, Windows Hello, or a device unlock screen. That leads some users to assume the website receives biometric information.
It does not.
The biometric is handled by the local platform. Its job is to authorize use of the private key.
Google's passkey documentation explicitly notes that biometric material never leaves the user's device. The server receives a signed cryptographic assertion, not a fingerprint image or facial template.
This separation matters for privacy.
The application does not become a biometric database.
Synced passkeys and device-bound passkeys are different
The word passkey covers more than one storage model.
| Type | Where the private key is available | Main benefit | Main concern |
|---|---|---|---|
| Synced passkey | Encrypted and synchronized through a credential provider | Convenience, recovery, multi-device use | Security depends partly on sync account and recovery |
| Device-bound passkey | Remains on one device or hardware key | Strong device control and provenance | Device loss and operational support |
| Hardware security key | Stored on a dedicated FIDO2 device | High assurance and portability | Cost, distribution, backup, user training |
A synced passkey is often the right choice for normal consumer accounts. It reduces the chance that device loss becomes account loss.
A device-bound passkey may be more appropriate for administrators, regulated users, privileged employees, or environments that need attestation and stronger device provenance.
Microsoft recommends FIDO2 security keys for highly regulated industries and elevated users, while describing synced passkeys as a practical option for most normal users.
This is a risk decision, not a debate about which type is universally better.
Cross-device authentication fills the gaps
A passkey does not need to exist on the device where the user is signing in.
Cross-device authentication lets a phone act as the authenticator for a laptop or another nearby device. A common flow uses a QR code and proximity checks, with the user approving the sign-in on the phone.
This improves practical interoperability.
A user can sign in on a borrowed or newly set up computer without manually copying a secret.
What passkeys solve and what they do not
Passkeys solve important authentication problems.
They do not solve identity as a whole.
That distinction is essential.
They remove reusable server-side password secrets
Traditional password systems store password hashes, not plaintext passwords when implemented correctly. Still, password databases are valuable targets because weak, reused, or cracked passwords can lead to account compromise.
With passkeys, the relying party stores public keys.
A stolen public key does not let an attacker authenticate.
That reduces the value of a credential database breach.
It does not make the entire account database harmless. Attackers still care about personal data, sessions, reset tokens, API keys, recovery methods, authorization records, and application vulnerabilities.
Passkeys reduce one major category of risk.
They do not remove the need for application security.
They resist credential stuffing
Credential stuffing depends on password reuse.
An attacker obtains an email and password pair from one breach, then tests it across many services.
Passkeys are unique to the relying party. There is no shared secret to reuse across sites.
This removes the basic economic model of credential stuffing for passkey-only accounts.
They remove many OTP phishing attacks
SMS codes, email codes, and authenticator-app codes can be phished because they are values a user can transfer to an attacker.
Passkeys are origin-bound.
That provides stronger phishing resistance than password plus SMS or password plus TOTP.
This does not mean all session theft disappears. Malware, compromised devices, malicious browser extensions, stolen session cookies, authorization bugs, and social engineering can still cause harm.
Authentication is one layer.
They reduce password reset volume
Password resets are expensive.
They create support costs, frustration, abandoned sign-ins, and security risk. Recovery flows are also common attack targets because they often use weaker verification than normal authentication.
Passkeys can reduce reset frequency because users do not need to remember a site-specific secret. Synced passkeys can survive device replacement when the credential provider restores them securely.
That is a major operational benefit.
But it only works if applications avoid rebuilding a weak password-reset system under a different name.
They do not prove the user is the person you think they are
A successful passkey authentication proves control of a credential bound to an account.
It does not automatically prove a legal identity, employee status, age, citizenship, license, or real-world person.
Identity proofing and authentication are separate processes.
Passkeys can strongly authenticate an enrolled account. They do not tell you whether the original enrollment was legitimate.
They do not replace authorization
A passkey answers:
Is this user in control of a valid credential for this account?
It does not answer:
Is this user allowed to refund $50,000?
Can this employee read this customer record?
Should this administrator be allowed to rotate production keys?
Authorization rules still matter.
High-risk actions may also require step-up authentication, transaction confirmation, approval, or device policy.
They do not automatically secure account recovery
This is the biggest design trap.
A service may advertise phishing-resistant passkeys while keeping a password, SMS code, or weak help-desk flow that can fully recover the account.
An attacker will use the weakest path.
If a phishable fallback can replace the passkey, the account is still phishable.
Passkeys can still improve everyday sign-in, but the service has not achieved full phishing resistance.
They do not remove device security
A passkey is only as safe as the environment that can unlock it.
If an attacker can unlock the device, control the operating system, compromise the credential provider account, or steal an active session, the account may still be at risk.
Passkeys reduce remote phishing and password attacks.
They do not make endpoint security irrelevant.
The hard parts are migration and recovery
The cryptography is not the hardest part of passkey adoption.
The account lifecycle is.
A production rollout has to support new users, existing users, multiple devices, lost devices, platform changes, shared devices, fallback, customer support, credential deletion, account recovery, and policy differences.
Do not force a sudden passwordless cutover
The safest rollout usually starts by adding passkeys to existing accounts.
A practical consumer migration looks like this:
Google's UX guidance recommends letting users authenticate through the familiar flow, clearly offering passkey creation, using the operating system dialog, and confirming successful creation without blocking the user's main task.
That is better than forcing users to understand passkeys before they can continue.
A migration should feel like an upgrade, not a security lecture.
Conditional UI makes mixed-mode sign-in cleaner
During migration, applications often support:
Passwords
Passkeys
Federated sign-in
Security keys
Recovery paths
A poor login screen turns this into a wall of buttons.
Conditional UI lets the browser or credential manager offer a passkey inside a familiar account field or autofill flow. The user can select an available credential without navigating to a separate "use passkey" screen.
This creates a smoother transition while passwords still exist.
The product goal should be one coherent sign-in experience, not separate authentication worlds.
Passkey creation needs clear language
Many users still do not know what a passkey is.
Do not assume the operating system prompt explains the whole concept.
A good setup message should say:
A passkey replaces the need to type a password on supported devices
It uses the device's normal unlock method
The website does not receive biometric data
The user should only create it on a personal or trusted device
The user can manage or remove passkeys later
Avoid technical explanations at the exact moment the user wants to continue.
Give a short explanation, then link to more detail.
Let users register more than one authenticator
A resilient account should not depend on one device.
For higher-value accounts, encourage users to register multiple authenticators:
Synced passkey through a credential provider
Second device-bound passkey
Backup hardware security key
Managed enterprise passkey
Another approved phishing-resistant authenticator
NIST guidance for syncable authenticators recommends binding multiple authenticators at higher assurance levels to support recovery.
That is a better recovery strategy than falling back to SMS.
Recovery is part of the threat model
Recovery needs the same design attention as sign-in.
A good recovery model might combine:
Another registered passkey
Trusted device approval
Strong identity re-verification
Enterprise administrator workflow
Recovery codes stored offline
Delayed recovery for sensitive accounts
Notifications to existing devices
Temporary restrictions after recovery
Human review for high-risk cases
A weak recovery model might rely on:
Email alone
SMS alone
Easily guessed personal questions
A support agent asking for public information
Immediate replacement of all authenticators
No notification to existing sessions
NIST warns that cloud sync-account recovery represents a potential weakness for synced authenticators. It recommends strong recovery controls, multiple authenticators, notifications, and careful protection of the sync fabric.
The key principle is simple:
Recovery should not be dramatically weaker than normal authentication.
Synced credentials move some trust to the provider account
Synced passkeys solve a real problem.
People lose phones. They replace laptops. Devices fail. Without synchronization, strong credentials can create painful recovery incidents.
But synchronization changes the trust model.
The passkey is encrypted and protected by the credential provider, but the security of that provider account and its recovery process becomes important.
For many consumer accounts, this is still a major improvement over passwords and SMS.
For high-assurance enterprise environments, the organization may prefer:
Device-bound credentials
Hardware security keys
Managed device enrollment
Attestation requirements
Restricted credential providers
Stronger administrator-controlled recovery
The correct choice depends on risk.
Shared devices need extra care
A passkey can be unlocked by anyone who can unlock the device.
That makes shared devices a special case.
Applications should clearly warn users not to create personal passkeys on public or shared devices. Managed environments need policies for user profiles, device ownership, credential storage, and local account separation.
Google's own user guidance warns people to create passkeys only on devices they personally own and use.
This is not a flaw in passkey cryptography.
It is a consequence of using local device access as the activation factor.
Credential management cannot stay buried
Users need a clear place to:
View registered passkeys
See creation dates
See provider or device labels
Rename credentials
Remove lost or old credentials
Add backup authenticators
Review recent authentication activity
Understand the impact of deletion
The W3C passkey endpoints work addresses a practical problem: enrollment and management pages are often hidden deep inside account settings. Standardized discovery could let credential managers direct users to the correct enrollment and management pages.
This may sound minor.
It is not.
Authentication systems fail operationally when users cannot manage their credentials.
Deleting a passkey may have side effects
Some applications can use WebAuthn extensions to derive secrets for encryption or related functionality.
If deleting a passkey affects access to encrypted data, the user needs a clear warning.
The W3C passkey endpoints draft includes a mechanism for relying parties to describe passkey use beyond authentication so credential managers can warn users during deletion.
This is a reminder that passkeys are becoming application infrastructure, not just login buttons.
Enterprise rollout needs segmentation
Not every employee needs the same credential policy.
A practical enterprise model might look like this:
| User group | Recommended direction |
|---|---|
| General workforce | Synced passkeys or managed platform passkeys |
| Developers | Managed passkeys plus strong recovery |
| Administrators | Device-bound passkeys or hardware security keys |
| Finance and high-value approvers | Device-bound credentials with step-up controls |
| Contractors | Time-limited managed access with clear offboarding |
| Shared workstation users | Controlled device-bound or roaming authenticator strategy |
The goal is not to choose one credential type for everyone.
The goal is to match assurance, convenience, cost, and support requirements.
Keep authentication and session security connected
A perfect passkey login can still lead to an insecure session.
Teams must still secure:
Session cookies
Token rotation
CSRF protection
Device and session management
Reauthentication for sensitive actions
Logout and session revocation
Suspicious login detection
Authorization checks
Account change notifications
Passkeys strengthen the front door.
They do not secure every room inside the application.
A practical implementation roadmap
Passkey support should be treated as an identity migration, not a frontend feature.
The work spans product, backend, mobile, web, security, support, and operations.
Phase one: understand your current authentication system
Before writing WebAuthn code, map the real account lifecycle.
Document:
Current sign-up methods
Current sign-in methods
MFA methods
Password reset
Account recovery
Device changes
Session management
High-risk action verification
Support-assisted recovery
Account deletion
Enterprise SSO interactions
Fraud and abuse controls
This will reveal where the weakest paths are.
A team that adds passkeys without understanding recovery may create a strong login button attached to the same weak account system.
Phase two: define the relying party model
WebAuthn credentials are scoped to a relying party ID.
That decision affects domains and applications.
Teams need to decide:
Which domain is the relying party ID?
Which subdomains should share credentials?
How do native apps associate with the web domain?
Are there separate consumer and enterprise accounts?
Do multiple brands share one account backend?
Will a future domain migration be required?
This is architecture work.
A careless relying party design can create long-term migration pain.
Phase three: choose credential policy
Decide which authenticators are accepted.
Questions include:
Are synced passkeys allowed?
Are device-bound passkeys required for some roles?
Are hardware security keys supported?
Is attestation required?
Are specific authenticator models allowed?
Is user verification required?
Can users register multiple credentials?
Are resident discoverable credentials required?
How are credentials named and managed?
Do not copy the strictest policy for every user.
A policy that creates too much friction will drive fallback use and support requests.
Phase four: implement registration correctly
A registration flow should:
Authenticate the user through an acceptable existing method.
Generate a fresh server-side challenge.
Bind the challenge to the user and session.
Provide the correct RP ID and origin expectations.
Request an appropriate authenticator configuration.
Verify the returned registration data.
Store the public credential and metadata.
Confirm successful creation.
Notify the user of the new authenticator.
Provide a direct link to credential management.
Use a maintained WebAuthn library where possible.
WebAuthn parsing and verification contain details that are easy to get wrong.
Phase five: implement authentication correctly
An authentication flow should verify:
Challenge matches the server-issued value
Challenge is fresh and single-use
Origin is allowed
RP ID hash is correct
Credential belongs to the account or resolves to the correct user
Signature is valid
User presence requirements are satisfied
User verification requirements are satisfied
Authenticator flags are handled according to policy
Session is created securely
Pseudocode for the server-side shape:
type StoredCredential = {
credentialId: string;
publicKey: Uint8Array;
userId: string;
signCount: number;
};
async function verifyPasskeyAuthentication(
response: AuthenticationResponse,
expectedChallenge: string,
expectedOrigin: string,
expectedRpId: string,
credential: StoredCredential,
): Promise<boolean> {
const result = await webauthn.verifyAuthenticationResponse({
response,
expectedChallenge,
expectedOrigin,
expectedRPID: expectedRpId,
credential: {
id: credential.credentialId,
publicKey: credential.publicKey,
counter: credential.signCount,
},
requireUserVerification: true,
});
if (!result.verified) {
return false;
}
await updateCredentialCounter(
credential.credentialId,
result.authenticationInfo.newCounter,
);
return true;
}
The exact API depends on the library.
The important point is that verification belongs on the server.
Phase six: add mixed-mode UX
During migration, support existing users without making passkeys feel secondary.
Good patterns include:
Offer passkey creation after successful sign-in
Use conditional UI where supported
Prefer passkeys when an available credential exists
Keep fallback discoverable but not dominant
Explain device unlock clearly
Confirm which account is being used
Avoid forcing users to choose technical authenticator types
Show clear errors when cross-device authentication fails
Provide a management page
The user should not need to understand WebAuthn terminology.
They need to know how to sign in.
Phase seven: redesign recovery
Do this before removing passwords.
Create a recovery matrix.
| Scenario | Recovery option |
|---|---|
| User has another synced device | Use synced passkey |
| User has another registered authenticator | Use backup authenticator |
| User has trusted active session | Approve new authenticator with step-up checks |
| User lost all authenticators | Strong account recovery process |
| Enterprise employee lost managed device | Help desk plus identity and device workflow |
| Privileged administrator lost hardware key | Backup key or high-assurance admin process |
| Suspected provider-account compromise | Revoke credentials and sessions, re-enroll securely |
Recovery should create audit events and notifications.
Sensitive accounts may need delays or temporary restrictions after recovery.
Phase eight: monitor the rollout
Measure the full experience.
Useful metrics include:
Passkey creation offer rate
Passkey creation success rate
Passkey sign-in success rate
Cancellation rate
Cross-device authentication success
Fallback use
Password reset volume
Support tickets
Recovery rate
Authentication latency
Account takeover rate
Phishing-related incidents
Credential deletion rate
Number of users with backup authenticators
Do not measure only the number of created passkeys.
A passkey that is never used does not represent a successful migration.
Phase nine: reduce weak fallback gradually
Once passkey adoption and recovery are healthy, reduce password dependence.
Possible steps:
Make passkey the default sign-in option.
Stop asking passkey users to type passwords during normal sign-in.
Require stronger verification before adding fallback methods.
Remove SMS fallback from high-risk accounts.
Require phishing-resistant authentication for privileged roles.
Let users opt into passkey-only accounts.
Eventually make passkey-first or passwordless the default for new accounts.
Do not remove fallback simply to claim passwordless status.
Remove it when the replacement lifecycle is ready.
A reference architecture
The architecture should separate:
Credential verification
User account data
Session creation
Risk decisions
Recovery
Credential management
Notifications
Audit logging
That separation makes the system easier to test and evolve.
Testing should include the awkward cases
A serious test plan needs more than successful registration on one laptop.
Test:
Registration on Android, iOS, macOS, Windows, and major browsers
Synced passkey use on another device
Cross-device authentication by QR code
Multiple accounts on one device
Multiple passkeys for one account
Shared-device warning
Credential cancellation
Expired challenge
Replayed assertion
Wrong origin
Wrong RP ID
Deleted credential
Lost device
User changes credential provider
Password fallback
Recovery with no remaining authenticators
Enterprise policy restrictions
Account offboarding
Accessibility with keyboard and assistive technology
Authentication bugs lock users out.
Treat compatibility and recovery tests as production-critical.
The final security model must be honest
A service should not claim to be phishing-resistant if a phishable recovery path can fully replace the passkey.
A service should not claim passwordless if users still need passwords for routine account maintenance.
A service should not claim biometric authentication if it does not explain that biometrics remain local.
A service should not claim enterprise-grade passkeys without a plan for lifecycle, offboarding, attestation, and recovery.
Passkeys are strong enough that weak surrounding systems become more visible.
That is a good thing.
It pushes identity teams to improve the entire account lifecycle.
Passkeys are finally becoming mainstream because the ecosystem is ready enough for normal users.
The next challenge is not proving that public-key authentication works.
It is making migration, recovery, support, and policy work just as well.
Passwords survived because they were familiar and recoverable, even when they were insecure.
Passkeys will replace them only when they become equally dependable without inheriting the same weak fallbacks.
The industry is closer than it has ever been.
This time, the passwordless future does not feel like a slogan.
It feels like an implementation plan.
