Passkey Usage Rate

Passkey Usage Rate (PUR) measures preference, not availability. It tells us, when a user already has at least one passkey enrolled, what share of their successful logins use a passkey instead of another method. It matters because usage is where ROI and user experience show up, users who do not choose passkeys will keep generating password resets, retries, and drop off.

We measure Passkey Usage Rate only for users who are passkey eligible at the moment of sign in, meaning they have at least one passkey enrolled for the account. The start is a successful login completion and the end is the method used for that completed login. Measurement boundary: we include only completed logins from passkey eligible users and we classify each completion by the method that actually authenticated the session.

flowchart LR
    LS((Login
    Started)) --> EL((Eligible
    has Passkey))

    EL --> PK((Complete Login
    With Passkey)) --> SU((Authenticated
    Success))
    EL --> OM((Complete Login
    with other Method)) --> SU

    EL -. "PASSKEY USAGE RATE" .-> PK

Get the Authentication Analytics Whitepaper

Analyze your Authentication Performance with Real Numbers

10 KPIs that connect authentication performance to revenue. Track adoption, friction & conversion impact.

Download the Authentication Analytics Whitepaper

Work email *

Name *

Company *

Job title *

Get Whitepaper

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.

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.

Count every completed login by users who already had at least one passkey at attempt time. Include completions that used non passkey methods, since those represent a choice or a constraint. Exclude users without a passkey, and exclude incomplete attempts.

We use Passkey Usage Rate to make passkeys the easiest path for eligible users, without breaking fallback.

We can improve the following business outcomes:

• Higher successful sign ins that reach the intended authenticated state, we diagnose hidden or confusing entry points, we move passkey to the default UI and keep fallback behind an option, we validate by seeing usage rise while overall success stays stable
• Lower user drop off during authentication, we diagnose extra steps such as explicit buttons or repeated account selection, we reduce taps with conditional UI and better prefill, we validate with fewer retries per user and higher usage
• Lower support contacts caused by sign in issues, we diagnose users reverting to passwords after errors, we improve error messages and recovery paths when biometrics fail, we validate by fewer password resets and higher usage among tenured users
• Better operational cost through fewer retries, we diagnose cross device QR friction, we prompt adding passkeys on the current device after successful sign in, we validate by higher same device usage and fewer cross device attempts

• Selection bias and intent: The metric only reflects behavior of users who already enrolled, so improvements can be driven by who enrolls rather than better UX
• Missing or inconsistent logging: If has_passkey is computed differently across clients, or method classification is client reported, usage can be inflated or under counted
• Mix shifts across segments: A shift toward desktop, cross device sign ins, or third party browsers can lower usage even if the experience did not regress
• Availability versus preference: Low usage can mean the passkey was not available on that device, not that the user disliked passkeys

At minimum, report Passkey Usage Rate by platform, browser, sign in entry point type such as conditional UI versus explicit button and passkey tenure such as first 30 days versus 90 plus days. Add a cross device flag to separate preference from availability constraints.