---
url: 'https://www.corbado.com/kpi/passkey-authentication-success-rate'
title: 'Passkey Authentication Success Rate'
description: 'Measures the share of passkey login attempts that reach an authenticated session, including user cancellations and technical failures.'
lang: 'en'
---

# Passkey Authentication Success Rate

## What is the Passkey Authentication Success Rate?

**Passkey Authentication Success Rate** measures how often passkey sign-ins succeed once a
user starts a passkey flow. We use it to validate that passkeys work reliably in real
conditions, across devices, platforms and user behavior.

> **Key facts on Passkey Authentication Success Rate**
> 
> - **What it captures**: Whether passkey attempts end in an authenticated session
> - **Primary use**: Find friction and reliability gaps specific to passkeys
> - **Interpretation**: Typical overall values are about **92% to 95%**, top implementations
>   reach **98% to 99%**, sustained values below **85% to 90%** usually require
>   investigation

## Where does the Passkey Authentication Success Rate fit in the login funnel?

We start counting when the user initiates a passkey flow and the client requests a passkey
credential. We stop counting when the session reaches the intended authenticated state or
the user exits the passkey flow. Measurement boundary: we only evaluate sessions where a
passkey attempt was started.

```mermaid
flowchart LR
  LP((Login page))
  SP((Start passkey authentication))
  UP((User verification: biometric or PIN))
  SV((Server verification))
  AS((Authenticated session))
  EX((Exit or cancel))

  LP --> SP --> UP --> SV --> AS
  UP -. cancel .-> EX
  SV -. error .-> EX
```

## How to calculate the Passkey Authentication Success Rate?

We calculate **Passkey Authentication Success Rate** at the login session level. We count
at most one started attempt and one outcome per session, even if the user retries within
the same session.

> $$\text{PASR}=\frac{\text{Passkey Auth Attempts succeeded}}{\text{Passkey Auth Attempts started}}$$

`Passkey Auth Attempts started` counts sessions where we invoked the passkey credential
request. `Passkey Auth Attempts Succeeded` counts sessions where server verification
completed and we issued an authenticated session.

### Numerator: Passkey Auth Attempts succeeded

Count a success when the user completes
[user verification](https://www.corbado.com/blog/webauthn-user-verification) and the server verifies the
response, then the user lands in the authenticated state.

Do not count sessions that end with user cancellation, timeouts, unsupported device errors
or a switch to a different sign in method after starting passkeys.

### Denominator: Passkey Auth Attempts started

Count a start when the user action and client code actually invoke the passkey flow, not
when we merely render a button or suggestion.

Do not count sessions where passkeys were never offered due to capability checks or where
the user chose another method without starting the passkey flow.

### How to use Passkey Authentication Success Rate to improve outcomes

We use **Passkey Authentication Success Rate** to target the specific step where passkeys
break, then fix that step and confirm the gain holds across segments.

We can improve the following business outcomes:

- **Higher successful sign ins**: If the KPI drops, we diagnose whether failures cluster
  in user cancellations or technical errors, we improve copy and capability checks, we
  validate via a stable lift in success across the same platforms.
- **Lower user drop off during authentication**: If cancellations rise, we diagnose
  unclear prompts or account selection confusion, we add clearer account naming and
  guidance, we validate by fewer cancels with unchanged traffic mix.
- **Lower support contacts**: If certain devices fail more, we diagnose OS or browser
  specific issues, we patch compatibility and error messaging, we validate with fewer
  repeated failures for the same device families.
- **Better operational cost**: If retries spike, we diagnose timeouts and flaky
  verification, we tune timeouts and retry handling, we validate with fewer repeated
  passkey starts per session and a higher success rate.

### Blindspots and common pitfalls of Passkey Authentication Success Rate

- **Intent and selection bias**: Early adopters and power users may use passkeys first,
  which can inflate results compared to broad rollout.
- **Missing telemetry**: If we fail to log `passkey_start` when the system UI opens, the
  denominator shrinks and the KPI looks artificially high.
- **Conditional UI tracking**: Tracking how many
  [conditional UI](https://www.corbado.com/glossary/conditional-ui) prompts have been offered is not natively
  supported by operating systems, but can be projected and calculated retrospectively with
  specialized methods.
- **Inconsistent logging**: If one platform logs cancel as failure and another drops the
  event, cross platform comparisons become misleading.
- **Mix shifts**: A change in traffic toward web cross device flows or older devices can
  lower the KPI even if nothing regressed.
- **Fallback masking**: If users start passkeys, fail, then succeed via another method,
  overall login outcomes look fine while passkey reliability is poor.