Passkeys in Practice: Adoption, Limitations, and What Comes Next

Passkeys are changing how people sign in to websites and apps. They can eliminate the need to remember passwords and provide strong protection against phishing, but the experience depends on where credentials are stored, how they are backed up, and what happens when a user loses access to a device or account. Understanding these details is essential before relying on passkeys for important accounts.

The security advantages of passkeys are well established, but adopting them involves more than clicking an option in an account's security settings. Users need to understand the difference between a credential stored on one device and one that syncs across devices, the recovery options provided by each service, and the limitations that can appear when switching operating systems.

This guide examines those practical issues, explains what to check before moving away from passwords, and outlines a sensible approach to using passkeys without creating unnecessary account-access risks.

In this post

1. How passkeys work in practice
2. Passkey adoption and real-world usability
3. Passkey storage and cross-device synchronization
4. Account recovery after losing a device
5. How to evaluate a service's passkey implementation
6. Common implementation problems
7. Portability and ecosystem dependence
8. Security limitations and remaining risks
9. A practical passkey setup checklist
10. What to watch for next

1. How passkeys work in practice

A passkey is a credential based on public-key cryptography. When a user registers one with a service, the authenticator creates a key pair. The service stores the public key, while the corresponding private key remains protected by the authenticator or credential-management system.

During sign-in, the service sends a cryptographic challenge. The authenticator uses the private key to produce a response, which the service verifies using the registered public key. Depending on the authenticator and configuration, the user may need to unlock the device with a fingerprint, face recognition, a PIN, or another local verification method.

This differs from a conventional password login. A password is a reusable secret that a user enters into a website. A passkey instead uses a cryptographic operation tied to the legitimate website or application. That origin binding helps prevent a fraudulent website from using a passkey registered for the genuine service.

Three concepts that are easy to confuse

• Passkey: The credential used to authenticate to a service through a public-key cryptographic protocol.
• Authenticator: The device, operating system, security key, or credential provider that manages and uses the credential.
• Credential synchronization: A mechanism that makes an eligible passkey available on other authorized devices. Synchronization is a separate feature, not a requirement of public-key authentication itself.

Passkeys are generally created and used through the WebAuthn and FIDO2 standards. The service does not normally receive the private key during registration or sign-in. This reduces the risk associated with stolen password databases, although it does not eliminate every way an account can be compromised.

For technical details, see the official Web Authentication specification and the FIDO Alliance passkeys overview.

2. Passkey adoption and real-world usability

Passkeys are available across major operating systems, browsers, and credential managers. However, support for creating or using a passkey does not automatically mean that a service offers a complete passwordless experience.

A website may let existing users add a passkey but still require a password when creating an account, changing security settings, or recovering access. Another service may offer passkey sign-in only through its website, while a separate application uses a different authentication flow. These differences are usually related to product design, integration choices, and security policy rather than a fundamental limitation of the passkey standard.

It helps to assess adoption at three separate levels:

• Platform support: Can the device, operating system, browser, or credential manager create and use passkeys?
• Service support: Does the particular website or app permit passkey registration and authentication?
• Account policy: Can passkeys replace passwords for the flows the user actually needs, and what other authentication or recovery methods remain available?

These distinctions matter when comparing services. A passkey button on a login screen is useful, but it does not reveal whether multiple credentials can be registered, whether account recovery is clear, or whether weaker fallback methods can still be used to take over the account.

There is no single adoption figure that describes every country, industry, platform, and user group. Rather than relying on a broad claim that passkeys have become universal, evaluate the services and devices relevant to your own accounts.

3. Passkey storage and cross-device synchronization

Where a passkey is stored affects how it can be used on another device. Some passkeys are synchronized through a credential manager, while others are tied to a particular authenticator. These approaches have different advantages.

For example, a synchronized passkey may be available on several devices after the user signs in to the same credential-management account and satisfies the provider's security requirements. A device-bound credential, by contrast, may require the original device or physical security key to be present during authentication.

