How to convince non-technical Users of Passkeys

1. Introduction#

This question comes up in almost every workshop we run, and never from a sceptic. It comes from people who are already convinced: they are rolling passkeys out at work, they have seen the numbers and they still cannot get their own parents onto them. The picture they describe is consistent. Their parents do not install new apps, they distrust anything that arrives on the phone and often one bad experience with a card or an account years ago is still shaping the decision.

That gap between the professional who is sold and the non-technical user who is not is the actual adoption problem, and it does not close with a better explanation alone. Nobody adopts a login method because the argument for it was sound. People change how they sign in when the change costs them nothing at a moment when the old way is already annoying them.

This is written for the person building the prompt: the questions non-technical users really ask, the wording that works on them, the timing that matters more than the wording and the product changes that take the decision away entirely. At the end there is the short version you can say at the kitchen table.

2. Questions non-technical users really ask#

The same questions come back across consumer rollouts, and every one of them is about what happens to the person asking.

• "Where does my face or fingerprint go?" Many users assume the app or service receives their fingerprint and stores it somewhere.
• "What if I lose my phone?" For an older user this is often the real blocker behind a vague no.
• "What is a passkey?" The word carries no meaning outside the industry, so people ask what it is.
• "I already have a password, why change?" A password that works is not experienced as a problem, so the switch reads as pure risk.
• "Do I have to remember something new?" People hear "new login method" and expect a new thing to memorise.
• "Is this the same as the fingerprint thing in my banking app?" Years of device biometrics have made the gesture familiar, which helps, but it also means people mix up two different things.
• "Can my family still get into my account?" Shared devices and shared accounts are common in exactly this group.
• "Do I have to do this on every device?" A fair question that most prompts leave unanswered.

Almost nobody asks whether the credential is phishing-resistant, how the cryptography works or which standards body maintains it. Security is the reason we build passkeys, but it is rarely what the user is weighing up at the prompt.

3. Why explaining passkeys only gets you so far#

The instinct of every technical person is to write a better explanation. It does help: a user who has some idea what a passkey is will be less suspicious of the prompt. It just helps much less than the effort put into it suggests.

3.1 Almost nobody reads the explanation#

An enrollment prompt gets a second or two of attention. A help page linked from it gets a fraction of that traffic, and a FAQ page gets close to nothing. People come to your login screen to get into their account, not to read about authentication, and nobody stops on the way to click through to an explanation. Whatever education you write therefore has to work for the users who never open it, which in practice means it has to fit inside the prompt itself.

3.2 Education only lands when it is phrased as a benefit#

The few words that do get read have to say what the user gets, not what the technology is. "Passkeys are a phishing-resistant replacement for passwords" is education nobody asked for. "Skip the code next time" is the same message, told as something the user wants, and it fits in a glance. Keep it to one benefit in plain words. Everything beyond that is for the people who go looking, and there are very few of them.

3.3 A first successful use matters more than understanding#

A user who has read up on public key cryptography and a user who simply taps the button end up in the same place. Whatever understanding follows tends to arrive afterwards, if at all. What actually convinces people is the second login: the app opens with a glance and nothing else happens. That experience teaches more than any help page, so the moment worth optimising for is the first successful use, not the explanation in front of it. It also means a failed first attempt costs more than a good explanation gains, because someone who got stuck once rarely tries a second time.

3.4 "Passkey" means nothing to the people you are asking#

MakeMyTrip found this in their own user base, as we describe in our India overview: a large part of their users, mostly on cheaper devices and outside the big cities, did not recognise the word "passkey" at all. A prompt built around that word says nothing to them.

3.5 The simple explanation, for when someone does ask#

None of this means you should have no explanation at all. Some users do ask, and they deserve an answer that does not start with cryptography. Three sentences are enough: their phone already checks that it is them, the app can use that same check instead of a password, and the face or fingerprint never leaves the phone. The full version, in the words you would use at a kitchen table, is in section 9.

4. Wording that works on real users#

Three rules cover most of it.

4.1 Describe the benefit, never the technology#

MakeMyTrip ran an A/B test that changed nothing but the wording of the enrollment prompt. One version asked users to "create a passkey", the other offered to "skip OTP next time". The second one produced exactly twice as many signups. Other rollouts land in the same place from a different angle, see section 8.

Write the sentence from the user's side of the screen, naming what they get instead of what you build:

