Why passkeys still stall with normal users Passkey teams usually know the security case already. The harder part is adoption: how do you get someone non-technical to actually say yes when the current login still works? That question matters because many passkey rollouts underperform for reasons that have nothing to do with cryptography. The pattern across real deployments is pretty consistent: users adopt when the benefit is obvious, the timing makes sense, and the first attempt succeeds. A few case studies in the source material make that painfully clear. MakeMyTrip changed its prompt from “Create a passkey” to “Skip OTP next time” and got 2x enrollment. eBay moved the prompt from settings to right after biometric login and saw 102% higher enrollment. Same technology. Better wording and timing. The prompt should name the pain removed Most non-technical users are not asking about phishing resistance or FIDO standards. They are asking practical questions: what is this? does my fingerprint get sent to the website? what happens if I lose my phone? do I need to remember something new? That changes how passkey enrollment prompt wording should work. Lead with the outcome, not the mechanism. Better: Skip the code next time Sign in with your face or fingerprint Log in without waiting for an SMS Worse: Create a passkey Enable passwordless login Set up FIDO2 authentication The lesson is simple: if the user has two seconds, spend them on the friction you remove. Timing beats explanation One of the more useful takeaways from the source is that education has limits. A healthcare trial found that an explanation-heavy nudge raised adoption from 18.5% to 33.2%, but the stronger result came from making the passkey button visually dominant: 46.2%. That does not mean copy is useless. It means copy cannot rescue a badly timed prompt. The highest-leverage moments are usually: right after login success right after OTP or password friction during recovery, when the old method has already become annoying This is why post-login passkey nudges and passkey UX timing after OTP friction matter so much more than a passive settings page. eBay got 75% of new passkeys from the login-flow prompt and only 10% from settings. Uber found more than 90% of enrollments came from inline nudges inside login and signup. If you ask in a calm moment, users wonder why they should change. If you ask after friction, the value is already obvious. Product changes matter more than better copy Some of the biggest adoption gains come from changing the flow itself. Change Why it helps Tradeoff Conditional Create passkeys Creates a passkey in the background after password manager use Can feel invisible unless the next login is clearly better Automatic append after successful login Uses a moment when identity is already proven Native dialogs can feel intrusive if shown without warning Identifier-first login passkeys Avoids sending users into a dead-end “no passkeys available” dialog Adds one step for users who do have a passkey Suppression + visible fallback Prevents prompts on devices likely to fail Fallback remains available, so some users will keep using it This is also where passkey recovery after lost phone becomes decisive. You should only promise the recovery path your service really supports. “You can still recover your account if you lose your phone” is useful if it is true. “The old way will always work” is risky if product policy may change later. Observability is what turns advice into rollout decisions A lot of passkey advice sounds good until you try it on real users. Then you find device-specific failures, broken credential manager paths, or cohorts that never should have seen the prompt at all. That is where authentication observability passkeys becomes practical, not theoretical. If you cannot see which browser, OS, or authenticator caused abandonment, you are mostly guessing about prompt wording, placement, and suppression rules. Corbado is a passkey observability and adoption platform for large B2C enterprises. The useful mindset here is not “how do we explain passkeys better?” It is “which users saw which prompt on which device, and what happened next?” What to optimize first If I had to prioritize one thing, I would start with this: stop treating passkey adoption non-technical users as a messaging problem only. Start with the post-login and post-friction surfaces. Replace technical wording with concrete benefit language. Avoid passkey buttons that can open into failure. Make recovery visible. Then measure where ceremonies break by device and cohort. That is usually worth more than writing a longer FAQ about public key cryptography. Read the full breakdown.