Background
Why Mercari Is a High-Value Target for Phishing Attacks
Mercari is a comprehensive consumer service ecosystem that integrates multiple offerings into a single native application. Users can access our C2C marketplace, Merpay payment services, Mercoin (cryptocurrency exchange), and Mercari Mobile all from one app.
While this architecture provides a seamless user experience, it also creates a significant security challenge. If attackers compromise a user’s credentials, they gain access to all services simultaneously. With each service requiring different security levels, this consolidation makes Mercari one of the most attractive targets for phishing attacks.
The Evolution of Mercari’s Passkey Strategy
To prevent phishing attacks, Mercari began introducing passkeys. In our 2023 blog post, we shared our initial passkey adoption. At that time, we had three main goals: to improve the sign-in user experience, reduce SMS One-Time Password (OTP) costs, and strengthen phishing protection. However, since then, our approach has evolved significantly.
The critical change is that once users register a passkey, they can no longer authenticate with passwords or SMS OTP. Once passkeys are enabled, these phishing-vulnerable authentication methods are completely removed from their account. It then functions as a phishing-resistant account, which we call a passkey account.
This change also transformed the purpose of Mercari’s passkey deployment. While initially focused on protecting Mercoin features, we now aim to protect all product features from phishing attacks. In other words, rather than simply offering passkeys as an alternative authentication method, we are now creating phishing-resistant accounts.
This distinction is important. Our goal is not just to encourage passkey usage, but to systematically eliminate phishing attack vectors from our service.
Mercari’s Passkey Deployment
Transition to Phishing-Resistant Accounts
At Mercari, our passkey deployment is based on maintaining two types of accounts: passkey accounts which are resistant to phishing attacks, and traditional accounts which are not. Our goal is to gradually migrate all users from traditional accounts to passkey accounts.
With traditional accounts, users can authenticate using password + SMS OTP and leverage social login. If users forget their passwords, they can recover access through email magic links or contact customer service for identity proofing and account recovery. When users register a passkey on a password account, they automatically migrate to a passkey account. This migration was initially required to use certain features, particularly Mercoin features.
Passkey accounts operate under different constraints. Users can authenticate with passkeys, but password and SMS OTP authentication are completely disabled. When users lose their passkey, email magic links are also unavailable since they represent a phishing risk. The only recovery path is contacting customer service for manual identity proofing.
For the time being, social login is allowed because there have been no phishing attacks targeting it so far. For now, we prioritize convenience. However, to achieve fully phishing-resistant accounts, we will need to reconsider social login as well.
The Core Challenge
This all sounds great, but this strict security posture also creates two interconnected problems.
First, when users lose their passkey, the passkey account user experience degrades significantly. Without social login configured, they cannot access their account at all and must wait days or even weeks for customer service resolution through text-based communication.
Second, this poor user experience makes product owners reluctant to require passkey accounts as a precondition for their services. As a result, a lot of users remain on traditional accounts and continue to be vulnerable to phishing attacks.
We face a circular problem. We cannot eliminate traditional accounts until the passkey account experience improves, but phishing attacks continue while we work on improvements.
Improving the UX of Passkey Accounts
Passkey Recovery with High Assurance Identity Proofing
The way to improve the UX of passkey accounts is to enable users to recover their passkeys by themselves. This removes the need for users to contact customer support when they lose access. To achieve this, we adopted a self-service identity proofing approach using Japan’s MyNumber digital ID card for passkey recovery. Over 80% of Japanese residents now possess this government-issued card for identity proofing purposes. The card contains an IC chip with a digital certificate embedding verified user attributes: name, date of birth, and address, and so on.
The process of verifying the user’s identity through the MyNymber card has two important characteristics. First, the cryptographic structure allows us to verify that the certificate was issued by the government, making it difficult to counterfeit. This can be used to validate authenticity. Second, using the MyNumber card requires a PIN, which functions as an activation secret that prevents misuse of stolen cards. This can be used to verify the card holder.
The recovery flow is straightforward. Users input their email address or phone number to identify their account. Our system compares the attributes from their MyNumber card with the information registered on their account. If the user’s attributes match perfectly, users can register a new passkey and immediately regain access.
This approach transformed our security model. We replaced email magic links with cryptographically verifiable government-issued identity, enabling self-service recovery while maintaining our phishing-resistant policy.
Future Directions
While high assurance identity proofing solved the recovery problem, users could still face login challenges on devices that don’t support passkeys. We are exploring alternative authentication methods, which were chosen based on their risk assessment results, to allow users to login without passkeys.
The core question is: which authentication methods can we accept, and under what conditions? Traditional authentication methods like passwords and SMS OTP remain unacceptable because they are vulnerable to phishing. But what about push notifications, QR codes, or email magic links? Each has exploitable weaknesses. Attackers can prompt users to approve push notifications, reconstruct QR codes on phishing sites, or social engineer users to forward magic link emails. In reality, no alternative authentication method exists with strength equal to passkeys.
Our current thinking centers on decision making based on their risk assessment results. We calculate a risk score for each login attempt and adjust acceptable methods accordingly. For high-risk scenarios, we permit only passkeys and social login. For low-risk situations, we may accept alternative methods despite their inherent vulnerabilities.
When an account is expected to be phishing-resistant, it is not ideal to allow other authentication methods, even if we have made the decision to provide them after reviewing their risks. However, we see this as an important step toward fully migrating to phishing-resistant accounts. This is still an ongoing discussion within our team, and we plan to share updates once the feature goes live in production.
We are also evaluating additional KYC methods beyond MyNumber cards, including other identity proofing approaches and digital credential APIs. The goal is to expand high assurance identity proofing to users who lack government-issued digital IDs while maintaining our security standards.
Increasing the Number of Passkey Accounts
Improving passkey account UX addresses one dimension of our challenge, but we must also actively grow adoption. But why is growth difficult?
From the product owner’s perspective, passkey account UX is not good enough to make it a service requirement. From the user’s perspective, they don’t know what passkeys are or how to set them up, so they take no action. To address these challenges, we pursue two complementary approaches.
Promoting Adoption Through Awareness
First, we make broad appeals to all users to spread the word about passkey accounts and how to set them up. We tested multiple approaches. We conducted promotional campaigns explaining passkey benefits through push notifications and email, but the effect was limited. We also tried prompting users to register passkeys immediately after they logged in with password and SMS OTP, but attackers exploited this feature to compromise accounts and register their own passkeys, so we discontinued this approach.
The most effective method was utilizing the status feature and TODO list. By displaying "Passkey Settings" on the account TODO list, we provided a continuous reminder for users to switch to passkeys. These naturally recommended passkey registration as part of users’ regular workflow, proving more effective than promotional campaigns or intrusive prompts.
Setting Risk-Based Requirements
Second, we discussed with product owners to identify appropriate contexts for mandating passkey accounts based on risk. For example Mercari group has launched new services such as Mercari NFT, a marketplace for non-fungible tokens (NFTs), and Mercari Mobile, which offers MVNO (mobile virtual network operator) services. For Mercari NFT, we allowed traditional accounts for low-value NFT purchases but required migration to passkey accounts for high-value NFT purchases. For Mercari Mobile, passkey accounts were required for SIM card contracts. These risk-based requirements are gradually expanding our passkey account base while respecting product constraints.
Current Progress and Future Plans
As a result of these efforts, we reached 10.9 million passkey accounts as of September 2025. This represents approximately half of our monthly active users. Authentication method usage has shifted dramatically. Before passkey adoption, 75% of logins used passwords. Currently, passkeys account for 31.6%, passwords 44.3%, and email magic links 4.1%. We expect passkey authentication to surpass password authentication next year.
In the future, we are considering making passkeys mandatory in existing services and implementing Automatic passkey upgrade. Automatic passkey upgrade is a powerful technique where passkeys are created without strong user awareness, but since passkey registration changes the login experience, UX improvement is essential.
Because traditional accounts and passkey accounts offer different user experiences, and passkey account UX currently remains inferior when users lose their passkeys, we plan to implement these measures only after completing passkey account UX improvements.
Summary
Mercari’s passkey deployment strategy aimed to prevent acts of phishing stands out from other implementations currently available elsewhere. Rather than offering passkeys as an optional authentication method, we create phishing-resistant accounts that systematically eliminate password-based authentication.
We created phishing-resistant "passkey accounts," improved passkey account UX through high assurance identity proofing and risk-based authentication to gradually drive migration, and will ultimately eliminate traditional accounts to eradicate phishing attacks. This architectural decision creates unique UX challenges that we address through high assurance identity proofing and risk-based authentication strategies.
Our progress demonstrates that phishing-resistant authentication is achievable at scale for consumer applications. This path requires that we invest in both security infrastructure and user experience at the same time, and we must balance these through risk-based product requirements. As we continue improving passkey account UX and expanding adoption, we move closer to our ultimate goal: eliminating traditional accounts and saying goodbye to phishing attacks at Mercari.
