Passkeys for Web Apps: How Passwordless Sign-In Works
Understand how passkeys work and what product teams should plan before adding passwordless sign-in.
Passwords create work for users and risk for businesses. Passkeys replace the shared password with a cryptographic credential tied to a website or app. The sign-in can feel like unlocking a device, but a sound rollout still needs careful account recovery and support planning.
Key takeaways
- A passkey uses a public and private key pair; the website stores the public key.
- The credential is bound to the site, making common phishing flows harder.
- Plan registration, cross-device sign-in, and recovery as one user journey.
How a passkey signs a user in
When a user creates a passkey, their device or passkey provider creates a key pair. The private key remains with that provider, while the website stores the public key. At sign-in, the server sends a fresh challenge. The authenticator signs it after the user unlocks their device, and the server verifies the response.
The FIDO Alliance passkeys guide explains this public-key design and the familiar biometric, PIN, or pattern experience. Google’s server authentication guide details checks such as challenge, origin, relying-party ID, and signature verification. A site should use a maintained WebAuthn library rather than hand-building those checks.
Registration happens before sign-in
At registration, a user chooses to create a passkey for a particular website or app. Their authenticator or passkey provider creates a public and private key pair. The site receives and stores the public key and information needed to identify the credential. The private key is not sent to the site. The FIDO Alliance explains this public-key approach and why it removes the shared password from the sign-in exchange.
A product should let people understand which account they are securing, name or manage their passkeys, and add another credential when appropriate. Registration is part of the account journey, so it should be designed alongside device changes and support. The visual below separates what the provider keeps from what the site stores.
What the server must verify
For sign-in, the server issues a fresh, unpredictable challenge. The browser asks the authenticator to sign it, and the server checks the response against the stored public key. According to Google’s server-side guide, verification includes the challenge, origin, relying-party ID, signature, and applicable user-verification requirements. A challenge must not be reused; its purpose is to prevent a captured response from being replayed later.
These checks belong on the server. A visually convincing device prompt or a successful browser API call alone does not establish an authenticated session. Use a maintained WebAuthn library, keep challenge state for the attempt, reject mismatches, and create a session only after verification succeeds.
Why passkeys resist phishing
A password can be typed into a lookalike site. A passkey is associated with the legitimate website or application identity, so the browser and authenticator do not offer the same credential to an unrelated origin. The server also avoids storing a reusable password secret. These are properties of the protocol, not a guarantee that every account risk disappears.
Account recovery is still important. If an attacker can bypass passkey sign-in through a weak recovery process, the overall account remains vulnerable. Review recovery, device loss, support scripts, and high-risk account changes along with the sign-in screen.
Synced and cross-device experiences
Some passkeys can sync through a provider to a user’s other devices. A person may also sign in on a device that does not hold their passkey by using a cross-device flow. These paths make sign-in convenient, but they depend on the person’s device, provider, browser, and account setup. Google’s passkey use-case guidance describes autofill and cross-device sign-in journeys.
Show clear instructions when the browser opens a passkey picker or a phone handoff. Avoid implying that the website reads fingerprints: local device unlock verifies the user to the authenticator, while the website receives a cryptographic response. Keep a working route for people who cannot use their passkey in the moment.
How to introduce passkeys in an existing app
Begin by offering passkey creation after a successful sign-in, then make the next sign-in easy to discover. During a transition, some users will still need their password or another existing method. Google’s passkey use-case guidance describes autofill and cross-device flows that help mixed user groups.
Explain what the user will see before the operating-system prompt appears. Make it clear that the website does not receive their fingerprint or face scan. Provide a way to manage registered passkeys and show a safe recovery route. Product teams should review the journey on the devices and browsers their customers actually use.
Make recovery as strong as sign-in
Account recovery is often the hardest product decision. If a lost device can be bypassed with a weak email or support process, the passkey’s phishing resistance does not protect that recovery route. Decide which evidence is required to restore access, how quickly risky changes become active, and how users are notified. Give support staff a defined process instead of an improvised exception.
During migration, measure registration completion, passkey sign-in success, fallback use, and support requests. Let existing users add a passkey after a trusted sign-in, then make passkey sign-in easy to choose next time. Keep credential management visible so users can remove an old device or add a new one without contacting support for routine changes.
A short implementation checklist
- Choose a maintained WebAuthn server library and define your relying-party domain.
- Design registration, sign-in, credential management, and recovery together.
- Verify challenges, origins, signatures, and required user-verification flags server-side.
- Measure sign-in completion and support issues before changing the default flow.
Passkeys fit naturally into a broader app development or web-platform project when security and ease of use matter from the start.
Common questions
Does a website receive a user’s fingerprint?
No. The biometric or device unlock happens locally. The website receives a cryptographic authentication response, not the biometric material.
What if a user changes devices?
Some passkeys can sync through a passkey provider, and cross-device sign-in is also possible. Your product still needs a clear recovery and credential-management flow.
Sources and further reading
Facts were checked against the following primary or official technical sources. Reviewed 30 September 2026.