What is the difference between synced and device-bound passkeys?

Synced passkeys are backed up and shared across a user's devices by their platform account, such as Apple, Google or a password manager, which makes recovery easier. Device-bound passkeys stay on one device or security key, which some high-assurance environments prefer.

Should passkeys replace passwords immediately?

Usually not. Most services add passkeys as an option, encourage users to create one after signing in, and keep other methods during transition. Over time, some remove passwords for users who have passkeys.

How should account recovery work?

Recovery is often the weakest point. Encourage users to have more than one passkey or synced passkeys, offer secure fallback methods appropriate to the risk, and add verification and notification for recovery actions. Do not let recovery undo the phishing resistance you gained.

Is the WebAuthn standard stable?

Yes. Web Authentication Level 3 became a W3C Recommendation in August 2026, and browser and platform support for passkeys is broad. Check specific features, such as autofill sign-in, on the devices your users have.

Web Development4 min read

Adding Passkeys to a Web or Mobile App: UX, Recovery and Security Trade-Offs

How to add passkeys to a web or mobile app: how they work, synced vs device-bound, sign-up and sign-in UX, account recovery, server implementation and rollout.

How do you add passkeys to an app?

Add passkeys as a sign-in option using a maintained WebAuthn library on the server and the platform credential APIs in your apps; prompt users to create a passkey after they sign in, support autofill sign-in, let users manage several passkeys, design account recovery carefully, keep existing methods during transition, and measure adoption and sign-in success. Passkeys reduce phishing and password reuse, but recovery and support need as much design as sign-in.

This guide is for product managers, designers and engineers. The standard is Web Authentication Level 3, now a W3C Recommendation; passkeys.dev collects implementation guidance.

Key takeaways

Passkeys are phishing-resistant public-key credentials.
Use maintained libraries; do not implement the cryptography yourself.
Offer creation after sign-in; support autofill sign-in.
Allow several passkeys per account and easy management.
Recovery design determines real security.
Measure adoption, success rates and support contacts.

How passkeys work

Step	What happens
Registration	The device creates a key pair for your site or app; the public key and a credential ID are sent to your server
Sign-in	Your server sends a challenge; the device signs it with the private key after the user unlocks it
Verification	Your server checks the signature with the stored public key
Binding	Credentials only work for your domain or associated app, which blocks phishing sites

UX patterns

Prompt to create a passkey after a successful sign-in or at sign-up, explaining the benefit simply.
Support autofill (conditional) sign-in so passkeys appear in the username field.
Show passkeys in account settings with names and last-used dates; allow removal.
Keep wording consistent: 'passkey', not technical terms.
Offer fallback sign-in methods during the transition.

Mobile and web implementation

On the web, use the WebAuthn browser API through a well-maintained library on both client and server. On iOS and Android, use the platform credential APIs and associate your app with your domain so the same passkeys work in the app and on the website. Store public keys, credential IDs, sign counters where relevant and metadata; never store anything that lets you sign on the user's behalf. See mobile app authentication.

Recovery and risk

Decide recovery by risk. Consumer apps often rely on synced passkeys plus verified email or phone recovery with extra checks and notifications. Financial or high-risk services may require identity verification before recovery. Whatever you choose, attackers will target recovery, so rate-limit it, notify users and review it in your threat model.

Hypothetical example: a subscription app

This example is hypothetical. A subscription app with frequent password reset requests added passkeys. After sign-in, users were offered a passkey; returning users saw passkeys in autofill. The account page listed passkeys by device. Recovery used email with a delay and notification for accounts with no passkey on a second device. The team tracked passkey adoption, sign-in success rates and password reset tickets each month.

Common mistakes

Removing passwords before most users have passkeys.
Weak recovery that bypasses the passkey.
Only one passkey allowed per account.
App and website not associated, so passkeys do not work across them.
Confusing technical wording in prompts.

Enterprise SSO implementation for workforce sign-in.
Mobile app security for device-side protections.
OAuth vs OpenID Connect for tokens after sign-in.
Website security in Australia for broader practice.

Conclusion

Passkeys offer phishing-resistant, easier sign-in. Implement them with maintained libraries, introduce them gradually, support several passkeys and autofill, design recovery with the same care as sign-in, and measure the results. For recovery across all sign-in methods, see secure account recovery.

Adding passkeys to your product?

ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web applications and mobile apps, including authentication. If it would help to plan a passkey rollout, we are happy to talk it through.

Start a Project

FAQ

Common questions.

A passkey is a sign-in credential based on public-key cryptography (the FIDO and WebAuthn standards). The private key stays on the user's device or in their platform's password manager and is unlocked with a fingerprint, face or device PIN; the service stores only the public key. Because the credential is bound to the website or app, passkeys resist phishing.