Passkey Login: Conditional UI

The Conditional UI flow starts without the user entering their username first. This is a usernameless login flow. The platform may offer an eligible subset of credentials selected by the operating system and active providers, for example through iOS QuickType or Android inline or drop-down suggestions. The account is resolved from the selected credential and verified assertion.

Platform support (August 2026): iOS and iPadOS 16+ via performAutoFillAssistedRequests() (not available to native macOS apps), and Android 15+ via PendingGetCredentialRequest in androidx.credentials 1.5.0+, which surfaces credentials in keyboard inline and drop-down suggestions. The Android implementation is currently View-based only, so Compose UIs are not yet covered: the screens below show the iOS experience.

Account resolution: The app does not know which user is signing in until the user selects a passkey. The operating system and active credential providers decide which eligible credentials appear in the suggestion surface.

Product-Native Steps: The blue background indicates optional product-native steps (e.g., verification code, setup PIN, enabling biometrics). PIN and local biometrics are optional features for protecting app access within sessions after passkey authentication completes. Learn more about how passkeys and local biometrics work together to provide both secure remote authentication (passkeys) and convenient app protection (local biometrics).

Conditional UI automatically triggered

When the user taps the email field, the platform may offer eligible credentials through its suggestion surface.
This is usernameless. The app does not yet know which account is signing in.

Authenticate using the selected passkey

The user taps their passkey from the available options on the keyboard, which identifies them to the system.
Upon selection, the system now knows which user account is attempting to authenticate.

Authorize credential and verify assertion

The platform returns an assertion after authorization with a supported device-unlock method.
The app sends the assertion to the relying party, and the user is signed in only after server verification succeeds.

App PIN setup

After successful passkey authentication, the user is signed in and is asked to set up PIN.

Enable local biometric for app login

User is allowed to enable/disable local biometric app login (provided as product feature).

The server still decides whether login succeeds. An active provider may surface an eligible credential the server no longer accepts, so device authorization does not guarantee login. Supported WebAuthn Signal API reconciliation can reduce this mismatch but cannot prove what a provider stores or changes.

Acceptance criteria

Benchmark as	User reach
Enhancement	Mid

Platform-dependent: Assess this enhancement only where the operating system, credential service and app UI technology support field-linked credential suggestions. Current Android guidance documents this experience for Android 15+ and View objects; implementations using other UI technologies should be assessed against the current platform capability rather than assumed to qualify.

ID	Level	Acceptance criterion	How to verify
N1.2-AC01	Core	On a supported surface, focusing the configured sign-in field allows the operating system to offer a matching passkey through its credential suggestions.	On iOS, focus an appropriately annotated field with an assisted authorization request active. On supported Android targets, focus a field linked to the credential request. Confirm that an available passkey can be selected from the OS-provided suggestion UI.
N1.2-AC02	Core	The assisted request is ready before the user can interact with the field, so the first focus does not miss credential suggestions because initialization is late.	Delay the challenge and request setup, then try to use the field as soon as the screen opens. Repeat from several cold starts and confirm that the request is ready before the field can be used.
N1.2-AC03	Core	A pending assisted request cannot alter authentication state after its login screen is no longer current.	Start another authentication route, submit the identifier, navigate away and complete fallback login while the assisted request is pending. Confirm that a late response cannot change the resulting account or session.
N1.2-AC04	Core	The app does not render or infer its own list of credentials stored on the device.	Compare first-party UI before and after field focus. Confirm that credential identities are presented only by the operating-system credential service.
N1.2-AC05	Core	An unsupported environment or a field with no matching credential does not display an empty passkey error owned by the app.	Exercise every unsupported target in scope and a supported target without a matching passkey. Confirm that the app remains on its ordinary sign-in surface without a passkey failure message.

References

Relevant criteria: N1.2-AC01–AC02 and N1.2-AC04–AC05: Apple: Supporting passkeys and Android: Integrate Credential Manager with autofill cover field-linked suggestions, provider-controlled presentation and Android’s current View applicability boundary.
Relevant criteria: N1.2-AC02–AC03: Apple: AutoFill-assisted authorization requests and Android: PendingGetCredentialRequest cover assisted-request lifecycle and Android’s success-only pending callback.

​Conditional UI Flow (Usernameless Login)

​Acceptance criteria

​References

Conditional UI Flow (Usernameless Login)

Acceptance criteria

References