• Good: "Skip the code next time", "Sign in with your face or fingerprint", "Log in without waiting for an SMS"
• Bad: "Create a passkey", "Enable passwordless login", "Set up FIDO2 authentication"

4.2 Answer the fingerprint and the lost-phone question in the prompt#

Two of the three questions from section 2 can be answered where they come up, in one line each, instead of in a help page nobody opens.

For ownership: your fingerprint stays on your phone and is never sent to us. That is accurate. The biometric check runs on the device and unlocks a private key stored there, and your server only ever receives a signed response, never the fingerprint.

For the lost phone: if you lose your phone, you can still get in the old way. Say it in the prompt, not after the fact. For a cautious user this is the sentence that makes the rest of the offer safe to accept, and it is also the reason the fallback path has to really exist (see section 7.4).

4.3 Borrow the mental model they already have#

Non-technical users already unlock their phone with a face or a finger dozens of times a day. That habit is the whole explanation you need. "It works like unlocking your phone, but for your account" gets people to try, where a correct description of a key pair does not. The comparison is not exact, and that is fine. Someone who feels safe enough to try does not need the standard explained first.

5. What real portals show their users#

The rules above are cheap to write down, so in August 2026 we went through the passkey settings and login screens of several large consumer services. The same page usually gets it right in one place and wrong in another.

5.1 Google gets it right in the banner and wrong in the paragraph below it#

Google Account, passkeys and security keys page, August 2026

The banner says: "You can now use your fingerprint, face, or screen lock to sign in on this device." One sentence, no technology, and it describes what the user does rather than what was built. The paragraph right below it, which is the actual explanation on the page, brings in security keys, a second step when signing in with a password and a warning to keep screen locks private. The button underneath says "Create a passkey". One screen, two languages, and the part a non-technical user can act on is the banner.

5.2 Amazon describes the passkey in the words a user would use#

Amazon account, login and security page, August 2026

The passkey row reads "Sign in the same way you unlock your device by using your face, fingerprint or PIN". It sits directly above the password, in the same list, and it is the only entry on the page that explains itself through something the user already does. Further down the same list, two-step verification needs "an additional layer of security when signing in" to describe something people have been doing for years.

A settings page is not the moment of decision either, and by section 3.1 most users will never open it. What it shows is that the sentence exists. The same company that has to explain the feature somewhere managed it without a single technical term, which makes it a candidate for the prompt, where it would be read.

The detail page behind it does the same for the questions from section 2:

Amazon account, passkey page, August 2026

"Use passkey on different devices", "Sharing passkeys with friends and family", "Privacy considerations". Three of the questions people actually ask, answered where they come up, and the line at the top handles the shared account case directly: "Sharing this account with someone who wants to sign in with a passkey? They'll need to set up their own."

5.3 The counterexample: the standard explained, the setting buried#

Apple's page opens with "a standard-based technology" that is "designed so that there are no shared secrets", and X starts with "public key cryptography from the WebAuthentication (or 'WebAuthn') standard" and "a unique key pair". Both are accurate and neither tells a non-technical user what changes for them.

The path X then describes is the more expensive problem: six steps, sitting under a heading called "Additional password protection", with the password typed in again along the way. A user who follows it learns that the passkey is an extra on top of the password rather than a replacement for it, and that it is something you have to go looking for. That is the account settings path, and eBay's numbers put only 10% of their enrollments there (see section 8).

5.4 On the login screen, the method comes after the identifier#

Amazon, Booking.com and Yahoo all ask for an email address, a phone number or a username before they offer any method at all. None of them puts a passkey button on the first screen. That is the identifier-first pattern from section 7.3 in production: find out who the user is, then show only what can work for that account.

The passkey appears one step later, once the account is known:

Amazon.de sign-in, second step for a recognised account, August 2026

Now "Sign in with a passkey" sits under the password field, next to the shopping app and the emailed code, and on this machine it is greyed out while the other two are not. Knowing the account first is what buys that. The option can be offered, held back or dimmed per account and device, instead of one button that everybody sees and only some can finish. PayPal takes the same idea further for people it recognises and greets them with "Log into PayPal with Face ID or Touch ID", without using the word passkey at all.

PayPal login screen for a new visitor, August 2026

For visitors it does not recognise, though, PayPal puts "Log in with Passkey" on the first screen, before anyone knows who is sitting in front of it. For a user with a passkey on this device that saves a step. For everyone else it is the case from section 7.3: a button that opens a dialog they did not expect and cannot complete, on a screen where the old way was working fine.

6. Timing beats persuasion#

