Passkey Usage Rate

What is the Passkey Usage Rate?#

Passkey Usage Rate (PUR) (also often called Passkey Login Rate) measures users' preference to log in with passkeys, not the availability of passkeys. It tells us, based on all available authentication methods, how many of the successful logins were done using a passkey instead of another method. Passkey usage is where ROI and user experience show up. A system that generates passkey registrations but fails to see those passkeys used in everyday authentication falls short of delivering the promised security and convenience benefits.

Where does the Passkey Usage Rate fit in the login funnel?#

We measure Passkey Usage Rate at the moment of sign in. We consider only completed logins and we classify each completion by the method that actually authenticated the session.

The rate depends heavily on how passkeys are presented in the login flow. There are three main approaches: Conditional UI automatically suggests existing passkeys during login with minimal friction. Identifier-first flows auto-trigger passkey authentication after the user enters their identifier when a passkey is available. A separate passkey button requires the user to actively choose it, which often results in lower usage. Features like One-Tap login can significantly improve passkey usage by reducing friction and making passkeys the path of least resistance. For a comprehensive guide on optimizing login flows, see our passkey login best practices.

How to calculate the Passkey Usage Rate?#

The unit is a completed login attempt and we count each successful login completion once, assigning it to exactly one method based on the server side verification outcome.

Passkey Logins counts completed logins where a passkey assertion was verified and the session was established. Total Logins by Users with a Passkey counts all completed logins for users who had has_passkey=true at the time of the attempt, regardless of whether they used passkey, password, OTP or another method.

Numerator: Passkey Logins#

Count a login when the user completes authentication using a passkey and the backend verifies the assertion for that attempt. Do not count enrollments, prompts shown or failed passkey attempts that fall back to another method.

Denominator: Total Logins#

Count every completed login. Include completions that used non passkey methods, since those represent a choice or a constraint. Exclude incomplete attempts.

How to use Passkey Usage Rate to improve outcomes#

Passkey Usage Rate (PUR) answers:
How many of all logins are done with a passkey?

PUR is the “ROI metric” of passkeys: it reflects whether passkeys became the default, low-friction path in real sign-in behavior, not just something users enrolled once and then ignored.

What PUR helps you improve:

• More successful sign-ins

  • If enrollment is high but PUR is low, passkeys are usually not the default path (e.g. separate non-used buttons).
  • Action: make passkeys the primary UI path (Conditional UI or identifier-first auto-trigger) and keep fallback available but not dominant.

• Less drop-off during authentication

  • If users start a passkey flow but abandon it, friction is too high (e.g. extra taps, QR/cross-device hassles).
  • Action: reduce steps with Conditional UI, identifier-first auto-triggering and “one-tap” patterns where possible.

• Fewer support tickets

  • If users permanently revert to passwords after one bad passkey experience, the issue is usually error handling and recovery UX.
  • Action: improve error copy and recovery paths (e.g. biometric failed, cancelled, no passkey on device) without “training” users to always choose fallback.

• Lower OTP / reset costs

  • Higher PUR usually means fewer OTP sends and fewer password resets.
  • Action: reduce cross-device friction and prompt users to add a passkey on the current device after a successful non-passkey login.

Blindspots and common pitfalls of Passkey Usage Rate#

• Login flow conflation: Comparing usage across different login approaches without segmentation is misleading. Conditional UI and identifier-first flows perform very differently from separate passkey buttons.
• Availability versus preference: Low usage can mean the passkey was not available on that device, not that the user disliked passkeys. Cross device flows inherently have lower usage than same device flows.
• Passkey detection limits: The WebAuthn standard does not directly support passkey detection on the web, so auto-triggering passkey flows can cause frustration when the passkey is not accessible on the current device.