Passkey UI Flow Catalogue

All 28 flows, grouped by the three phases of the passkey lifecycle. This is a reference, not something you are meant to read top to bottom. Use the Benchmark as class to see which flows are expected of every implementation and which apply only in their documented scenario. User reach estimates how much of the user base a flow touches. It is an estimate for planning, never a score to add up. Each flow’s platform requirements and benchmark class are in the availability matrix at the bottom of this page.

Benchmark as: how strictly a flow is judged

Value	Meaning
Baseline	Expected production behavior whenever passkeys are in scope.
Strategy	One primary UX pattern that can coexist with or substitute for another strategy. Do not require every alternative.
Conditional	Required only when its documented scenario occurs in the declared scope.
Enhancement	Progressive capability that improves the flow where supported; unsupported targets are not penalized.
Supporting capability	Non-UI behavior that improves several flows.

User reach: how much of the user base a flow touches

Value	Meaning
High	Directly affects a frequent, broad creation or returning-login opportunity.
Mid	Expands device coverage, recovery or another important part of the user base.
Low	Primarily improves lifecycle hygiene, trust or administration rather than direct funnel exposure.

This is a qualitative estimate for the full audience. It is not a measure of overall importance, it does not affect whether a criterion passes and the labels must never be added together as a score. Credential management and Signal API reconciliation have low user reach but high reliability and lifecycle value.

Availability: where the flow can work at all

Value	Meaning
Universal	Works on every modern browser or on iOS 16+ / Android 9+ with a supporting credential provider.
Limited	Depends on recent browser, OS or provider versions. Feature-detect and degrade gracefully.
Desktop only	Applies to the desktop context by definition.

Exact version requirements are listed on each flow page and in the availability matrix.

How the flows are numbered

Every flow carries a stable ID. Use it when scoping an implementation, comparing platforms or filing tickets.

Part	Values	Example
Platform	`W` web, `N` native, `E` platform-independent	W2.3
Phase	`1` login, `2` creation, `3` management	W2.3
Flow	Appended in order, so existing IDs never shift	W2.3

Individual acceptance criteria extend the ID, for example W1.1-AC03. The phase digit follows the ID scheme, not the order you build in: creation is 2 but comes first in the lifecycle. Getting a returning user in with a passkey they already have.

ID	Flow	When it applies	Reach
W1.1	One-Tap	A returning user should see a single, explicit passkey button	High
W1.2	Conditional UI	You want usernameless login offered inside the identifier field	High
W1.3	Identifier-first	You already run an identifier-first login form	High
W1.4	Cross-device via QR	The user’s passkey lives on their phone	Mid
W1.5	Login error states	You are designing failure handling and fallback	Mid
W1.6	Immediate mode	A client has an immediately available credential and should offer a faster login	Mid

ID	Flow	When it applies	Reach
N1.1	App-start overlay	The app should offer a passkey before the user types anything	High
N1.2	Conditional UI	You want passkeys suggested from the keyboard	Mid
N1.3	Identifier-first	The app collects an identifier before authenticating	High
N1.4	Login error states	You need recoverable, platform-aware failure handling	Mid

2. Passkey creation

Getting a passkey onto the user’s device in the first place. This is where adoption is won or lost.

Creation on the web

ID	Flow	When it applies	Reach
W2.1	Automatic upgrade (conditional create)	A password was just filled by the user’s credential manager	Mid
W2.2	After login, non-MFA (post-login nudge)	A single-factor account should be offered a passkey after login	High
W2.3	After login, MFA (post-login nudge)	An MFA account should be offered a passkey after verification	High
W2.4	After hybrid login	The user just signed in by scanning a QR code	Mid
W2.5	After passkey error	A passkey attempt failed and verified fallback creates another usable credential	Mid
W2.6	On 2nd device	The account’s passkeys were created before this device was first seen	Mid
W2.7	During sign-up	A new account should create a passkey during registration	Mid
W2.8	Creation cancellation	An explicit creation offer can be skipped or its system ceremony cancelled	Mid

Creation in native apps

ID	Flow	When it applies	Reach
N2.1	After login, non-MFA (post-login nudge)	A single-factor account should be offered a passkey after login	High
N2.2	After login, MFA (post-login nudge)	An MFA account should be offered a passkey after verification	High
N2.3	After passkey error	A failed passkey attempt is followed by verified fallback and another usable credential	Mid
N2.4	In-app nudge after unlock	Long-lived sessions make post-login enrollment rare	Mid
N2.5	In-app nudge on key action	A relevant completed action provides a less disruptive time for enrollment	Mid
N2.6	Automatic upgrade (conditional create)	A password was just filled by the user’s credential manager in your app	Mid

