Passkey Management - Corbado docs

Create, manage or delete Passkeys via Passkey List Component

Passkey management lets users view and revoke passkeys registered to their account. The server-side list shows which credentials the relying party accepts. Provider-side copies may remain until the credential provider acts on best-effort reconciliation.

General Passkey Management

iOS
Android

General Passkey Settings in Profile Section

Users can see all the passkeys created for the current account here.
Each entry shows the authenticator or passkey-provider name resolved from the AAGUID stored during registration. If no trusted mapping exists, the entry uses a neutral name instead of guessing.
Users can initiate passkey registration on the current device through its active credential provider.
Users can revoke an existing credential and, where supported, edit an RP-side friendly label. The cryptographic credential itself is not updated.

When no Passkey is created for the User Account

When the user has no passkey created, the passkey list is shown empty.

Passkey Delete Modal

Provide a clearly named revoke or remove action associated with the selected passkey.
This action is not reversible, so the user is again asked for confirmation on deletion of passkey.
Revoke the credential in server state so every later assertion from it is rejected. Then send a best-effort Signal API request so the credential manager can hide or remove its stale client-side copy.
User has the ability to create a new one.

Server deletion completes the security revocation, but not the credential-manager cleanup. The stale passkey may keep appearing in Conditional UI and the app-start overlay until the credential manager acts on a signal. The user can select the stale passkey and complete device authorization, but the server rejects the assertion and login fails. This can make the settings screen appear broken. Reconcile the accepted credential list from the delete action, but treat signalling as best-effort because providers may hide, remove or ignore the credential. See the WebAuthn Signal API.

Passkey List Error States

iOS
Android

Passkey List Loading Error

The list of passkeys fails to load (e.g., due to network or system error).

User aborts Passkey Creation

User cancels creation during system prompts or internal dialogs. No new passkey is added in the list.

Passkey Creation failed due to API Errors

User experiences errors from backend/API during passkey creation. The error is communicated clearly.

Passkey Deletion fails

Deletion of the passkey returns an error due to system or API failure.

Passkey already exists

Attempting to register a passkey that is already present prompts an informative error.

No Passkey Support

When the device or OS cannot create a passkey, omit or disable only the add action with an accurate explanation. Keep the server-side list and revoke actions available.

Acceptance criteria

Benchmark as	User reach
Baseline	Low

Low user reach does not mean low importance. Native passkey management is a baseline lifecycle and security capability, while proactive creation and login flows usually have more direct influence on adoption.

ID	Level	Acceptance criterion	How to verify
`N3.1-AC01`	Core	The list contains every credential the server accepts for the current account.	Compare the rendered list with server records for accounts with zero, one and several credentials, including a credential revoked through another client.
`N3.1-AC02`	Core	Local passkey-creation capability gates only the add action. An unsupported device or OS can still list and revoke server-side credentials, with creation omitted or disabled using an accurate explanation.	Open management on supported and unsupported creation environments; list and revoke remain usable in both, while only supported environments can start creation.
`N3.1-AC03`	Core	Revoking a selected credential changes only that server record and causes every later assertion from it to be rejected.	Give one account several credentials, revoke one, then authenticate with each on every surface that shares the RP. The revoked credential fails and every other active credential still works.
`N3.1-AC04`	Core	Confirmed revocation invalidates first-party last-used or availability hints tied to that credential without clearing valid hints for unrelated credentials or accounts.	Delete the hinted credential with zero and with several accepted credentials remaining, then start the next login. Stale personalization is gone, while unrelated valid hints remain.
`N3.1-AC05`	Core	After an ambiguous revoke response, the client reconciles with server state before presenting a final credential status.	Lose the response after server success and time out before server processing; in both cases, a follow-up read determines whether the entry remains or is removed.
`N3.1-AC06`	Quality	Each entry shows a recognizable authenticator or passkey-provider name resolved from the credential’s stored AAGUID when a trusted mapping is available. An unknown or generic AAGUID uses a neutral label instead of guessing the provider, physical device or exact storage location.	Register credentials with known AAGUIDs from different authenticators or passkey providers and one unknown AAGUID. Confirm that known entries show the mapped names and the unknown entry uses a neutral label.

References

Relevant criteria: N3.1-AC02: CorbadoConnectPasskeyList documents creation-capability handling in a passkey list; it supports the flow shape, not a vendor requirement.
Relevant criteria: N3.1-AC01, N3.1-AC03: Web Authentication Level 3: Decommissioning requires the server to reject later assertions from a decommissioned credential.
Relevant criterion: N3.1-AC06: FIDO Alliance: Synced Passkey Deployment: Emerging Practices for Consumer Use Cases covers distinguishable metadata and its provenance limits.
Relevant criterion: N3.1-AC06: FIDO Metadata Statement defines AAGUIDs and human-readable authenticator or passkey-provider names intended for display to users.
Relevant criteria: N3.1-AC04: One-Tap Login: Seamless Passkey Authentication documents device-scoped returning-user state used to personalize later login; the criterion applies the server-revocation boundary to that hint rather than making it a vendor requirement.
Relevant criteria: N3.1-AC05: Android Developers: Keep credentials consistent with credential providers separates server state from best-effort provider cleanup; Web Authentication Level 3 signal methods defines provider action as opportunistic.

​Create, manage or delete Passkeys via Passkey List Component

​General Passkey Management

​Passkey List Error States

​Acceptance criteria

​References

Create, manage or delete Passkeys via Passkey List Component

General Passkey Management

Passkey List Error States

Acceptance criteria

References