Migrating an Existing User Base to Passwordless

Building passwordless into a new product is straightforward. Migrating a product that already has two million password-based accounts is a different problem entirely, and it is mostly not a technical one.

The technical work — implementing WebAuthn, adding magic links — is a few weeks. The migration is a year, and it fails for reasons that have nothing to do with the cryptography: users who ignore the prompt, a recovery flow that quietly reintroduces the password you were trying to remove, and a long tail of accounts on devices that will never support the new thing.

This article is about the migration, not the implementation.

Decide what "passwordless" means for you

The word covers several different products, and they have different migration profiles. Choose deliberately.

Magic links — a signed link mailed to the user. Zero enrollment friction, works everywhere, and moves your security posture entirely onto the user's mailbox. Phishable. Easiest migration by a wide margin.

Email or SMS OTP — a code the user types. Same trust model as magic links, better on mobile because the flow does not leave the app, worse for SMS specifically because of cost and delivery problems.

Passkeys / WebAuthn — a device-bound credential unlocked by biometrics. Phishing-resistant, genuinely better than passwords on every security axis, and the only option here that is a real improvement rather than a relocation of the problem. Also the one with meaningful enrollment friction and device-support caveats.

Most successful migrations use passkeys as the destination and magic links or OTP as the universal fallback. The important thing to be clear-eyed about: magic links are not more secure than passwords — they trade "something you know" for "access to a mailbox," and the mailbox is usually protected by a password. They are more convenient, and convenience is a legitimate goal. Do not tell your security team you improved the threat model when you moved it.

The phases

A migration that works looks roughly like this, and the ordering is not arbitrary.

Phase 1 — quietly available. Ship it in account settings. No prompts, no banners. The goal is to find the bugs with the small population of users who go looking for new settings, before you show it to everyone. Instrument enrollment failures heavily; this is where you discover that a particular browser-and-password-manager combination silently fails.

Phase 2 — promote at the right moment. This is the phase that determines whether the migration succeeds, and the moment matters more than the message. The best moment is immediately after a successful login, when the user has just proved who they are, is not in the middle of a task, and has just experienced the friction you are offering to remove. "That took a while. Next time, sign in with your fingerprint?" converts far better than a banner in settings.

The second-best moment is after a password reset — the user has just been maximally inconvenienced by passwords and is unusually receptive.

The worst moment is before login, or interrupting a task. An interstitial between the user and the thing they came to do gets dismissed, and a dismissal trains them to dismiss it next time.

Phase 3 — new accounts default to passwordless. No migration needed, and it stops the problem growing. Do this as early as the flow is solid; every day you delay adds accounts to the migration backlog.

Phase 4 — retire passwords, selectively. For accounts with a working passkey on more than one device, remove the password credential entirely. This is the only phase that actually delivers the security benefit, and it is the one most migrations never reach.

The recovery trap

Here is the failure that quietly nullifies most passwordless migrations.

A user enrolls a passkey. Six months later they lose their phone. They click "I can't sign in." Your recovery flow emails them a link, which lets them set a new password, which they use to sign in.

The password never went away. It was sitting behind a recovery flow the whole time, and the account's real security level is the security of that flow — which is email access, which is what you were trying to move away from. Worse, an attacker attacking this account does not bother with the passkey at all. They attack the recovery path, because it is the weakest one, and it always was.

This is the single most important thing to get right, and it is the part that is hardest.

Enroll a second factor at the same time as the first. The single strongest mitigation. If a user enrolls a passkey on their phone, prompt immediately to add one on their laptop. Two devices means losing one is an inconvenience, not a lockout, and it removes most of the pressure on the recovery flow.

Generate recovery codes at enrollment, and make the user store them. One-time codes, shown once, hashed at rest. Not glamorous, and it is the mechanism that lets you make recovery strong without making it impossible.

Make recovery harder than login, not easier. If recovery is one email click and login is a biometric, you have built a system where the front door is stronger than the back door and attackers use the back door. Recovery should require multiple signals — a verified email and a recognized device, or a waiting period, or an out-of-band confirmation.

Consider a deliberate delay for high-value accounts. A 24-hour hold on account recovery, with notification to every registered contact and an opportunity to cancel, is unpopular and extremely effective. It converts a silent takeover into one the owner has a day to stop.

