---
url: 'https://www.corbado.com/blog/convince-non-technical-users-passkeys'
title: 'How to convince non-technical Users of Passkeys'
description: 'How to convince non-technical users of passkeys: the wording, the timing and the product changes that move them, based on real consumer rollouts.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-08-24T15:34:05.605Z'
lastModified: '2026-08-24T15:34:05.605Z'
keywords: 'convince non-technical users passkeys, passkey adoption non-technical users, passkey user education, passkey enrollment prompt wording, explain passkeys to parents, passkey adoption consumer'
category: 'Passkeys Strategy'
---

# How to convince non-technical Users of Passkeys

## Key Facts

- **What non-technical users turn down is an unfamiliar word at a moment when nothing is
  bothering them.** Wording and timing decide more than the security argument.
- **Wording alone doubled enrollments.** MakeMyTrip changed the prompt from "create a
  passkey" to "skip OTP next time" and got twice as many signups.
- **Three questions decide it:** where does my face or fingerprint go, what happens when I
  lose my phone and do I still have my old way in.
- **Some users can never succeed at the prompt**, for example when the phone has no screen
  lock. Asking them anyway teaches them that passkeys do not work.
- **Product changes move the numbers further than any argument:** Conditional Create,
  automatic append, identifier-first login and suppression on unsupported devices.

## 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](https://www.corbado.com/blog/passkeys-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](#9-what-to-actually-say-to-your-father).

## 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](#8-what-other-rollouts-changed-and-what-it-moved).

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 page with a success banner, an explanatory paragraph and a create a passkey button](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/google_passkeys_settings_hq_a5e3735366.png)_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 login and security page with a passkey row explaining sign in the same way you unlock your device](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/amazon_login_security_hq_b35340ca99.png)_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 passkey page with expandable sections about other devices, sharing with family and privacy](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/amazon_passkey_page_hq_4935a4c0e0.png)_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](#8-what-other-rollouts-changed-and-what-it-moved)).

### 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 sign-in step two offering sign in with a passkey next to the password field](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/amazon_signin_passkey_option_3d376425b8.png)_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 with a log in with passkey button below the email field](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/paypal_login_passkey_button_4d0887f801.png)_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](https://www.corbado.com/blog/samsung-passkeys)
  devices, Samsung Pass sits in front of
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/conditional-create-passkeys) 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](https://www.corbado.com/blog/user-transition-passkeys-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](https://www.corbado.com/blog/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](https://www.corbado.com/blog/passkey-adoption-case-studies-authenticate-2025).

- **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.

> You know how you unlock your phone with your face or your thumb? You can use that to get
> into your account too, so there is no password to remember and no code to wait for. The
> face or thumbprint stays on the phone, they never get it. And if you ever lose the
> phone, you still have the old way in.

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](https://www.corbado.com/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.

[Video: Enrollment](https://www.corbado.com/videos/features/enrollment.mp4) ([See Login Funnel in Corbado Observe](https://www.corbado.com/observe/login-funnel))

Once you know which cohorts convert, [Corbado Connect](https://www.corbado.com/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.

## 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](https://www.corbado.com/blog/conditional-create-passkeys),
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.