Passkeys Japan: An Overview [2026]

In 2025, Japan accelerated passkey adoption in response to evolving security challenges. Following a rise in unauthorized access incidents across the financial sector, regulators emphasized that "ID/password-only authentication and even email/SMS one-time passwords are not sufficient" and that stronger authentication methods like passkeys should be prioritized for high-risk financial actions.

The result: over 50 passkey providers live or planned by year-end, 64 organizations in the FIDO Japan Working Group, and a regulatory timeline that gave the industry months, not years, to ship.

But Japan's rapid rollout has also stress-tested the FIDO ecosystem in ways that US/Europe deployments rarely encounter. The combination of high enterprise Windows/Edge share, diverse Android OEM landscape, and strict corporate network policies has exposed edge cases, especially around Android passkey QR codes, iPhone cross-device flows, and multi-device registration, that product teams building for global markets need to understand.

This post covers:

1. Who's live: Rakuten Securities, Nomura Securities, SBI, Monex, and more
2. What triggered it: the regulatory and fraud timeline
3. Why APAC is different: Android vs iPhone fragmentation
4. What breaks: recurring implementation hurdles from the field
5. What to do about it: strategic recommendations

Japanese financial institutions are moving quickly to meet new regulatory expectations. Below is a snapshot of the current landscape as of late 2025.

Status: Live (Passkey authentication mandatory from Nov 29, 2025)

Nomura Securities has made passkey authentication mandatory for all users. Key characteristics:

• Registration via native NOMURA app
• Positions passkeys as phishing-resistant and passwordless for safer transactions
• Known Android issues: Users report "M0902" and "Operation interrupted" errors, particularly on certain Android devices/OS combinations (troubleshooting guide, support resources)

Nomura Support

Status: Live (Introduced Oct 26, 2025)

Rakuten Securities rolled out FIDO2 passkey authentication with strong cross-device support:

• FIDO2 passkey authentication across all trading channels
• Smartphone passkey usable for PC logins via cross-device QR flow
• Strongly recommends migrating to passkeys

Rakuten News

Status: Live/Planned (FIDO since 2021; FIDO2 passkeys by Autumn 2025)

SBI Securities has been an early FIDO adopter and is now transitioning to full passkey support:

• Replacing Password + SMS OTP
• Initial rollout to web, followed by native apps
• Introduced partially as a response to compensation claims from earlier fraud

Impress Watch

Status: Live (Introduced Oct 31, 2025)

Monex Securities launched with broad platform support and explicit security messaging:

• Broad OS support: Windows 11+, macOS 13+, Android 11+, iOS 16+
• Unified experience across Web and App
• Explicitly markets "Phishing Resistance"

Monex Info

Status: In Progress (Autumn–Winter 2025)

PayPay Securities is rolling out passkeys as a strongly recommended optional feature:

• "Strongly Recommended" optional feature
• Adds email alerts for login/withdrawal as a secondary signal
• Covers multiple trading apps and PC sites

Impress Watch

Status: Live (2025)

Recruit ID has implemented passkeys with multi-device support:

• Supports multi-device registration
• Strong warnings against registering credentials on shared/public devices

Recruit Announcement

Status: Suspended (New biometric registration paused, mid-2025)

Acom paused new biometric registration to review and strengthen enrollment security, a cautionary tale: even phishing-resistant authenticators require strong initial enrollment verification to prevent unauthorized access.

Acom FAQ

Status: Planned (Passkey mandatory from Feb 9, 2026)

Mizuho Securities will require passkeys for all critical account operations:

• Required for: transactions, deposits/withdrawals, account changes on ネット倶楽部 and 株アプリ
• Supported: Windows 11 (Edge/Firefox/Chrome), macOS 14+, iOS 17+, Android 10+
• Uses Windows Hello, iCloud Keychain, or Google Password Manager

Mizuho FAQ

Japan's passkey sprint was not a UX trend. It was a defensive response to phishing-led account takeover (ATO) that escalated until regulators intervened directly.

In a January 2025 dialogue document, Japan's Financial Services Agency (FSA) describes phishing damages as a major fraud channel and lists “promotion of the use of passkeys” as a countermeasure (alongside DMARC and faster takedowns). It also notes a joint notice with the National Police Agency issued Dec 24, 2024 to request stronger anti-phishing measures.

