Passwords are no longer enough. WebAuthn and passkeys offer a modern, secure way to authenticate users without relying on shared secrets.
Implementing them correctly at scale requires understanding browser behavior, device compatibility, and lifecycle management. This guide breaks down the essentials and shows how to get started with Ory.
What are WebAuthn and Passkeys?
WebAuthn (W3C standard, built with FIDO2) allows browsers to handle public/private key credentials. The private key never leaves the device; the server stores only the public key. Authentication becomes a challenge-response operation, resistant to phishing and credential leaks.
Passkeys are the user-friendly, discoverable layer on top of WebAuthn. They enable cross-device login (via iCloud, Google, etc), biometric login (Face ID, Windows Hello), and a passwordless experience.
Key distinction:
- WebAuthn = protocol & API. If you see “WebAuthn” in developer docs, you’re dealing with the raw standard, registration/login ceremonies, public/private key flows.
- Passkeys = UX-focused implementation of WebAuthn. If you see “passkeys” in product or marketing contexts you’re dealing with credentials built on WebAuthn, focusing on user experience and device sync, etc.
What is WebAuthn?
The Web Authentication (WebAuthn) API is a specification published by the World Wide Web Consortium (W3C), developed in conjunction with the FIDO Alliance, that enables a web application (the relying party) and a browser (the client) to use public-key cryptography for authentication rather than passwords.
WebAuthn works only in secure contexts, such as HTTPS origins, with certain exceptions for localhost during development. Browser and platform support is mature, with all major browsers — Chrome, Firefox, Edge, and Safari — providing full WebAuthn functionality.
In practical terms:
- A user’s device (via a browser) uses an authenticator (hardware token, built-in biometric/TPM) to generate a key‐pair: private key stays on device, public key is registered with the server.
- During login, the server issues a challenge, the device signs it with the private key; because the credential is scoped to the origin (domain) and bound to the authenticator, it provides phishing-resistance.
- It supports both single-factor (passwordless) and multi-factor flows.
What are Passkeys?
The term “passkeys” is more of a user-friendly branding of credentials built on top of WebAuthn. According to the FIDO Alliance, a Passkey is “a password replacement that provides faster, easier, and more secure sign-ins to websites and apps across a user’s devices.”
What distinguishes passkeys:
- They use WebAuthn under the hood (i.e., public key credentials) but are optimized for the user experience: e.g., device-synchronised credentials (via cloud keychain or OS sync) so the user can sign in across multiple devices.
- They are often resident credentials (keys stored on device or sync service), enabling a “one-tap” experience (e.g., FaceID/TouchID, Windows Hello) rather than asking user to explicitly register a security token.
What developers and IAM builders struggle with
Even though passkeys and WebAuthn promise a lot (phishing-resistance, passwordless UX, fewer account take-overs), in practice there are significant implementation and lifecycle challenges. Below are some of the key pain-points from the industry.
1. Account recovery, fallback and user-lockout concerns
One of the largest obstacles reported by enterprises is how to recover or reset passkey-based credentials when a user loses access (device lost, credential removed, device replaced). A recent study found account recovery as a top barrier for FIDO2 deployment in enterprises.
Developers worry if a user only has a passkey registered on one device and that device fails — how do they safely get back in? Without a strong fallback plan you risk lock-outs and support load.
2. UX variation across devices, platforms and browsers
While modern browsers support WebAuthn, there are subtle differences in behaviour, device support, cross-device flows (e.g., scanning QR codes to approve login from phone to desktop), and other quirks.
For example:
- Some devices don’t sync passkeys across platforms, so a “passkey on iPhone” might not work on Windows desktop.
- Detecting whether passkeys are available on the device before starting the login flow is non-trivial. Many devs assume they can check “navigator.credentials” and know if passkeys exist; in reality this may lead to errors or unexpected flows.
3. Migration from legacy authentication or hybrid flows
Many organizations have existing username/password, OTP, social login, SSO flows. Deploying passkeys means either phasing out legacy flows or running a hybrid state. That raises issues such as user education, fallback flows, analytics/KPIs, migration strategy.
4. Domain/Relying-Party ID changes & credential breakage
Because WebAuthn credentials are bound to a specific relying party ID (often domain) and origin, if you change your domain, subdomain, or mis-configure the RP ID/origins you can inadvertently break existing credentials. For example, Ory doc calls out this exact risk.
5. Device/device-authenticator management and “zombie” credentials
There is a risk of accumulating credentials tied to devices that are no longer valid (old device thrown away, passkey removed but server still sees it). These “zombie passkeys” can degrade UX and raise support burden.
6. Compliance/regulatory and enterprise context constraints
In enterprise or regulated sectors (finance, banking, healthcare) there may be legacy systems, onboarding rules, identity proofing, SCA/PSD2 requirements that complicate a pure passkey rollout.
Using Ory for WebAuthn and Passkeys
Implementing passwordless login with WebAuthn can be powerful, but it often leaves developers wrestling with subtle UX issues. Ory Network addresses this with a dedicated passkey strategy, designed specifically to make first-factor authentication smoother and more intuitive for users.
Instead of relying solely on the standard WebAuthn strategy, which has limitations in discoverability and conditional UI, the passkey strategy optimizes the login experience while still adhering to the same underlying FIDO2 standards.
Here’s a quick comparison of the two approaches:
| WebAuthn passwordless login | Passkey strategy |
|---|
| Discoverable credentials: The browser automatically discovers which credentials the user has stored for the site. | ❌ | ✅ |
| Conditional UI: The browser attaches an autofill dropdown to the email field that allows the user to select a passkey. | ❌ | ✅ |
| Backwards compatibility: Works for users that have a passkey configured with the WebAuthn strategy. | ✅ | ❌ |
For details on setting this up via Ory Network (managed), or self-hosted with Ory Kratos see our documentation on Passkeys & WebAuthn.
Key considerations before launch
Implementing passkeys and WebAuthn is straightforward in theory, but real-world constraints can impact both functionality and user experience. Before rolling out, keep the following in mind:
- Stable RP ID / Origin: WebAuthn binds credentials to a single origin (the HTTPS URL). Changing your domain later, or using CNAMEs can break existing credentials. Plan your domain strategy carefully.
- Fallback flows: Not all devices or browsers support passkeys. Always provide backup options such as email OTP or legacy password login.
- Cross-device/browser testing: Test login flows across desktops, mobiles, and multiple operating systems to catch platform-specific quirks.
- Lifecycle management: Prepare processes for credential removal, lost devices, account recovery, and audit logging.
- User education: Train users on enrolling, using, and managing passkeys, particularly if they’re accustomed to password-based logins.
- Monitoring & metrics: Track support requests, login failures, and key UX indicators like conversion and login success rates.
- Native app constraints: WebAuthn is a browser standard. It does not natively work in mobile apps without a compatible framework or wrapper.
- UI complexity: Implementing WebAuthn in your own interface can be challenging depending on your tech stack. Reference implementations exist for React Native, Node.js, and React/SPA.
By addressing these constraints early, you ensure a smoother launch and reduce the likelihood of broken credentials or frustrated users.
Key takeaway
Deploying passkeys via Ory (in the network-hosted or self-hosted model) offers a standards-based, secure path to passwordless authentication. That said, the real complexity lies beyond the technical API: in user experience, fallback/rescue flows, lifecycle management, device diversity, domain stability, and enterprise integration. Treat passkeys not just as a feature, but as a shift in authentication architecture and operational practice.
Don’t risk broken credentials or security gaps in your passwordless rollout. Talk to our experts today to implement passkeys securely and at scale
