---
url: 'https://www.corbado.com/kpi/passkey-usage-rate'
title: 'Passkey Usage Rate'
description: 'Measures the share of successful passkey logins from all successful logins, showing true preference and whether passkeys are the default path.'
lang: 'en'
keywords: 'Passkey Login Rate'
---

# 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](https://www.corbado.com/faq/are-passkeys-available). 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.

> **Key facts on Passkey Usage Rate**
> 
> - **What it captures**: The share of logins completed with passkeys based on all
>   successfull login attempts. It is often also called
>   [Passkey Login](https://www.corbado.com/blog/passkey-login-best-practices) Rate
> - **Primary use**: Validate that passkeys are the default, low friction choice in real
>   sign in behavior
> - **Interpretation**: Higher is better, the rate depends heavily on login flow design and
>   device / [passkey availability](https://www.corbado.com/faq/are-passkeys-available)

## 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](https://www.corbado.com/glossary/conditional-ui) automatically suggests
existing passkeys during login with minimal friction.
[Identifier-first flows](https://docs.corbado.com/passkey-ui-flows/web/passkey-login/identifier-first)
auto-trigger [passkey authentication](https://www.corbado.com/ko/blog/passkey-providers) after the user enters
their identifier when a passkey is available. A separate
[passkey button](https://www.corbado.com/blog/passkey-login-best-practices) requires the user to actively choose
it, which often results in lower usage. Features like
[One-Tap login](https://docs.corbado.com/corbado-connect/features/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.

> $$\text{PUR}=\frac{\text{Passkey Logins}}{\text{Total Logins}}$$

`Passkey Logins` counts completed logins where a passkey [assertion](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/conditional-ui),
      identifier-first auto-triggering and
      “[one-tap](https://docs.corbado.com/corbado-connect/features/one-tap-login)”
      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](https://www.corbado.com/faq/passkeys-reduce-password-resets-otp-costs).
    - Action: reduce
      [cross-device friction](https://www.corbado.com/blog/cda-friction-cxf-genai-phishing-authenticate-2025-trends)
      and prompt users to add a passkey on the current device after a successful
      non-[passkey login](https://www.corbado.com/blog/passkey-login-best-practices).

### Blindspots and common pitfalls of Passkey Usage Rate

- **Login flow conflation**: Comparing usage across different login approaches without
  segmentation is misleading. [Conditional UI](https://www.corbado.com/glossary/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.