Lean on platform sync. Passkeys synced through iCloud Keychain, Google Password Manager, or a third-party manager survive device loss entirely, because the credential is backed up. This dramatically reduces recovery volume and is the strongest practical argument for synced passkeys over device-bound ones for consumer products.

Dual-mode is where you will live

For a long time — years, realistically — you will support both. Design for that rather than treating it as a temporary state.

The login screen leads with identifier-first. Ask for the email, then present the methods available for that account. This is what makes a mixed population coherent: a user with a passkey sees a passkey prompt; a user without one sees a password field. Nobody sees a screen full of options that do not apply to them.

Support conditional UI (autofill). WebAuthn's conditional mediation lets the browser offer the passkey in the username field's autofill dropdown, before the user has done anything. It is the difference between passkeys feeling magical and feeling like an extra step, and it is a small implementation detail with an outsized effect on adoption.

Never remove the password until a replacement is proven. Proven means: enrolled, and successfully used at least once, ideally on more than one device. An enrollment that was never exercised is not evidence.

Handle the account with three methods. Passkey on a laptop, password, and a magic link fallback. Each is a full authentication path, and each is a potential entry point. The account's security is the weakest of them — so the audit log should record which method was used, and your risk scoring should treat a fallback-method login on an account with a passkey as mildly anomalous.

Setting a realistic target

Adoption is slower than anyone plans for. Some honest expectations:

• Voluntary enrollment via settings alone: low single digits. Nobody visits settings.
• Well-timed post-login prompting: 15–40% over several months, heavily dependent on your user base's device mix.
• Enforcement for a defined segment (employees, admins, high-value accounts): near 100%, with a support cost.
• Full retirement of passwords across a consumer base: not achievable in the medium term. Plan for a permanent fallback.

Segment your measurement, because the aggregate hides everything. Enrollment rates differ enormously between mobile and desktop, between platforms, and between user cohorts. A 20% overall number might be 45% on iOS and 4% on desktop Windows — and those two facts imply completely different next steps.

Track these specifically:

• Enrollment rate, by platform and browser.
• Enrollment abandonment — how many users start the ceremony and do not finish. High abandonment usually means the prompt appeared at a bad moment or the copy did not explain what was about to happen.
• Authentication success rate by method. If passkey login fails more often than password login, adoption will reverse.
• Fallback usage among enrolled users. A user with a passkey who keeps using their password is telling you the passkey path is broken or hidden.
• Support ticket volume, by category. This is the real cost.

The long tail

Some users will never migrate, and it is worth knowing who they are before you plan enforcement.

Shared or kiosk machines where no credential can be stored. Corporate environments where the platform authenticator is disabled by policy. Users on old devices, or on browsers without WebAuthn support. Accounts shared between people — against your terms of service, and common. Users who genuinely do not want biometrics on their device, which is a legitimate position.

For each of these, the answer is a fallback, not a fight. What you should not do is let the long tail block the migration for everyone else. Enforce where you can — internal accounts, admin roles, new signups, high-value tiers — and keep a well-secured fallback for the rest. A migration that gets 40% of accounts onto phishing-resistant credentials, including 100% of the privileged ones, is a large security win even though it is not the clean story anyone wanted.

What to communicate

Users are being asked to change how they log in, which is the most anxiety-inducing change you can make to a product. The copy matters.

Say what happens, not what it is. "Sign in with your fingerprint instead of typing a password" beats any sentence containing the word WebAuthn.

Say what happens if they lose the device, at enrollment. This is the question everyone has and nobody asks, and answering it up front removes the main hesitation.

Do not use security fear as the pitch. "Your password could be stolen" produces anxiety and inaction. "Sign in in one second" produces enrollment.

Make the dismissal honest. "Not now" should mean not now, and you should ask again later — but a prompt that reappears every single session gets muted permanently. Space it out, and respect a second dismissal.

Key takeaways

• Choose the destination deliberately. Magic links relocate the risk to the mailbox; passkeys actually reduce it.
• Promote immediately after a successful login or a password reset — never interrupting a task.
• The recovery flow is the migration. If recovery restores a password, the password never left and the attacker will use that path.
• Enroll a second device or recovery codes at the same time as the first credential. This is what makes strong recovery possible.
• Ship identifier-first login and conditional UI; plan to live in dual-mode for years.
• Never remove a password until the replacement has been used successfully, ideally on two devices.
• Measure by platform and cohort; the aggregate number hides the actionable finding.
• Enforce where you can, keep a fallback for the tail, and count a partial migration as a real win.