How to convince non-technical Users to use Passkeys

1. Introduction#

"How can I convince my non-technical dad to use passkeys?" This question comes up in almost every workshop we run. It usually comes from people who are already convinced: they are rolling out passkeys at work, have seen the numbers and still cannot persuade a parent to try one. The hesitation is understandable. An unfamiliar prompt creates risk for someone whose current login still works, especially if one bad digital experience with a payment or account continues to shape how they decide.

That is an adoption problem, but it does not close with a better explanation alone. People change how they sign in when the benefit is obvious, the timing is relevant and the first attempt works.

This article therefore analyzes passkey adoption for non-technical users in three layers:

1. Message: the questions users actually ask and the few words worth putting in the prompt.
2. Moment: why a post-login or post-friction nudge outperforms a passive entry in account settings.
3. Mechanism: the product changes that remove unnecessary decisions and failed ceremonies.

We start with the measured results from real rollouts, then apply them to prompts, login flows and account settings. The final section challenges the idea that a parent needs a sales pitch at all and gives a safer way to offer help.

2. Real-life case studies as evidence#

The clearest evidence rewards a concrete benefit, a relevant moment and a path that is likely to work on the current device.

These numbers are the backbone of the article. The sections that follow explain why the changes worked and where their limits are.

3. 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 user 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 often carries no meaning outside the identity bubble, 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 one of the reasons we push passkeys, but it is rarely what the user is weighing up at the prompt.

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

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

Here is the page a Google prompt links to, which is as good as this genre gets:

Google Account Help, "Sign in with a passkey instead of a password", August 2026

Three bullets under Important come before the page says what a passkey does for the reader. The first is about recovery factors, the second about 2-Step Verification and the Advanced Protection Program, the third about where the biometric lives. Only the third one answers a question a non-technical user actually has and it is the fourth paragraph of a page they were never going to open.

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.

4.2 Better wording helps, but explanation is not the main lever#

Whether our explanations actively get in the way has now been tested. Husain, Spero and Biddle first went through the public material large services use to explain passkeys and found that it leads with the mechanism, public key cryptography above all, rather than with what changes for the reader. They then had participants read one of two texts: one written the way the industry writes them today, one rewritten around what the user actually does. Comprehension and mental models differed significantly between the two groups. Same technology, same reader, and the version that explained the machinery left people understanding it less well.

Two more studies show the limit of explanation on its own. Lassak et al. gave participants one of six notifications written to correct the belief that the website receives their fingerprint. Afterwards 40% knew the biometric stays on the phone, against 71% for the same question about unlocking their own phone. The gap between the best and the worst notification was not statistically significant.

In production, Reittinger et al. tested nudges on a live healthcare platform with 3,680 users. The nudge that added an explanation of what passkeys are and where the credential lives took registration adoption from 18.5% to 33.2% and missed significance. The nudge that explained nothing and only made the passkey button full-width and primary-coloured reached 46.2%.

Registration nudges tested by Reittinger, Glas and Pernul (2026), CC BY 4.0

The lesson is that copy works best when it makes the next action clear. However, it cannot compensate for a badly timed prompt or a failed ceremony.

4.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. A failed first attempt can cost more than a good explanation gains, because someone who got stuck once has little reason to try again.

5. Wording that works on real users#

Three rules cover most of it.

5.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 produced twice as many signups.

PayPal leads with the familiar benefit before asking the user to create a passkey

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"

5.2 Answer the fingerprint and lost-phone questions in the prompt#

Two of the questions from section 3 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. Do not expect the sentence to land completely: in the Lassak study, a fifth of participants still thought the site stored the biometric and between 23% and 39% thought it was sent to a third party for processing, after reading exactly this reassurance. Write it anyway, since it is the users who are already worried who read it.

The six biometric explanation variants tested by Lassak et al. at the 30th USENIX Security Symposium

For the lost phone, only promise what the service actually supports. If password or OTP recovery remains available, say: if you lose your phone, you can still recover your account. Synced passkeys may also return through the user's credential manager. A vague promise that "the old way" will always work becomes harmful if the product later removes it.

