Passkey Enrolment and Account Settings UX
Most of the difficulty in a passkey rollout is not the ceremony — it is persuading people to enrol, and then giving them a settings page where they can recognise and manage what they enrolled. This page covers the moment that converts, the copy that earns the interruption, and the credential list that makes self-service revocation actually happen. It sits under Frontend UX and Conditional Mediation.
Concept Definition and Spec Grounding
Nothing in the WebAuthn specification concerns enrolment prompts or settings pages, which is precisely why they are where deployments diverge. The protocol gives you a ceremony and a set of facts about its outcome; everything a user sees around that is a product decision.
Two of those facts do more work than the rest. The reported attachment and transports let you label a credential in terms of the device it lives on, and the backup bits tell you whether that credential would survive the device being lost. Between them they turn a credential list from an undifferentiated set of rows into something a person can reason about — which is the difference between a settings page that gets used and one that does not.
The third input is not from the protocol at all: it is the name the user gives a credential. No derived label will beat “work laptop”, and letting people rename is the cheapest possible improvement to a management page.
Architecture and Data Flow
The enrolment offer has three inputs and one output. The inputs are whether the account already has a credential on this device, whether the platform-authenticator probe says a credential can be created here, and how recently the user was last asked. The output is whether to show a one-sentence offer immediately after sign-in. All three inputs are cheap; the third requires a per-account dismissal count stored server-side rather than per-device, or a user who declines on their laptop will be asked again on their phone the same week.
The settings page has a different shape. It reads the credential list for the account, resolves each row into a human label from the stored attachment, transports and any model name, overlays the user’s chosen name where one exists, and offers a removal action per row. The one piece of server-side logic that matters is the guard against removing the last usable credential, which should route into enrolment or recovery rather than silently succeeding.
Both surfaces need the same underlying data, which is why the schema decisions and the interface decisions are worth making together rather than in sequence.
Implementation Guide
Step 1 — put the offer immediately after sign-in. The user has just authenticated, they are thinking about authentication, and the biometric prompt they are about to see is the one they used seconds ago. Every other moment converts worse.
Step 2 — gate it on the probe and on existing credentials. Do not offer enrolment on a device that cannot hold a credential, and do not offer it when the account already has one on this device — that second case is a settings-page conversation, not a prompt.
Step 3 — write one sentence, naming the benefit. “Sign in with your fingerprint next time” beats anything mentioning security, credentials or standards. Match the platform’s own vocabulary: they say passkey, so say passkey.
Step 4 — cap the ask, server-side. Once per session, with a hard ceiling of a few times per month, counted per account. Record dismissals so the cap is real.
Step 5 — build the settings page from five fields. Name, added date, last used, backup state, remove. Anything less produces a list nobody can act on.
Step 6 — let users rename. A nullable label, editable inline. It is a small feature and it is the one that makes the rest of the page work.
Step 7 — guard the last credential. Removing it should be blocked with an explanation and two options: enrol a replacement first, or start recovery.
Step 8 — surface the second-credential suggestion from the backup bits. Not from a credential count. A single synced passkey is resilient; a single device-bound one is not.
Validation Checklist
Error Reference Table
| Symptom | Cause | Fix |
|---|---|---|
| Low enrolment despite high traffic | the offer is on a settings page nobody visits | move it to post-sign-in |
| Users dismiss without reading | generic copy, or asked too often | name the benefit; cap the ask |
| Stale credentials accumulate | the settings list is unreadable | add names, dates and last-used |
| Users locked out after removing a passkey | no last-credential guard | block and route to enrolment or recovery |
| Everyone nagged for a second passkey | prompt driven by credential count | drive it from the backup-eligibility bit |
| Enrolment offered where it cannot succeed | probe not consulted | gate on the platform-authenticator probe |
Platform and Library Notes
Platform vocabulary has converged on “passkey”, and matching it matters more than it might appear: the word on your button should be the word in the dialog the operating system is about to show. Where platforms differ is in how much of the credential they surface to the user afterwards — some list passkeys in a system settings pane where users can delete them independently of your application, which means your list and theirs can diverge without any event reaching you.
That divergence is worth designing for rather than fighting. A credential the user deleted at the platform level will simply stop working, and your first indication is a failed ceremony. Keeping removal available from your own settings page, and treating a credential that has not been used for a long period as a candidate for archival, keeps the two views from drifting too far apart.
Third-party password managers add a further wrinkle: they may own the credential and present their own management interface. From your side nothing changes, but a user’s mental model of “where my passkeys live” may not match yours, which is another argument for labelling by device rather than by provider.
Pitfalls and Security Hardening
1. A blocking enrolment interstitial. Every population contains users who cannot complete the ceremony on the device in front of them. An interstitial they cannot dismiss converts them into support tickets.
2. Prompting on the settings page only. It is the lowest-traffic surface in most products, and it reaches exactly the users who were already going to enrol.
3. Counting dismissals per device. A user with three devices gets asked three times as often, which is how a well-intentioned cap produces prompt fatigue.
4. A list of identical rows. Users will not remove credentials they cannot identify, and unremoved credentials degrade every subsequent ceremony through oversized exclude lists.
5. Allowing removal of the last credential without a guard. It converts a settings page into an account-loss mechanism.
6. Nagging users who do not need it. A single synced passkey is durable. Asking its owner to add a second one teaches them the prompt is noise, and they will ignore the one that matters.
Frequently Asked Questions
Where should the enrolment offer live?
Immediately after a successful sign-in, as a dismissible card or sheet rather than a blocking step. That moment has the highest conversion by a wide margin, and it is the only one where the user’s mental context already includes authentication.
How often is too often?
Once per session, with a ceiling of a few times per month per account, and never again once a user has dismissed it repeatedly. The exact numbers matter less than the fact that the cap is enforced per account rather than per device.
Should the settings page show the authenticator model?
As part of a suggested name rather than as its own field. “Security key (model)” is useful when a user has several; a separate column labelled with a vendor name is technical detail that does not help them decide anything.
What should happen when a user removes a passkey?
The credential is revoked, its sessions end, it leaves the exclude list, and the user is told what happened. If it was their last usable credential, the removal should not proceed without them first enrolling a replacement or going through recovery.
Should users see which credentials are synced?
In translated form, yes. “Saved to your account — available on your other devices” is information a user can act on, and it makes the occasional suggestion to add a second credential comprehensible when it appears.
Does a passkey settings page need its own step-up?
Yes. Adding, renaming and removing credentials are exactly the actions that change who controls the account, so they belong in the set that requires a recent, verified ceremony.
Measuring Whether the Interface Is Working
Enrolment programmes are usually measured with a single number — how many accounts have a passkey — and that number hides almost everything that matters.
Offer-to-acceptance rate. Of the users shown the enrolment offer, how many started a ceremony. This is a pure measure of the copy and the moment, and it is the number to move first. A low rate with high traffic means the sentence is wrong or the timing is; it almost never means users do not want passkeys.
Ceremony completion rate for enrolment. Of those who started, how many finished. A gap here is a device problem rather than a persuasion problem: the probe said yes, the ceremony began, and something in the platform interaction lost them. Segmenting it by platform usually identifies the cause within a day.
Second-ceremony rate. How many users who enrolled once go on to sign in with the passkey. This is the number that tells you the feature is real rather than merely adopted, and it is the one most often not collected. A high enrolment rate with a low second-ceremony rate means people enrolled and then never saw the passkey path again, which is a discoverability problem on the sign-in page.
Settings-page removal rate. How often users remove credentials. A near-zero rate on a mature deployment is not good news; it usually means the list is unreadable and stale credentials are accumulating silently.
Dismissal distribution. How many times an average account has been shown the offer. If a meaningful group has seen it many times, the cap is not working, and those users have been trained to dismiss reflexively.
Five numbers, all cheap to collect, and between them they distinguish a persuasion problem from a platform problem from a discoverability problem — three failures that look identical in a single adoption figure.
Copy That Works and Copy That Does Not
The wording around a passkey ceremony carries more weight than any other part of the interface, because the platform owns the dialog and your copy is the only thing setting expectations for it.
Name the outcome, not the mechanism. “Sign in with your fingerprint next time” describes what the user gets. “Register a passkey for passwordless authentication” describes what your system does. The first converts; the second reads as an administrative task.
Use the platform’s word. Every major platform now says “passkey” in its own dialogs. Using a different term on the button immediately before that dialog creates a small moment of doubt at exactly the wrong point.
Say what will happen next. A user about to see a biometric prompt should have been told a biometric prompt is coming. This single sentence removes most of the hesitation that shows up as an abandoned ceremony.
Explain the QR code before showing it. The cross-device flow is the one most likely to be abandoned, and almost all of that abandonment is people not understanding what appeared. “Scan this with the phone that has your passkey” costs nothing.
Keep failure messages generic and actionable. Protocol vocabulary belongs in telemetry. What the user needs is a sentence saying it did not work and two visible ways forward.
Write the settings page in device language. “This MacBook”, “iPhone”, “Security key” — not “platform authenticator, internal transport”. The user is trying to answer which of their things a row refers to, and the specification’s vocabulary does not help them do it.
Accessibility of the Enrolment and Settings Surfaces
The ceremony dialog belongs to the platform and is accessible by construction; everything around it is yours, and it is easy to build surfaces that work only with a pointer and a clear line of sight.
The enrolment offer must be reachable and dismissible by keyboard. A card that appears after sign-in and traps focus, or that can only be dismissed by clicking a small icon, is a barrier at exactly the moment you are asking for cooperation. Move focus to it deliberately, provide an obvious dismiss control in the tab order, and let the escape key work.
Announce state changes. When a ceremony starts, a screen-reader user should be told something is happening, because the platform dialog may not be announced by your page’s assistive technology in the way a native control would be. A polite live region carrying “waiting for your passkey” and then the outcome covers it.
Do not rely on the biometric icon alone. Fingerprint and face glyphs are widely understood by sighted users and mean nothing to anyone using a screen reader unless they carry a label. The accessible name should say what the control does, not what the icon depicts.
Make the settings list a real list. A credential list built from generic containers is far harder to navigate than one using list semantics with each row’s name as its accessible label. The removal control for each row needs a name that includes which credential it removes — “Remove work laptop” rather than four identical “Remove” buttons.
Keep the failure path announced. A ceremony that fails silently, leaving the page visually unchanged apart from a small message, is invisible to anyone not looking at that part of the screen. The same live region that announced the start should announce the outcome.
None of this is passkey-specific, which is rather the point: the surfaces around the ceremony are ordinary interface work, and they deserve the same care as any other part of a sign-in flow. What is passkey-specific is the temptation to treat them as trivial because the interesting part happens somewhere else.
Related
- Frontend UX and Conditional Mediation — the parent topic area and the client-side surface
- Designing a Passkey Management Page — the credential list in detail
- Prompting Users to Add a Passkey — timing, copy and capping the ask
- Detecting Platform Authenticator Availability — the probe that gates the offer
- Modelling Multi-Device Passkeys in Your Schema — the data these surfaces read