---
url: 'https://www.corbado.com/kpi/time-to-authenticate'
title: 'Time to Authenticate'
description: 'Time to Authenticate measures how long a login takes from starting the auth flow to reaching the authenticated state.'
lang: 'en'
---

# Time to Authenticate

## What is the Time to Authenticate?

**Time to Authenticate** measures the total time a person experiences during login from
initiating the authentication flow to reaching the intended authenticated state. We use it
to quantify login speed, identify friction and protect conversion and productivity when
authentication changes.

> **Key facts on Time to Authenticate**
> 
> - **What it captures**: Elapsed time from starting authentication to authenticated access
> - **Primary use**: Reduce [login friction](https://www.corbado.com/blog/login-friction-kills-conversion) while
>   keeping the flow reliable
> - **Interpretation**: Lower is better, [watch](https://www.corbado.com/blog/how-to-use-passkeys-apple-watch)
>   median and tail latency, values over 20 seconds often feel slow

## Where does the Time to Authenticate fit in the login funnel?

We start timing when the user initiates the login flow, and we stop timing when the user
reaches authenticated content. Measurement boundary sentence: we include user input time,
redirects and all server round trips until the authenticated state is reached.

```mermaid
flowchart LR
    OA(("Offer<br/>Auth"))
    OM(("Offer<br/>Method"))
    SM(("Start<br/>Method"))
    SuM(("Success<br/>Method"))
    SuA(("Success<br/>Auth"))

    OA --> OM --> SM --> SuM --> SuA

    OA -. "ENGAGEMENT RATE" .-> SM
    OM -. "METHOD CONVERSION" .-> SM
    SM -. "METHOD SUCCESS RATE" .-> SuM
    SM -. "AUTH SUCCESS RATE" .-> SuA
```

## How to calculate the Time to Authenticate?

We compute **Time to Authenticate** once per authentication attempt. If a user retries
within the same session, each retry is a separate attempt, because it represents new
friction.

> $$\text{TTA}=\text{Auth completed Timestamp}-\text{Auth started Timestamp}$$

- `Auth started Timestamp` is when the user clicks sign in, opens the login screen or
  triggers an authentication prompt.
- `Auth completed Timestamp` is when the app confirms an authenticated session and the
  user can access protected content.

A practical way to report is to show median time and a tail metric such as p95, since a
small set of very slow attempts drives frustration.

### How to use Time to Authenticate to improve outcomes

We use **Time to Authenticate** to target specific sources of friction and verify that
changes reduce real user time, not just server latency.

We can improve the following business outcomes:

- **Higher successful sign ins that reach the intended authenticated state** Diagnose
  which methods or platforms have the slowest median. Change the default method order and
  reduce step count. Validate by a sustained median drop without an increase in retries.
- **Lower user drop off during authentication** Diagnose long tails that correlate with
  extra steps like one time codes. Change the flow to reduce manual entry and reduce
  redirects. Validate by a p95 drop and fewer abandoned attempts.
- **Lower support contacts caused by authentication issues** Diagnose spikes where time
  grows alongside verification errors or delivery delays. Change messaging, timeouts, and
  recovery UX. Validate by fewer long attempts and fewer repeated starts.
- **Better operational cost through fewer retries and fewer challenges** Diagnose flows
  where time is dominated by waiting or repeated prompts. Change rate limits, challenge
  policy, and caching. Validate by fewer attempts per successful session and lower p95.

### Blindspots and common pitfalls of Time to Authenticate

- **Intent and selection bias**: users who choose a slower method can make overall time
  look worse even if the main method improved.
- **Missing telemetry**: inconsistent start or completion events will undercount long
  attempts, especially when users close the app or lose connectivity.
- **Mix shifts across segments**: changes in platform mix, network quality, or new user
  share can move the metric without any product change.
- **Timer boundary drift**: starting the timer before the login UI is interactive or
  stopping it before the authenticated page renders can hide real friction.