3. Passkey management

Letting users and your server keep the set of credentials correct over time.

Management on the web

ID	Flow	When it applies	Reach
W3.1	Passkey management	Users need to list, add and revoke their own passkeys	Low
W3.2	WebAuthn Signal API	Keeping the credential manager in sync with what your server accepts	Low

Management in native apps

ID	Flow	When it applies	Reach
N3.1	Passkey management	Users need to list, add and revoke their own passkeys	Low
N3.2	WebAuthn Signal API	Keeping the credential manager in sync with what your server accepts	Low

Passkey Intelligence

Not a UI flow. It decides whether one of the flows above should run. The benchmark checks the resulting behavior and does not require a proprietary engine.

ID	Capability	What it decides	Reach
E1	Passkey Intelligence	Whether to attempt, offer, defer or fall back from a passkey flow in the current context	High

Availability matrix

Platform requirements and benchmark class for every flow

ID	Availability	Benchmark as	Exact requirements
W1.1	Universal	Strategy	All modern browsers
W1.2	Universal	Enhancement	All modern browsers
W1.3	Universal	Strategy	All modern browsers
W1.4	Desktop only	Conditional	Desktop; needs Bluetooth and internet
W1.5	Universal	Baseline	All
W1.6	Limited	Enhancement	Chrome only; feature-detect `immediateGet`
W2.1	Limited	Enhancement	Chrome 136+ desktop / 142+ Android; Safari 18+ macOS / iOS 18+
W2.2	Universal	Strategy	All modern browsers
W2.3	Universal	Strategy	All modern browsers
W2.4	Desktop only	Conditional	Desktop
W2.5	Universal	Conditional	All modern browsers
W2.6	Universal	Conditional	All modern browsers
W2.7	Universal	Strategy	All modern browsers
W2.8	Universal	Baseline	All modern browsers
W3.1	Universal	Baseline	All modern browsers
W3.2	Limited	Supporting capability	Chrome/Edge 132+ desktop; Chrome 144+ Android; Safari 26+
N1.1	Universal	Strategy	iOS 16+, Android 9+ with a supporting Credential Manager/provider
N1.2	Limited	Enhancement	iOS 16+, Android 15+
N1.3	Universal	Strategy	iOS 16+, Android 9+ with a supporting Credential Manager/provider
N1.4	Universal	Baseline	iOS 16+, Android 9+ for passkey paths
N2.1	Universal	Strategy	iOS 16+, Android 9+
N2.2	Universal	Strategy	iOS 16+, Android 9+
N2.3	Universal	Conditional	iOS 16+, Android 9+
N2.4	Universal	Strategy	iOS 16+, Android 9+
N2.5	Universal	Strategy	iOS 16+, Android 9+
N2.6	Limited	Enhancement	iOS 18+; Android 9+ with `androidx.credentials` 1.6.0 and a supporting provider
N3.1	Universal	Baseline	iOS, Android
N3.2	Limited	Supporting capability	Android 15+; Apple 26.0+ with legacy `ASCredentialUpdater` on 26.0–26.1 and current `ASCredentialDataManager` on 26.2+
E1	Universal	Supporting capability	Platform-independent

Using this catalogue

For implementation reviews: Declare the target platforms and account policies first, then assess only the applicable strategies and conditional flows with the benchmarking method. Do not use a raw percentage of checked rows. For Corbado Connect users: Map the configured product capabilities to the same acceptance criteria and attach implementation or production evidence. Product availability alone is not evidence that a deployed flow passes. For custom implementations: Use the criteria as outcome requirements. They deliberately avoid prescribing a specific SDK, identity provider or internal architecture.

Want the full Figma board with all flows for your design team? Email contact@corbado.com to request access.

Overview

Web

Native

Passkey UI Flow Catalogue

How the flows are numbered

2. Passkey creation

Creation on the web

Creation in native apps

3. Passkey management

Management on the web

Management in native apps

Passkey Intelligence

Availability matrix

Using this catalogue

​How the flows are numbered

​1. Passkey login

​Login on the web

​Login in native apps

​2. Passkey creation

​Creation on the web

​Creation in native apps

​3. Passkey management

​Management on the web

​Management in native apps

​Passkey Intelligence

​Availability matrix

​Using this catalogue

How the flows are numbered

1. Passkey login

Login on the web

Login in native apps

2. Passkey creation

Creation on the web

Creation in native apps

3. Passkey management

Management on the web

Management in native apps

Passkey Intelligence

Availability matrix

Using this catalogue