Where the prompt appears changes acceptance more than what it says.

• Ask after friction, not before. A user who has just retyped an SMS code three times is receptive. The same user, at a calm moment, has no reason to change anything. MakeMyTrip built their prompt logic on exactly this signal: it reacts to repeated OTP retries rather than firing on a schedule.
• Ask right after a success. eBay puts the prompt directly behind a completed biometric check during login, which more than doubled their enrollment rate compared to the same offer sitting in account settings. The user has just proven who they are, so the offer reads as the obvious next step.
• Ask once. MakeMyTrip keeps the prompt optional and does not ask again once someone has declined. A prompt that keeps coming back turns a soft no into a hard one.
• Do not ask when it cannot work. Consumer rollouts in price-sensitive markets keep finding users, older users in particular, whose phone has no PIN or biometric configured at all. Without a device lock there is nothing to build a passkey on, so the prompt can only fail. On some Samsung devices, Samsung Pass sits in front of Google Password Manager and requires a Samsung account first, so the same flow that is one tap on one Android phone has an extra step on another. Every failed attempt teaches the user that passkeys are broken, which is expensive to undo.

7. Product changes that remove the decision#

The most reliable way to convince a non-technical user is to never put the decision in front of them.

7.1 Conditional Create upgrades a password login without asking#

Conditional Create turns a password login into a passkey in the background. The user signs in with their password as always, and in the same session the credential manager quietly creates a passkey. Nothing pops up, nothing is asked. From the user's side nothing happened, and from then on there is a passkey on that device that the next login can use.

How much this is worth to you depends on the share of your logins where the password is filled in by a credential manager instead of typed. Conditional Create only fires on those. On iOS that share runs roughly 20% to 50%, higher on older sites where users have had years to save their password, and support differs between credential managers. Within that share it is the cheapest adoption you can get, because nobody has to agree to anything.

7.2 Automatic append after a successful login#

When someone signs in successfully through the old method on a device that supports passkeys, that is the moment to add one. The user has just proven who they are and the friction of the old method is fresh in their mind. The alternative, a setting somewhere in the profile, only ever reaches the users who go looking for it, which is not the group this article is about.

7.3 Identifier-first login instead of a passkey button#

A visible "sign in with passkey" button is a trap on a device that has no passkey saved locally. Technically the ceremony can still succeed by scanning a QR code and using a passkey on another device, but a non-technical user does not read that screen as an offer. They see something unexpected, they back out, they drop back to the old method and now they associate passkeys with something that did not work.

Checking the identifier first and starting the passkey journey only when the account actually has a credential removes most of that. It is not a guarantee: the web platform cannot tell you whether the credential is available on this particular device, only that one exists. What it does remove is the case where the button was never going to lead anywhere. Conditional UI does the same job on the autofill path.

7.4 Suppression and a visible fallback#

The suppression side is the timing rule from section 6, turned into a filter: devices with no screen lock, unsupported OS versions and credential managers with known problems never get the prompt in the first place. The fallback side is the promise from section 4.2: everyone can always find the old way in. A visible fallback costs a little adoption on paper and buys the confidence that makes cautious users try the new thing in the first place.

One failure mode is worth designing for explicitly. When a user deletes a passkey in their credential manager, your backend does not hear about it and keeps offering a login that cannot work. The WebAuthn Signal API helps in the other direction, letting your server tell the credential manager which credentials are still valid, so stale ones get cleaned up there. A client-side deletion still only surfaces when the next login fails, which is why the fallback path has to catch it gracefully.

8. What other rollouts changed, and what it moved#

The pattern is easier to trust when it shows up in more than one product. These are consumer rollouts that published what they changed, not just what they achieved. All of them are covered in more detail in our Authenticate 2025 case studies.

• MakeMyTrip, the wording. Same prompt, same moment, one word changed: "create a passkey" became "skip OTP next time". Twice as many signups.
• eBay, the placement. Instead of an option in account settings, the prompt appears automatically right after the user has passed a biometric check during login. That move alone was a 102% higher enrollment rate, and 75% of all new passkeys now come from this one moment. Only 10% still come from account settings.
• Uber, the moment. In-line nudges inside login and signup instead of a separate screen. Over 90% of enrollments come from those nudges, though the conversion rate swings between 10% and 50% depending on device and country.
• TikTok, the trigger. A small upsell in the profile popup that opens the native passkey dialog drives 99% of their passkey creations. The signup flow itself was cut from seven steps to four.
• Roblox, the silent path. 50% of their mobile users had a saved password, which let them convert those logins into passkeys in the background. Where they do ask, in the signup flow, the opt-in rate is 12%, and signup still accounts for 85% of all passkeys added.