Storage approach	Typical advantage	Practical consideration
Apple Passwords and iCloud Keychain	Convenient synchronization across supported Apple devices	Availability on non-Apple devices depends on supported cross-device or credential-provider workflows.
Google Password Manager	Convenient use across supported Android devices and Chrome environments	Cross-platform availability depends on the device, browser, account, and supported sign-in flow.
Third-party password manager	Can make credentials available across different operating systems	The user relies on the manager's security, account recovery, device compatibility, and export policies.
Hardware security key	Provides a separate physical authenticator that does not depend on cloud synchronization	The key must be available when required, and a second registered key is important for backup.
Device-bound authenticator	Can keep the credential tied to a particular device or protected hardware environment	Replacing or losing the device may require registering another credential or using the service's recovery process.

These categories are not perfectly interchangeable. Exact behavior depends on the credential provider, the type of passkey, and the service's authentication requirements. For example, a user may have a synchronized passkey in a password manager and a separate hardware security key registered to the same account.

What synchronization does and does not guarantee

Synchronization can make everyday sign-in much easier and reduce dependence on a single phone or computer. It does not guarantee that every device will be able to use the passkey in every situation.

Access may depend on being signed in to the credential provider, having the relevant synchronization feature enabled, completing a security check, or using a supported browser. A newly purchased device may also require additional setup before synchronized credentials become available.

It is therefore useful to test a second-device sign-in before relying on a passkey as the only practical way to access an important account.

4. Account recovery after losing a device

Account recovery deserves attention before a passkey is enabled, not after a phone has been lost or damaged. A passkey can make authentication easier while also changing the steps required to regain access when the original authenticator is unavailable.

There is no single recovery method used by every service. The available options depend on whether the passkey is synchronized, whether other authenticators are registered, and which recovery policies the service supports.

Common recovery scenarios

• Another device already has access. If a passkey is synchronized or another passkey is registered, the user may be able to sign in from that device and register a replacement credential.
• A second passkey is available. A separately registered passkey, including one stored on another device or hardware security key, can provide an alternative authentication route.
• The credential provider account can be recovered. If the passkey is synchronized, recovering access to the provider account may help restore access to eligible credentials. The provider's own recovery and verification requirements still apply.
• The service offers account recovery. A website may provide a recovery code, verified email process, identity checks, customer support, or another method for regaining access.
• No usable credential or recovery method remains. The user may face a lengthy verification process or, depending on the service's policy, may be unable to recover the account.

Important: Do not assume that losing a phone automatically means losing every passkey, or that synchronization automatically guarantees recovery. The result depends on where the credential is stored, whether another authorized device is available, and the provider's recovery rules.

Why recovery can weaken account security

A service may preserve email, SMS, customer support, or another fallback even when passkeys are enabled. This can be helpful for users who lose their credentials, but it also means the account may remain vulnerable through those alternative routes.

For example, an attacker who cannot authenticate with a registered passkey might attempt to compromise the account's email address or exploit a weak recovery process. Whether that attempt succeeds depends on the service's verification requirements and the security of the recovery channel.

This is not a reason to reject recovery options altogether. It is a reason to understand them. A recovery method should provide a practical way for the legitimate account owner to regain access without giving an attacker an easier route around strong authentication.

Build redundancy before you need it

For important accounts, register a second authentication method where the service supports it. That could be another passkey in a different location, a backup hardware security key, or a documented recovery method that you have tested.

Keep recovery codes in a secure place separate from the device they are intended to recover. Avoid storing the only copy in an account or on a device that depends on the same credentials you are trying to recover.

For your primary email account, take particular care. Email is often used to reset passwords or verify ownership of other accounts, so losing access to it can affect much more than one login.

5. How to evaluate a service's passkey implementation

Passkey quality is not determined solely by whether a service displays a passkey option. A useful evaluation looks at registration, sign-in, credential management, recovery, and the security of alternative authentication routes.

Before relying on passkeys for an important account, check the following areas.

Registration and credential management

• Can users register a passkey without unnecessary steps?
• Can more than one passkey be associated with the account?
• Can users view and remove old or unfamiliar credentials?
• Does the service explain whether a passkey is synchronized or tied to a particular authenticator?

Sign-in and account protection

• Is passkey sign-in available on the platforms and devices you actually use?
• Does the service clearly explain alternative sign-in methods?
• Are sensitive actions, such as changing recovery information, protected by suitable reauthentication?
• Can users review active sessions and revoke access after losing a device?

Recovery and portability

