This is the third post in our series on passkeys and phishing-resistant accounts at Mercari. The earlier posts are: Mercari’s Passkey Adoption (2023) and Mercari Phishing-Resistant Accounts with Passkey (2025).
Background: A Recap of Our Journey So Far
Since 2021, we have been growing the number of phishing-resistant accounts at Mercari — accounts built on passkeys (passkey registration required, authentication only with passkeys, and recovery only through high-assurance identity proofing) that are structurally prevent phishing attacks. Today, around 13 million users have registered a passkey. For the full story, see our previous post.
This worked. Where passkeys are required, large-scale phishing financial damages have been effectively zero; even where passkeys are optional, losses dropped sharply as adoption grew. But enforcing phishing-resistant accounts in their pure form comes at a cost to the user experience: users who cannot register a passkey abandon the service, and users who lose access to theirs get locked out, which turns directly into support inquiries.
That leaves us in a bind. To stop phishing, accounts must be phishing-resistant. But users will not migrate to using if the experience is unacceptable. So password-dependent users and services do not go away, and phishing losses never fully stop. This post is about what comes next. On one side are password-dependent accounts. On the other side are passkey-only accounts. Between them is a large gap, and an all-or-nothing requirement does nothing to close it. How we bridged that gap is the subject of this post.
Bridging the Gap with a Credential Migration Spectrum
Our response was to stop treating an account as either password-dependent or passkey-only. Instead, we model it as a spectrum of states. Users move along the spectrum step by step, rather than crossing the gap in one jump.
| State | Description |
|---|---|
| Password or Email Link | Available factors: Password or email link The traditional, password-dependent state |
| Email Link | Available factors: Email link Password disabled; an intermediate state |
| Passkey or Email Link | Available factors: Passkey or email link Passkey registered, with email link as a fallback |
| Passkey | Available factors: Passkey only Fully phishing-resistant |
There are three things that makes the migration along this spectrum.
The email link lets us drop the password. An email link (An email link — sometimes called a "magic link" — signs the user in via a one-time link sent to their registered email address; control of the mailbox proves identity) is not as strong as a passkey, but it is more phishing-resistant than a password. Even for users who cannot or will not register a passkey, it lets us remove the weakest factor — the password — moving an account from Red (Password or Email Link) to Green (Email Link). Even when an account never reaches the Blue (Passkey-only), removing the password already reduces phishing risk.
The fallback lowers the barrier to adopting passkeys. In the second intermediate state, keeping the email link available is also what lets us promote passkey
registration without hurting the experience. Users can add a passkey with confidence because they do not have to worry about locking themselves out, allowing them to reach
the Green "Passkey or Email Link" state, which offers a better UX.
Risk-based authentication secures the bridge. At each transition between states — from Red toward Blue — we evaluate risk and decide whether to disable a weaker factor and advance the account. This lets us move only the users who can move safely, and only when it is safe to do so.
The goal is not to move everyone to passkeys at once. It is to nudge each account toward stronger phishing resistance, little by little, according to risk. Removing the weakest factor — the password — is only the first step. We do not need to complete the full migration right away: every move toward a more phishing-resistant state reduces losses.
Assessing Risk Signals
At each point where we decide whether to disable a weaker factor, we evaluate risk along two axes, which we call postures.
Session posture is gathered from the device or network during a particular onboarding session. It includes client integrity, network reputation, and device and user-agent properties.
Account posture is bound to the account’s capabilities and accrues over its lifecycle. It includes the account’s authentication capabilities, its identity verification history, and its historical behavioral patterns.
We combine these signals into a single weighted verdict and use it to decide whether to advance the account. The session-side signals are produced by a risk engine based on device and session fingerprinting: it recommends more phishing-resistant factors in higher-risk environments, and it lets us phase out weaker factors starting with the riskiest environments first.
The weighting is deliberately asymmetric, because the threats differ depending on which factor we are disabling:
- Disabling passwords defends against credential theft and password spraying and stuffing. These attacks show strong session-level signals, so this decision leans on session posture.
- Disabling email links defends against email-provider account takeover and the UX degradation that comes from enforcing passkeys. Accounts that already hold a passkey have a strong baseline, so this decision leans on account posture.
The action is the same — disabling a weaker factor — but the signals that justify it depend on the situation.
Applying Risk-Based Migration to Login
We applied this approach to the login flow first.
After a user identifies their account with an email address or phone number, we evaluate the risk score and respond in three steps:
- Disabling passwords. We restrict the password path with risk-based authentication in higher-risk sessions, and guide the user to email link login instead.
- Passkey upsell. After a successful login, we promote passkey registration — through an automatic passkey upgrade during password login, and through an explicit registration prompt after email link login. The password is permanently disabled once a passkey is registered. The email link remains as a fallback.
- Disabling email links. We restrict the email for accounts that meet the risk threshold, guiding the user to passkey-only login.
The same login screen serves every state on the spectrum; what changes is which paths risk-based authentication allows.
Applying Risk-Based Migration to Account Recovery
The second place we applied this approach is account recovery. Recovery matters here because it is where users would otherwise fall back to a password.
Recovery is for users who have lost their password or passkey and cannot be reached by email or phone. We provide self-service recovery based on high-assurance identity proofing, using either My Number Card (Japan’s national digital identity, via its certification function) or document-based identity verification with a selfie.
After identity proofing passes, the recoverable information is the passkey, email address, and phone number. We do not restore passwords. A recovered account therefore re-enters the spectrum at the email-link state or beyond, never back at the password-dependent state. And because we prompt passkey registration during recovery, recovery itself becomes a force that drives migration forward.
Putting It Together
Login and recovery are not two separate efforts — they are two surfaces of the same migration. Across the account lifecycle there are several points where risk-based authentication can act, and every one of them pushes the account in the same direction: toward stronger phishing resistance, never back toward weaker factors. At login, we restrict passwords, promote passkeys after a successful login, register passkeys through automatic passkey upgrade, and restrict email links. During recovery we disable passwords and promote passkeys. Taken together, these levers turn everyday authentication into a single, one-way migration toward phishing-resistant accounts.
Where We’re Headed Next
From here, we are pursuing two main goals: going password less and mandating passkeys.
Going Password less
First, we are rebuilding the registration flow so that new accounts can start without a password at all, using email links or passkeys from the beginning. This keeps new "Red" (password-dependent) accounts from being created in the first place.
Afterwards we will continue to tune our risk thresholds, tightening them over time. This lets us ultimately remove passwords across the entire service.
Mandating Passkeys
The move from Green to Blue — disabling the email link so that only passkeys remain — comes with a real cost to the user experience. For that reason, we will take this slowly. In step with other companies, users, and society as a whole growing more familiar with passkeys, we expect to raise the threshold over a span of years.
In the meantime, we should be able to reshape this end goal into something with an even better user experience if new phishing-resistant authentication factors — for example, phishing-resistant phone-number verification or email verification — become genuinely available. That is something we are looking forward to.
Conclusion
To stop phishing losses, phishing-resistant accounts are essential. But if the experience is unacceptable, people will not use them, and the risk of phishing continues. A pure, all-or-nothing requirement runs straight into that wall.
Risk-based adaptive authentication bridges the gap between passwords and passkeys. We can reduce phishing losses without waiting for a complete migration by modeling accounts as a spectrum, phasing out weak, phishable factors according to risk, and guiding users toward more phishing-resistant states. And we can do this without the users walking away because of degraded experience. We intend to continue driving credential migration toward even better phishing resistance.