By mid-2025, the FSA highlighted "unauthorized access and transactions in Internet transactions for securities accounts" and explicitly stated that ID/password-only authentication is often insufficient against modern threats.

On July 15, 2025, the Japan Securities Dealers Association (JSDA) published a draft revision of its guideline for preventing unauthorized access in internet trading. The draft calls for implementing and requiring (default-on) phishing-resistant MFA for login, withdrawal, and bank-account change flows, explicitly giving passkeys as an example; it also raises the bar on detection/notification and lockout controls. (JSDA draft guideline PDF; coverage)

By December 2025, the FIDO Alliance Japan Working Group had grown to 64 member organizations, with over 50 passkey providers live or planned in Japan, a direct result of the securities-phishing crisis and subsequent regulatory push.

Acom's temporary pause of new biometric registration (mid-2025) is a useful cautionary tale: even phishing-resistant authenticators require strong initial enrollment verification to prevent unauthorized access. (Acom FAQ)

If you ship passkeys into Japan (and broader APAC), you're operating in a more heterogeneous device and network environment than US/Europe testing typically covers.

• Japan traffic is not "mobile-only"; desktop remains significant.
• Enterprise Windows fleets matter, and Edge share is materially higher than in many markets.
• For additional "device reality" context, StatCounter also provides mobile vendor and mobile screen resolution distributions (useful proxies for hardware diversity).
• Android ecosystems are more diverse (OEM + carrier customization), and passkey behavior can depend on the interaction between the OS, the browser, and the platform credential provider layer (e.g., Google Play Services / Credential Manager). The practical result: more variance, more edge cases, and more "works on device A, fails on device B" debugging.
• OEM-Specific Adoption Blockers: Advanced enrollment features like Conditional Create (automatic passkey upgrades) often see significantly lower success rates on "OEM Android" hardware (non-Pixel devices) compared to Google Pixel devices. For instance, many Samsung devices default to Samsung Pass as the primary credential manager, which can block the background creation of passkeys that relies on Google Password Manager integration.
• Credential Manager System Bugs: A significant hurdle on Android 14 is a documented system bug where the Credential Manager API fails to correctly display the passkey selection UI or returns "no credentials found" errors. This issue has disproportionately affected users on OEM hardware, creating unexpected friction during high-stakes financial app rollouts.
• OEM Android Challenges: Independent analysis of recent financial app rollouts has identified authentication challenges on specific Android 14 devices (including popular Samsung Galaxy A, Sony Xperia, and Sharp AQUOS models). These issues typically manifest on non-Google Pixel hardware, as Google's own implementation tends to be more consistent with the latest FIDO standards. See also local support resources for detailed troubleshooting.
• This isn't hypothetical: a 2024 NDSS paper analyzing official OEM security-update datasets shows how many region/country/carrier variants large Android OEMs support at once (e.g., Samsung: ~1,400 unique models of 402 devices across 97 countries and 109 carriers; Xiaomi: 223 devices across 10 regions). The paper also notes this workload can introduce delays (or even failures) in delivering some security updates, meaning patches can reach end users later or unevenly.

As organizations in Japan move from specification to production, several recurring failure modes have emerged. These real-world scenarios illustrate the gap between standard testing and APAC deployment reality.

A service provider accelerates passkey rollout to meet regulatory guidelines, introducing passkeys to all users simultaneously without device-level telemetry.

• The Failure: Teams see "success" on their own test devices but are blind to 3× higher failure rates on fragmented OEM hardware. Users encounter confusion (e.g., unsupported devices, missing platform accounts) and simply drop off, but the bank has no data to explain why or where the friction occurs.

A user tries cross-device passkey authentication (PC ↔ phone) from inside a corporate network or a Japanese home office.

• The Failure: The "happy path" assumes flawless Bluetooth/Hybrid flow connectivity. In reality, corporate proxies frequently block the traffic required for FIDO Hybrid flows. Without robust multi-access point planning, this turns a seamless login into a permanent connectivity barrier.

A previously working flow starts failing after an OS update, or only fails on certain manufacturer devices (Samsung, Sony, Sharp).