• Are recovery instructions available before an emergency occurs?
• Can a second authenticator be registered?
• Does account recovery depend on an email address or phone number that could itself be compromised?
• What happens if you change your phone, switch operating systems, or stop using your credential manager?

A service does not need to eliminate every alternative authentication method to offer good passkey support. It should, however, explain how those methods work and give users reasonable control over their registered credentials and recovery options.

6. Common implementation problems

Several design choices can make passkeys confusing or less convenient than they need to be. Understanding the difference between a standard limitation and a product decision helps users identify what can be improved and what may require a different setup.

Problem 1: Passkeys are difficult to find

A service may support passkeys but place registration deep inside its security settings. Users may never discover the feature, or may not know whether they have successfully registered a credential.

What to check: Look for the service's official security settings and confirm that the new credential appears in its registered passkeys or authentication-method list.

Problem 2: A single credential is the only option

If a service permits only one passkey, the user may have fewer convenient alternatives when changing devices. Some services allow multiple credentials, while others have account-specific restrictions or different management interfaces.

What to check: Before depending on a passkey, see whether you can register a second one or configure another secure recovery method.

Problem 3: Switching between devices is confusing

A passkey stored in one credential provider may not appear automatically in another provider. A desktop login may instead offer a cross-device flow, such as scanning a QR code and approving the request on a phone.

What to check: Test the actual sign-in flow from each device you use. Confirm that the browser, operating system, and credential provider support the required method.

Problem 4: Passwords and weaker fallback methods remain active

Some services allow a password, email verification, or SMS recovery even after a passkey is registered. These options can be important for account recovery, but their presence affects the account's overall security.

What to check: Review the available sign-in and recovery methods. Where a service offers suitable controls, disable methods you do not need and protect the remaining recovery channels.

Problem 5: Recovery instructions are unclear

Users may not know whether they should recover the credential provider account, use a backup authenticator, or contact the service itself. These are different procedures, and one does not necessarily replace the others.

What to check: Read the official recovery documentation and, where possible, confirm that your backup methods are usable before removing an old device.

These issues are not all defects in the passkey standard. Many arise from service-specific interface decisions, account policies, or incomplete explanations. Evaluating the complete authentication experience is more useful than judging a service by the presence of a single button.

7. Portability and ecosystem dependence

Moving between platforms is a practical concern for anyone who changes phones, uses a mixture of Android and Apple devices, or regularly works across Windows, macOS, and Linux.

A synchronized passkey may be readily available within its credential provider's supported ecosystem. Moving it to a different provider can be a separate process, and the exact options depend on the providers involved.

This does not mean passkeys can never be moved. The FIDO Alliance's Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) are designed to support credential exchange between compatible credential managers. Actual availability depends on the products, their versions, and the export and import workflows they implement.

When evaluating portability, distinguish three separate activities:

• Synchronization: Making eligible credentials available across devices using the same provider.
• Cross-device authentication: Using one device to authenticate to a service on another device without necessarily moving the credential.
• Credential transfer: Moving supported credentials from one credential manager to another through an available transfer process.

These mechanisms solve different problems. A QR-code sign-in flow, for example, can let a phone authenticate to a desktop session without exporting the passkey to the desktop's credential store.

A practical way to reduce dependence on one ecosystem: choose a credential-management strategy that matches the devices you use, register an independent backup where possible, and understand how to recover both your service account and your credential-provider account. Do not assume that a passkey can be exported freely or that every provider implements the same transfer features.

For current technical information, consult the FIDO Alliance's official standards and resources and the documentation published by your credential manager. Exporting authentication credentials is security-sensitive, so use supported transfer mechanisms rather than unofficial tools or untrusted files.

8. Security limitations and remaining risks

Passkeys provide strong protection against conventional phishing because authentication is bound to the legitimate website's origin. A fake login page generally cannot obtain a valid authentication response for the real service merely by asking a user to enter a secret.

That advantage is significant, but passkeys are not a complete account-security solution. Attackers may still target the systems and people surrounding the authentication process.

Risks that still matter