None of these teams won an argument. They moved the ask to a moment the user was already in, or removed it entirely.

9. What to actually say to your father#

Strip everything above down to what fits in a conversation at a kitchen table. No technology names, one benefit, one reassurance and one exit.

If he asks a follow-up, answer that one and stop. Then sit next to him the one time he does it, because the first successful use is what convinces people.

10. How Corbado can help#

Every recommendation in this article is a guess until you can see what your own users do with the prompt: which cohort abandons the ceremony, on which devices and at which step. Corbado Observe, the authentication observability layer, reads the client side of every login and enrollment. It works alongside your existing IDP.

• Client capabilities show, per device and browser, whether a built-in authenticator is even available. That is the signal separating users who could enroll from users whose phone can only fail the prompt.
• Enrollment and funnel views break the ceremony down by device, operating system, browser and authenticator, so a cohort that drops out becomes a named group instead of an unexplained gap.
• Experiments compare prompt wording and placement against each other, measured on completed enrollments.
• Per-user drill-down reconstructs one person's journey when support gets the call, which is the fastest way to learn what a non-technical user actually saw.

See Login Funnel in Corbado Observe →

Once you know which cohorts convert, Corbado Connect acts on it in the flow, with gated prompts that appear only where they can succeed and rollout rules per cohort.

11. Conclusion#

A non-technical user at the prompt is deciding whether an unfamiliar word is worth a risk at a moment when their current login still works. No security model enters into it, so the work is in the moment you design rather than the argument you make.

Change the word to a benefit they recognise, move the ask to the moment they are already frustrated, answer the fingerprint question before it is asked and remove the prompt entirely where the platform can create the passkey on its own. For the kitchen table, three sentences and sitting next to him the first time are enough.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

How do you explain passkeys to a non-technical person?#

Do not explain the technology. Describe what changes for them: they unlock the app with the same face or fingerprint they already use to unlock the phone, with no password to remember and no code to wait for. Add one sentence on ownership, that the face or fingerprint stays on the phone and is never sent to the app or service, and stop there. Terms like passkey, FIDO, cryptographic key pair or phishing-resistant do not help a non-technical user decide.

Why do non-technical users decline the passkey enrollment prompt?#

In most cases what they turn down is an unfamiliar word at a moment when nothing is bothering them. In MakeMyTrip's consumer rollout, users on cheaper devices outside the big cities did not recognise the term "passkey" at all, and rewording the prompt from "create a passkey" to "skip OTP next time" produced twice as many enrollments. Prompt timing matters as much as wording: users accept far more often right after they have felt friction, for example after several failed OTP attempts.

Do passkeys send my fingerprint to the website?#

No. The biometric check happens on the device and unlocks a private key stored there. The fingerprint or face data never leaves the phone and is never shared with the website or app. The service only receives a signed response proving the device unlocked the key. Put that sentence in the prompt itself, where a sceptical user will read it.

What happens to a passkey if the user loses the phone?#

Synced passkeys are restored from the credential manager, so a user who signs in to a new phone with their Apple or Google account gets the passkey back. Device-bound passkeys do not come back, which is why a fallback path such as the existing OTP or password flow has to stay in place. Next to that fallback, prompt users to add a second passkey on another device they already use, so a lost phone is not a lost account. For an older user this question is usually the real blocker, so answer it before the prompt appears rather than after.

How do large services word their passkey prompts?#

The services that do it well describe the gesture and the benefit, never the technology. Amazon's account settings say "Sign in the same way you unlock your device by using your face, fingerprint or PIN", Google's confirmation banner says "You can now use your fingerprint, face, or screen lock to sign in on this device", and PayPal greets a recognised user with "Log into PayPal with Face ID or Touch ID" without using the word passkey at all. The counterexamples open with the standard instead: Apple describes "a standard-based technology" with "no shared secrets", and X starts with public key cryptography and a unique key pair.

Which product changes raise passkey adoption among non-technical users?#

Four changes do most of the work: Conditional Create, which upgrades a password login to a passkey without any prompt; automatic append after a successful login through the old method; identifier-first login so users are not offered a passkey button when their account has no passkey at all; and suppression of the prompt on devices with no screen lock or a broken credential manager, where the attempt would fail anyway.