• The Failure: Documented Android 14 bugs and OEM-specific defaults (like Samsung Pass) block standardized flows. The passkey provider layer behaves inconsistently across versions, leading to QR code handoff failures or "no credentials found" errors that are impossible to triage without device-specific monitoring.

A service disables password fallbacks too early or fails to secure initial enrollment verification.

• The Failure: If the initial enrollment is insecure (like the Acom case), an attacker with a stolen password registers their own passkey. Conversely, once a bank goes "passwordless" to meet 2025 mandates, any enrollment friction or device failure becomes an absolute user lockout, as there is no legacy safety net to fall back on.

To mitigate the risks identified above, product and security teams must adopt a preventative architecture. We have tried to outline the most important recommendations here:

1. Invest in Authentication Observability and Gradual Rollouts. You must track passkey prompt → completion rates by device, OS, and browser to catch the "3× failure" gap before support tickets arrive.

   • On Web: Phase rollouts by OS version and browser type.
   • On Native: Phase by specific device models (e.g., Pixel first, then OEM manufacturers) to catch regressions early.
   • Monitoring: Continuously monitor storage locations (System vs. Third-Party) to understand lockout risks.

2. Treat Enrollment as a Security Surface. phishing-resistant auth is only as strong as the initial binding. Require step-up verification (eKYC, existing strong factor) before passkey registration to prevent attackers from "hijacking" the move to passwordless.

3. Prepare to go Completely Passwordless. Expect regulatory pressure to accelerate toward a total phase-out of passwords for initial login. This makes solving the technical hurdles mentioned in Section 5 a compliance mandate: once the password fallback is removed, any device-level failure becomes a terminal lockout.

4. Build an APAC-weighted Device Matrix. Samsung, Sony, and Sharp models dominate Japan. If your test matrix is limited, you will ship bugs. Include Japan-heavy OEMs and use the observability data from Recommendation 1 to refine your supported device list in real-time.

5. Architect for Multi-Device and Multi-Access Point Reality. Assume Bluetooth CDA and corporate proxies will fail. Provide clear network requirements and robust fallbacks, such as multi-device registration, to ensure users can authenticate regardless of their environment or access point.

6. Evaluate Hardware Security Keys as a High-Assurance Complement. For users in highly restricted corporate environments or those requiring maximum assurance, hardware security keys (such as YubiKeys) offer a powerful alternative to synced passkeys. These keys provide a physical root-of-trust that works consistently across almost any device, including mobile and legacy desktop fleets, without relying on platform-specific cloud synchronization or Bluetooth connectivity. A robust architecture should allow these hardware-bound authenticators to coexist alongside platform passkeys, giving users the flexibility to choose the "key" that fits their specific access context.

7. Automate Recovery to Prevent Support Bottlenecks. Transitioning to a passwordless model is only sustainable if you have a streamlined recovery process that doesn't reintroduce weak authentication methods. For high-security sectors like Japanese finance, this means moving beyond SMS/email resets to "Smart MFA" recovery, such as selfie-based identity verification or cross-device fallbacks using trusted hardware. Without an automated recovery plan, the initial reduction in password-reset tickets will quickly be offset by a surge in complex passkey-loss support calls.

The bottom line: Japan's experience shows that the gap between "spec compliance" and "works for real users" is wider in APAC than many teams expect. The winners will be the teams that treat device fragmentation and enrollment security as first-class engineering problems, using a dedicated orchestration layer to bridge the gap.

For financial institutions in Japan, the transition to passkeys is no longer a "UX experiment"; it is a critical compliance mandate with immediate impact on fraud rates and operational costs. However, as the recent rollouts have shown, "shipping passkeys" is only the beginning. The real challenge lies in managing the fragmented reality of the Japanese device ecosystem.

Corbado provides a passkey observability and adoption layer that sits on top of your existing identity provider (IDP) and WebAuthn server. We help you bridge the gap between "spec compliance" and "real-world success."

Most banks have sophisticated anti-fraud telemetry but zero visibility into the "frontend-focused" journey of a passkey login.