• Compromised devices: Malware or an attacker with sufficient access to an unlocked device may be able to abuse an authenticated session or interfere with the user.
• Credential-provider account compromise: If an attacker takes control of an account that manages synchronized credentials, the consequences depend on the provider's protection and recovery mechanisms.
• Weak account recovery: A poorly protected recovery channel may give an attacker another way to take control of an account without using its passkey.
• Session theft: A passkey protects authentication, but a stolen session cookie or active session may still allow access until the session is revoked or expires.
• Social engineering: Users can still be tricked into approving actions, revealing recovery codes, or granting access through a separate workflow.
• Account-provider lockout: Losing access to the account that synchronizes credentials can complicate access to those credentials, depending on the provider's recovery process.

It is also important to understand that the word "passkey" alone does not tell you whether a credential is hardware-backed, synchronized, or subject to a particular device policy. Those properties depend on the authenticator and implementation.

For organizations, the right choice may depend on the threat model. A consumer account, a corporate administrator account, and a high-security workstation may need different policies for device management, additional authentication, credential registration, and recovery.

9. A practical passkey setup checklist

Use this checklist when moving an important account to passkeys. The goal is to gain phishing resistance without accidentally creating a single point of failure.

Before enabling passkeys

• Confirm that the service supports passkeys on the devices and browsers you use.
• Read the service's official account-recovery instructions.
• Check whether the passkey will be synchronized or tied to a particular authenticator.
• Secure the account used by your credential manager with strong authentication and recovery settings.

After registering a passkey

• Verify that the passkey appears in the service's credential-management settings.
• Register a backup passkey or another supported authentication method where appropriate.
• Test sign-in from a second device if you expect to use one.
• Store recovery codes securely if the service provides them.
• Review passwords, email recovery, SMS, and other fallback methods.

When replacing or losing a device

• Confirm that you can access the account from another authorized device or credential.
• Use the official procedure to remove a lost device or revoke its sessions where appropriate.
• Register a replacement credential and test it before removing your last working authenticator.
• Review account activity if the device may have been stolen or compromised.

For high-value accounts, consider registering two independent authentication options rather than relying on a single phone or credential provider. The appropriate backup depends on the service's capabilities and your own security requirements.

10. What to watch for next

Passkey usability will continue to depend on improvements in credential management, cross-platform compatibility, recovery, and the way websites integrate authentication into their account settings.

Credential exchange standards may make it easier to transfer supported credentials between compatible providers. However, a published standard does not guarantee that every password manager or operating system supports every transfer workflow. Users should check current product documentation rather than assume universal portability.

Another important area is enterprise deployment. Organizations need ways to set authentication policies, manage employee access, handle device replacement, and respond when a credential or device is lost. Passkeys can strengthen enterprise authentication, but successful deployment still requires appropriate identity management and recovery procedures.

Services also need to make their authentication choices understandable. Clear explanations of passkey registration, backup credentials, recovery, and account security can prevent users from confusing a synchronized credential with an independent backup or assuming that a new device will automatically have access.

The broader direction is toward authentication that relies less on reusable passwords. The pace and details of adoption will vary by service and industry, so the most useful measure of progress is whether users can sign in securely, recover access predictably, and manage their credentials across the devices they actually own.

Conclusion

Passkeys offer a meaningful security improvement over conventional passwords, especially against phishing attacks that rely on tricking users into entering credentials on fraudulent websites. Their use of public-key cryptography reduces the need to transmit or repeatedly enter a reusable secret during authentication.

However, a good passkey setup involves more than registering one credential. Storage, synchronization, recovery, portability, and alternative sign-in methods all affect the practical security of an account. A passkey stored in a synchronized credential manager behaves differently from one tied to a physical security key, and neither approach removes the need for sensible recovery planning.

For important accounts, register passkeys where supported, protect the account that manages synchronized credentials, set up a backup authentication method, and understand how to recover access before you need it. Test the process when possible, and review the remaining fallback methods instead of assuming that adding a passkey automatically removes every weaker route into the account.

The best passkey strategy is one that combines phishing-resistant authentication with a recovery plan you understand and can actually use.

Further reading and official references

• FIDO Alliance: Passkeys — an introduction to passkeys and their security properties.
• W3C: Web Authentication (WebAuthn) — the technical specification for web-based public-key authentication.
• W3C: Credential Management Level 1 — background on browser credential-management interfaces.
• Google Account Help: Sign in with a passkey — information about passkey use with Google Accounts.
• Apple Support: About passkeys — information about passkeys and Apple's supported ecosystem.