Designing a Passkey Management Page

A credential list that users cannot read is a list they will not act on, and unremoved credentials degrade every subsequent ceremony. This page covers the five fields a row needs, how to derive a label people recognise, and what a removal control must actually do. It sits under Passkey Enrolment and Account Settings UX.

Field Reference

Field Source Why it is there
name the user, or derived the only reliable way to identify a row
added your credential row distinguishes old from new
last used updated on each assertion identifies what is safe to remove
backup state the flags byte tells the user what a device loss costs
remove an action the whole point of the page

Four fields and an action. A page with fewer produces a list of indistinguishable rows and no removals.

Deriving a label a user will recognise Fall through a short chain until something meaningful is available. Four steps; the last one still has to be usable the name the user chose always wins, if one exists the resolved authenticator model from attestation, where it was collected attachment plus transports "This device" or "Security key" a neutral default "Passkey", plus the date it was added

Root Cause Analysis

1. Rows with no distinguishing information. The default outcome when nothing was recorded at registration. Four entries called “Passkey” cannot be acted on, so nothing is ever removed, exclude lists grow, and ceremonies on constrained transports start failing.

2. No user-supplied name. Every derived label is a guess. Letting people type “work laptop” is a nullable column and an inline edit, and it outperforms any amount of clever inference.

3. Removal that only hides the row. If revocation does not end sessions and update the exclude list, the credential is half-alive: it can still mint requests from an existing session, and the user cannot re-enrol the device they just reset.

4. No guard on the last credential. A settings page that will happily remove the only way into an account is an account-loss mechanism with a friendly icon.

5. Assuming your list matches the platform’s. Users delete passkeys in system settings without anything reaching your server. Designing as though the two views are synchronised produces confusion on both sides.

What removal must actually do A row disappearing from a list is the visible part of four separate effects. Four effects, one click revoke the credential row end sessions minted by that credential update the list the exclude list drops it tell the user on a channel they control Users only trust a removal control that visibly does something; a row vanishing with no confirmation reads as a UI glitch.

Step-by-Step Resolution

Step 1 — record the labelling inputs at registration

Attachment, transports, and the resolved model name if attestation was collected. Without them, no label can be derived later.

Step 2 — derive a default and let the user override it

Fall through the chain: user name, model name, attachment-based description, neutral default. Show the added date alongside so even the neutral case is distinguishable.

Step 3 — sort by last used, descending

The credential the user relies on appears first; the candidates for removal sink to the bottom where they belong.

Step 4 — translate the backup state

“Available on your other devices” or “Only works on this device”. Never the bit names.

Step 5 — make removal do all four things

Revoke, end that credential’s sessions, drop it from the exclude list, and confirm to the user on a channel they control.

Step 6 — guard the last usable credential

Block, explain, and offer two routes: enrol a replacement, or start recovery.

Step 7 — require step-up for every mutation

Adding, renaming and removing all change who controls the account.

Two lists that will diverge Your credential list and the platform’s passkey manager are separate views that neither side keeps in sync. Neither view is authoritative for the other your list shows credentials your server accepts when each was last used here backup state as reported to you a name the user gave it here the platform shows passkeys stored on the device or account deletions your server never hears about entries for other sites too its own naming A passkey deleted in the platform manager simply stops working; your first indication is a failed ceremony.

Verification and Testing

Build a test account with four credentials of different kinds — a synced platform passkey, a device-bound one, a security key and one with no recorded metadata — and render the page. Every row must be distinguishable, and the fourth must still be usable through its date. That single fixture catches most labelling defects.

Assert that removal ends the right sessions and only those: sign in twice with different credentials, remove one, and assert the other session survives.

Assert the last-credential guard by attempting to remove everything, and assert the resulting flow offers a real next step rather than an error.

Pitfalls

1. Showing raw protocol values. “platform / internal” means nothing outside a specification.

2. Sorting by creation date. Puts the credential they use most at the bottom.

3. Removal without confirmation. Reads as a glitch, and users re-check by removing another one.

Frequently Asked Questions

Should the page show credentials the user cannot currently use?

Yes — a security key in a drawer is still a credential, and hiding it because it is not connected would make the list unreliable. What the page can usefully show is when each was last used, which lets the user infer availability without you guessing.

What if a user renames two credentials the same?

Allow it. Users know their own devices, and enforcing uniqueness on a display label is friction with no benefit. The credential identifier is what your system keys on; the name is purely for the human reading the page.

How should the page handle a credential deleted in the platform manager?

There is nothing to handle, because you are never told. The credential simply fails at its next use, and your revocation guard will then be the thing that keeps the account usable. Treating credentials unused for a long period as archival candidates keeps the divergence from accumulating.

Should removal require re-authentication every time?

It should require a recent, verified ceremony rather than a fresh one per row. A user tidying up three stale credentials should not be prompted three times, but the session must have been verified recently enough that somebody who found an unlocked laptop cannot quietly remove the owner’s passkeys.

Does the page need to show which credential the current session used?

It is a genuinely useful touch: marking “this device” on the row that minted the current session removes most of the ambiguity for users with several similar entries, and it makes the last-credential guard comprehensible when it fires.

Should users be able to see failed sign-in attempts here?

Not on this page. It is a management surface, and mixing a security log into it makes both harder to use. A separate account-activity view is the right home for that, and it can link back here for the removal action.

Keeping the List Small Without Asking Users To

Credential sprawl is the slow failure mode of a passkey deployment: nothing breaks, exclude lists grow, requests get larger, and ceremonies on constrained transports start failing for reasons nobody connects to a settings page. The remedy is mostly automatic rather than user-driven.

Prevent duplicates at the source. A correctly scoped exclude list means a device enrols once. Most accounts with a dozen credentials got there because the list was missing or wrongly scoped for a period, and every one of those rows will persist until somebody removes it.

Archive on inactivity, not on age. A credential unused for a long period is a candidate; a credential created long ago and used yesterday is not. Age-based cleanup removes the security key in the drawer, which is precisely the credential the user was relying on for the case where everything else is lost.

Notify before archiving. A message saying a passkey has not been used in a long time and will be removed, with a one-click way to keep it, converts an unpleasant surprise into a routine tidy. It also surfaces the drawer case, because the user will keep it.

Make the list itself the nudge. Sorting by last used puts the stale entries at the bottom under a visible date, which does more to prompt removals than any message. Users tidy lists they can read.

Cap gently rather than hard. A ceiling in the low tens, enforced by suggesting removals rather than by blocking enrolment, keeps the numbers sane without ever telling somebody they have too many passkeys — which is a sentence no product should have to write.

Related