A FIDO Alliance recovery pattern makes the route back into the account explicit

5.3 Borrow the mental model they already have#

Non-technical users already unlock their phone with a face, finger or PIN. 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 public-private 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.

PayPal borrows the device-unlock mental model instead of explaining the underlying technology

The Lassak numbers make the case for borrowing rather than explaining. Asked where the biometric is stored when signing in with a passkey, 40% of participants got it right. Asked the same question about unlocking their own phone, where the answer is identical, 71% got it right. The knowledge is already there. It is attached to the phone, not to your login, and the sentence that moves it across is a comparison, not a description.

6. Analyze screens in order of adoption impact#

Not every passkey screen deserves equal attention. A post-login prompt reaches users in the flow. A login option reaches returning users. Account settings reach only the small self-selected group that goes looking. That is why the analysis starts with the post-login nudge.

6.1 Post-login and post-friction nudges#

This is the highest-leverage surface. The user has just authenticated successfully or has just experienced the cost of the old method and can understand the benefit in context. eBay gets 75% of new passkeys from its automatic login-flow prompt and only 10% from settings. MakeMyTrip reacts to repeated OTP retries rather than showing the same prompt on a schedule.

The post-login moment: the user has just authenticated, and the offer describes the gesture rather than the technology

Judge this screen on four questions: Is the benefit specific? Does the user opt in before the native system dialog opens? Is declining easy and respected? Is the device likely to complete the ceremony?

6.2 The login screen#

Amazon, Booking.com, Uber and Yahoo ask for an identifier before offering a method. Once the account is known, the product can offer, suppress or de-emphasize passkeys based on what can work for that account and device. Conditional UI goes further by offering an available passkey in autofill, where the user is already typing, without requiring a separate passkey button or vocabulary lesson.

PayPal offers a passkey through autofill on a recognized device

The failure to avoid is a prominent "Sign in with passkey" button that opens a "no passkeys available" dialog. It saves a step in the best case and creates an unexplained dead end for everyone else. One way to make this button smarter is using a 1-tap passkey button that knows if passkeys have been successfully used before on this browser / device. See more here.

6.3 Account settings and help pages#

Settings are useful for management, recovery and the minority of users who actively seek passkeys. They are not a primary adoption channel. Here, more detail is appropriate because the visitor chose to spend attention.

Amazon's settings copy is a useful model: "Sign in the same way you unlock your device by using your face, fingerprint or PIN." Google similarly confirms: "You can now use your fingerprint, face, or screen lock to sign in on this device." Both start with the familiar gesture. Deeper pages can then cover other devices, sharing, privacy and recovery.

Amazon account, login and security page, August 2026

The test is simple: could the first sentence from the settings page work unchanged in a two-second post-login prompt? Keep the technical detail behind that sentence for users who want it.

7. Timing beats persuasion#

Where the prompt appears changes acceptance more than what it says. The healthcare-platform trial from section 4.2 tested nudges at five moments. Adoption ranged from 8.2% for the control during ordinary activity to 54.3% for the strongest nudge at account recovery. Completion after engagement barely changed between touchpoints. The difference was whether users chose to start.

• 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. The identical offer that reached 16.8% during ordinary use reached 52.7% at recovery.

• Ask right after a success. eBay puts the prompt directly behind a completed biometric check during login, a 102% higher enrollment rate than account settings.

• Sell the benefit, not fear. Saying "passwords are insecure" can undermine trust in the service that issued the password. Describe the time or effort the new method saves.

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

8. Product changes that reduce unnecessary decisions#

The most reliable product path reduces prompts that add no useful choice, while keeping creation visible, removable and recoverable. Each change below is followed by its strongest objection because lower friction should not mean lower user control.

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

Conditional Create upgrades a saved-password login and then lets the credential manager notify the user; source: Chrome for Developers, CC BY 4.0

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.