• The Problem: Your logs might show a "failed login," but they won't tell you if it was a documented Android 14 system bug, a Samsung Pass conflict, or a user cancelling because the UI was confusing.
• The Corbado Solution: We provide auth-native observability that tracks prompt-to-completion rates by specific device model, OS version, and browser. This includes monitoring the usage of hardware security keys vs. synced passkeys, allowing you to see exactly which factor provides the highest success rate for your specific user segments.

A mandatory rollout requires a strategy that adapts to the user's hardware and environment in real-time.

• The Problem: Forcing a single authentication path (like synced passkeys) can fail in corporate environments where cloud sync is disabled or on OEM devices with broken credential managers.
• The Corbado Solution: Our adoption intelligence allows you to define flexible policies that seamlessly integrate both platform passkeys and hardware security keys. You can offer YubiKeys as a premium or high-assurance fallback for users on problematic devices or in restricted networks, ensuring 100% reach without increasing support overhead.

The move to passwordless increases the stakes for account recovery, as there is no legacy fallback for lost devices.

• The Problem: High-friction recovery flows drive users to expensive human-led branch calls or force the reintroduction of insecure SMS/email resets.
• The Corbado Solution: We integrate external recovery solutions and processes based on user behavior. This includes explicitly requesting high-assurance recovery factors, such as hardware security keys or other custom procedures defined by your system, ensuring that even if a user loses their primary device, they can regain access through verified methods that meet Japanese regulatory standards without manual intervention.

Removing the password fallback is the end goal of the 2025 regulatory roadmap, but doing so without data is a terminal risk for user access.

• The Problem: A mandatory rollout that hits a regression on a specific Sony or Sharp device model can result in thousands of immediate account lockouts.
• The Corbado Solution: Our platform allows you to pilot different authenticator types across your user base and phase rollouts by technical environment. If a specific device/OS combination starts failing, you can deactivate it instantly with a device-level kill switch without an app store update.

We understand that for Tier-1 banks, owning your WebAuthn server and user data is non-negotiable for regulatory and security reasons.

• The Corbado Approach: We are not an IDP. You keep your existing stack, your user database, and your security policies. Corbado adds the "intelligence and visibility layer" on top, providing the same forensic visibility into passkey and security key journeys that you expect from your existing SIEM and anti-fraud tools today.

The transition to a phishing-resistant, passwordless future in Japan is inevitable, but it doesn't have to be a support disaster. By combining forensic observability with intelligent adoption strategies, you can meet the FSA's mandatory requirements while maintaining a seamless experience for every user, regardless of their device. Contact us to find out how to integrate our SDKs into your existing solution or plan your rollout.

The questions below reflect the most common passkey-related queries from Japanese users, derived from search trends, support ticket patterns, and community discussions. By phrasing these as natural questions, we address the real intent and confusion users face during the transition.

