Prompting Users to Add a Passkey

Adoption is decided almost entirely by when you ask and what you say, and the difference between the best moment and the usual one is larger than any amount of copy work will close. This page covers the ranking of moments, the four rules for suppressing a prompt that cannot succeed, and how to ask for a second credential without training people to dismiss you. It sits under Passkey Enrolment and Account Settings UX.

Placement Reference

Moment Why it works or does not Typical outcome
after a successful sign-in authentication is already in mind; the biometric is familiar best by a wide margin
after a security action related context, but a smaller audience good
on the settings page reaches only users already inclined low volume
email or in-app message no context, no device guarantee poor

The audience shrinks as you move down the table and so does the conversion rate, which is why the first row is worth building properly rather than settling for the third.

Moments ranked by conversion The gap between the best moment and the others is larger than any copy change will close. Four placements, in order immediately after a successful sign-in after completing a security-relevant action, such as a password change on first visit to account settings in an email or an in-app message The bottom two are where most programmes put the prompt, which is why most programmes report poor adoption.

Root Cause Analysis

1. Asking on the settings page only. The lowest-traffic surface in most products, reaching the users who would have enrolled anyway. It feels safe because it is unobtrusive, and it produces the adoption curve that gets a passkey programme cancelled.

2. Asking where it cannot succeed. A prompt on a device with no platform authenticator, offering to set up a passkey on that device, produces a ceremony that fails and a user who concludes the feature is broken.

3. Counting dismissals per device. A user with a laptop, a phone and a tablet is asked three times as often as the cap intends, which is how a well-designed limit produces fatigue.

4. Blocking. An interstitial that cannot be dismissed converts everyone who cannot complete the ceremony into a support contact, and there are always more of them than expected.

5. Generic second-credential nagging. Asking every account to add another passkey, regardless of whether the first is synced, means the prompt fires for people who need nothing — and by the time it fires for someone who does, they have learned to dismiss it.

The four suppression rules A prompt that appears when it cannot succeed teaches users to dismiss the ones that can. Four rules; the third is the one most often per-device by mistake a credential already exists on this device offer nothing; this is a settings conversation the platform probe is negative offer a different path, not this one the user dismissed recently respect the cap, counted per account the session is not verified ask for a step-up first, or defer

Step-by-Step Resolution

Step 1 — put the offer after sign-in

A dismissible card or sheet, rendered once the session exists, before the user navigates onward.

Step 2 — apply the four suppression rules

Existing credential on this device, negative probe, recent dismissal, unverified session. Each one has a different alternative: nothing, a different path, silence, or a step-up.

Step 3 — write one sentence naming the benefit

“Sign in with your fingerprint next time.” Match the platform’s vocabulary and mention the device in front of them.

Step 4 — cap per account, server-side

Once per session, a few times per month, and permanently after repeated dismissal. Store the count with the account.

Step 5 — set expectations for the prompt that follows

One clause saying a biometric or PIN prompt is coming. It removes most of the hesitation that shows up as an abandoned ceremony.

Step 6 — drive the second-credential ask from the backup bits

Only when the existing credential reports backup-eligible clear. Then the sentence writes itself, and it is true.

Two ways to ask for a second credential The generic nag and the specific one perform very differently. Rarity is what makes the prompt effective generic — poor "Add another passkey for security" shown to every account ignores whether the first is synced trains dismissal specific — good "This passkey only works on this computer" shown when the backup bit is clear names the risk concretely fires rarely, so it is read A prompt that fires for everyone is a prompt nobody reads by the third time.

Verification and Testing

Assert each suppression rule independently: a seeded credential on the test device suppresses the offer; a stubbed negative probe suppresses it; a recorded dismissal suppresses it; an unverified session defers it. Four tests, and they are the ones that stop a prompt appearing where it cannot work.

Assert the cap is per account by dismissing on one simulated device and asserting the offer does not appear on another.

Assert the second-credential prompt fires for a device-bound credential and does not fire for a synced one. This is the test that keeps a useful prompt from becoming a nag.

Pitfalls

1. Asking before the session is verified. An enrolment offer to a session that has not proved much is an invitation to enrol an attacker’s credential.

2. Re-asking after a permanent dismissal. The user has answered; asking again converts a decision into an annoyance.

3. Offering enrolment on a device the account already has one on. It looks like the product does not know what it stored.

Frequently Asked Questions

Should the prompt appear on the first sign-in or a later one?

The first, provided the session is verified. Waiting adds nothing — the user’s context is best immediately after authenticating, and a new user has no habits to interrupt. What should wait is the second-credential ask, which only makes sense once there is a first.

How permanent should a dismissal be?

Escalating. The first dismissal defers by a session, the second by weeks, and the third should be treated as an answer. Users who want a passkey later will find it in settings, and that is a better outcome than a prompt they have learned to click past without reading.

Does the prompt need its own step-up?

The session must be verified, because enrolment adds a credential that can sign in. If the sign-in that just completed was verified, that is sufficient; if it was not, defer the offer rather than interrupting for a step-up immediately after sign-in.

What should the prompt say on a device with no platform authenticator?

Something different, or nothing. “Set up a passkey on your phone, or use a security key” is actionable; the standard copy is not, because the action it describes cannot be performed on that device.

Should adoption be incentivised?

Framing the benefit is enough for most products, and material incentives tend to produce enrolments that are never used. If a nudge is needed beyond copy, the more effective one is removing friction from the path — fewer steps, clearer wording — rather than offering a reward for a security change.

How do I know the prompt is working rather than merely being shown?

Measure offer-to-acceptance and then the second-ceremony rate. Acceptance tells you the copy and moment are right; the second ceremony tells you the credential is actually being used, which is the only outcome that matters.

What does a realistic adoption curve look like?

Slower than most plans assume, and driven almost entirely by how often people sign in. Accounts that authenticate weekly will see the offer within days; accounts that authenticate twice a year will take that long to be asked once. That asymmetry is why calendar-based targets tend to disappoint and why the useful figure is the share of monthly active accounts holding a credential rather than the share of all accounts. It is also the argument for keeping the offer in place indefinitely rather than treating enrolment as a campaign with an end date: the residual group of infrequent users is reached only by being there when they eventually return, and a prompt that was switched off after a quarter will never reach them at all.

Should the offer differ for a returning user versus a new sign-up?

Slightly, and mostly in the framing. A new sign-up has no password habit to displace, so the offer can be presented as part of setting the account up rather than as a change: “Set up a passkey so you can sign in with your fingerprint.” A returning user has an existing habit, and the sentence that works is the one describing what they will stop doing: “Skip typing your password next time.” Both should sit at the same point in the flow, immediately after the session exists, and both should be equally dismissible. What should not differ is the suppression logic, which is about device capability and prior answers rather than about tenure.

Related