The objection: a credential was created and nobody told the user. This comes up regularly among practitioners, and at Authenticate 2025 it came up in exactly those words, that Conditional Create slips something past people who never find out what happened. The objection is fair on its own terms. What softens it is where the credential is created and what it replaces. The passkey lands in the credential manager the user is already trusting with the password for that same account, it grants no access the password did not already grant and the user can see and delete it in the same list. It is closer to the credential manager upgrading its own stored secret than to a new capability being added behind the user's back.

That does not make it free. Two things make it defensible in practice: the passkey has to show up somewhere the user can find it and remove it, and the next login has to be recognisably better rather than merely different. If a user is surprised by a face scan at the next sign-in and cannot work out where it came from, the objection was right.

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

The objection: firing a native dialog unannounced is intrusive. A user who has just finished logging in did not ask for another step, and the system passkey sheet is a modal they cannot ignore. Done badly this is worse than not asking: it interrupts a completed task with an unexplained dialog, and a dismissal here is a decision recorded against passkeys.

Three things keep it on the right side. One screen of your own before the system dialog, in your words, so the native sheet is not the first thing the user sees. A visible way out that does not look like failure. And a hard rule not to ask again after a decline, which is the same rule as in section 7. TikTok's version of this drives 99% of their passkey creations from a single upsell in the profile popup, and it works because the user taps your screen first and the native dialog only opens after that tap.

TikTok's first-party upsell appears before the native passkey dialog

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

This is what that dead end looks like on Android:

The result of offering a passkey button to a device that has no passkey for the account

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, as PayPal's iOS login in section 6.2 shows.

The objection: it costs the fast path for users who do have a passkey. True, and it is a real cost, one extra screen for the users who need it least. The trade is one step for your best case against a failed ceremony for a group that is much larger early in a rollout. Where you can identify the device without asking, through conditional UI or a stored hint, you get both.

8.4 Suppression and a visible fallback#

The suppression side is the timing rule from section 7, 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 recovery side is the promise from section 5.2: users can see how they will regain access if the passkey is unavailable. A visible, tested recovery route costs a little adoption on paper and buys the confidence that makes cautious users try the new thing in the first place.

The objection: keeping a fallback visible keeps it in use. It does, and the trial from section 4.2 has the counter-argument in a testable form. Making the passkey the default reached the highest adoption of any nudge tested at registration and login, and it did that while still letting the user fall back with one tap. Prominence and availability are different levers. You can make the passkey the obvious choice without hiding the exit, and hiding the exit is what makes cautious users refuse the whole thing.

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.

Google keeps both recovery and retry visible after a failed passkey attempt

9. What to say to a parent and when not to persuade#

The original question contains a bad assumption: a cautious parent is not a conversion problem. An unsolicited technical pitch can make passkeys sound riskier than they are. Start with permission and with a frustration they already recognize:

Then pause. If they are interested, answer the concern they raise instead of continuing a prepared pitch. If recovery is the concern, explain the service's real recovery path: synced passkeys may return on a new device through the credential manager, while some services retain password, OTP or support-based recovery. Do not promise that "the old way will always work" unless that is actually the product policy.

If they choose to try, stay for the first creation, the first passkey login and a quick check of recovery options. If they decline, respect it. Trust grows from control and a successful experience, not from winning the argument.

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. In a personal conversation, ask permission, explain the concrete benefit and help with the first login and recovery check if the person chooses to continue.

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, fingerprint or PIN they already use to unlock the phone, with no password to remember and no code to wait for. Say that the biometric data is not sent to the app or service, then answer the concern they raise. 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 can be restored through the user's credential manager on a new device. Device-bound passkeys do not return automatically, so the service needs a tested recovery route, such as another passkey, an existing password or OTP flow, or support-based recovery. Explain the recovery path the service actually provides rather than promising that the old method will always remain available.

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's enrollment prompt is headlined "Make your face your password". The same screens then switch language: PayPal's button under that headline still says "Create a Passkey", Apple describes "a standard-based technology" with "no shared secrets" and X starts with public key cryptography and a unique key pair. The usable sentence and the technical one usually sit next to each other, and which of the two ends up in the login prompt is the decision that matters.

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.