Common causes: device/browser mismatch (passkey created on specific device won't appear mobile), WebView limitations in apps, or corporate proxies blocking traffic required for cross-device authentication. Try using the same browser/profile where you registered, or open the site in a full system browser instead of an in-app browser.

This generic error typically indicates a communication failure between the browser and the platform authenticator. Ensure your OS and browser are up to date (e.g., latest iOS or Android with updated Play Services).

If you can't access your account, check: (1) you're using the same device/cloud ecosystem where the passkey was created, (2) screen lock (biometric/PIN) is correctly set up on your device, (3) the service hasn't reset its security settings. If completely locked out, use the service's account recovery flow or contact support.

General passkey errors often stem from using outdated browsers or unsupported operating systems. Ensure you are using a modern browser (Chrome, Edge, Safari) on a recent OS version. Also check that your device's clock is synced and you are not in Incognito/Private mode, which can sometimes interfere with passkey storage or retrieval.

If the passkey prompt doesn't trigger: verify Bluetooth is enabled (mandatory for cross-device/QR code flows), check that the site is using HTTPS, and ensure no browser extensions (like ad blockers or password managers) are conflicting with the WebAuthn call. Restarting the browser or device often resolves temporary stalls.

The system passkey dialog may not appear if: you are in a WebView (in-app browser) that doesn't support WebAuthn, the platform Credential Manager is disabled, or the passkey exists in a different profile. On Android, verify that Google Play Services is running and the correct Google account is selected in the passkey UI.

The "spinning" state often means the browser is waiting for a connection to the authenticator device via Bluetooth (for cross-device flows) or waiting for user interaction. If using a local passkey, the biometric prompt might be hidden behind another window or another prompt is still open.

This error appears when the flow is cancelled explicitly by the user, times out, or loses focus. Retry the authentication immediately. Ensure you complete the biometric verification prompt quickly and avoid switching apps or letting the screen sleep during the process. Nomura Securities users on Android have reported this error frequently since the Nov 2025 mandatory rollout, often linked to device/OS compatibility issues (detailed analysis).

Synced passkeys (iCloud Keychain, Google Password Manager) transfer automatically when you sign into your new device with the same cloud account. Device-bound passkeys (e.g., YubiKey or non-synced platform credentials) do not transfer. You must register a new passkey on the new device before wiping the old one.

Proper deletion is a two-step process: (1) Remove the passkey from the service's security settings page to prevent it from being requested, and (2) delete the credential from your device's passkey manager (iCloud Keychain, Google Password Manager, etc.) to clean up your local storage.

"Transfer" is a misnomer for passkeys. You typically "sync" them via the cloud (Apple/Google) or "register new" ones. If switching ecosystems (e.g., iPhone → Android), you cannot migrate existing passkeys. You must log in (using password or cross-device auth) on the new phone and create a brand new passkey there.

Setup generally follows this flow: (1) Log in to the service, (2) Go to Account/Security settings, (3) Select "Create Passkey", (4) When the system prompt appears, perform biometric/PIN verification. Ensure your device has a screen lock (FaceID, Fingerprint, or PIN) enabled, as passkeys require this underlying security.

For synced passkeys, one registration covers all your devices in that ecosystem (e.g., all your Apple devices). For cross-ecosystem usage (e.g., iPad + Windows PC), you should register a passkey on each platform to avoid relying on QR codes for every login. Most services allow multiple passkeys per account.

If you lose a device with your only passkey: use a fallback method (password, backup codes, email magic link) if available. If the service is "passkey-only," you must go through their identity verification/recovery process. Using synced passkeys reduces this risk since the credential exists on your other devices or cloud account.

Passkeys are strictly bound to the user's personal cloud accounts, making digital inheritance extremely difficult. Unlike a written-down password, a family member cannot just "use" a passkey. Services are beginning to establish legal processes for account access by next of kin, but this remains a complex friction point.

Android passkeys rely on Google Password Manager and Google Play Services. Experience can vary by manufacturer (Samsung, Sony, Sharp, etc.). For cross-device (QR) flows, use the system-provided scanner or Google Lens if the OEM camera app fails to recognize the FIDO QR code.

Passkeys on iPhone are integrated into iCloud Keychain. They work consistently across iOS and macOS devices signed into the same Apple ID. Ensure "iCloud Keychain" and "AutoFill Passwords & Passkeys" are enabled in your Settings.

Windows 11 provides native passkey management via Windows Hello. Passkeys can be stored locally (protected by Face/Fingerprint/PIN) or synced via a browser profile (e.g., Google Account in Chrome). On corporate PCs, IT policy may restrict Windows Hello usage, forcing reliance on mobile-device auth (QR code) or security keys.

Elderly users often struggle with the concept of "no password" or the mechanics of QR code scanning. While newer senior-friendly smartphones running modern Android may technically support passkeys, the UX barrier is high. Family assistance is often required for setup. Services should strictly maintain alternative login methods for this demographic.

A passkey is a secure digital key stored on your device that replaces a password. Instead of typing a secret, you unlock your device (face, finger, PIN) to prove it's you. The website never sees your private key, making passkeys resistant to leaks and phishing.

Passkeys are significantly more secure than passwords because they are phishing-resistant (cannot be tricked into logging into a fake site) and unique (no reused credentials). However, security depends on the initial enrollment: if an attacker has your password, they could potentially register their own passkey before you do.

Main disadvantages: (1) Device dependency: if you lose access to your cloud account or devices, lockout risk is real; (2) Shared device friction: passkeys are personal and don't work well on shared family/public computers; (3) Account aggregation issues: account aggregation services (like MoneyForward and others) that rely on legacy integration methods may face connectivity challenges if a bank switches to passkey-only without offering a dedicated API; (4) Corporate network blocking of cross-device protocols.