After a wave of data breaches in Japan, account takeover comes next: what to review in your sign-in

Since late September 2026, Japanese companies have been disclosing breaches, or possible breaches, of personal data on the scale of millions of records. On October 9 the National Cybersecurity Office (NCO) in the Cabinet Secretariat published a notice asking businesses that handle large volumes of personal data to promptly consider tightening their measures.

A breach announcement is not the end of the damage. Leaked email addresses and names are reused for phishing and fraudulent sign-ins. This article summarises what has been disclosed and what the government asked for, then sets out what to review in the sign-in of your own service.

Based on disclosures and reporting as of October 9, 2026. Figures may change as investigations continue; see the references at the end.

What has happened

On October 9 alone, several companies disclosed breaches or possible breaches. The main ones, as disclosed or reported:

Company	Records (as disclosed or reported)	Main data items
BOOKOFF GROUP HOLDINGS	Up to about 6.43 million (member numbers)	Name, date of birth, email, phone, address, password hashes and more. No payment data
Adventure (skyticket)	About 14.64 million	Name, date of birth, email, phone, address and more; about 4.13 million include hashed login passwords. Card numbers are not stored
JR East / View Card	About 6.09 million in total	Mostly email addresses; for one membership programme also member numbers and dates of birth. No names, addresses or card numbers
JR Kyushu	Up to about 1.3 million	Web members’ email addresses
Suzuki (Suzuki Village)	About 3,000 people	Email, nickname, region and more. No payment data

JR East and JR Kyushu were reported to be affected through unauthorized access to an external cloud service they used, and Suzuki said the server belonged to the contractor running the site. Many leaks came through contractors and cloud providers rather than the companies’ own systems.

Earlier, on September 28, Temairazu, which provides a reservation management system for hotels, disclosed unauthorized access to its system. Guests received suspicious messages that appeared to know their booking details and pushed them to fake sites to re-enter card details or make payments. It is an example of leaked data being used directly for the next fraud.

What the government asked for

The NCO notice, “Responding to cases of leaks caused by unauthorized access”, lists points in three areas for businesses that handle large volumes of personal or sensitive data.

Managing web systems. Treat internet-facing systems on the assumption that they “could be attacked at any time”. Apply patches promptly, stop using unsupported products and run regular vulnerability assessments. Under account management and authentication, it lists multi-factor authentication (MFA), banning easily guessed passwords and disabling unused accounts, along with keeping logs and watching for abnormal authentication attempts from outside.
Supply chain compromise. Check contractors’ and subcontractors’ security continuously, not only at contract time; share the minimum data with them and have it deleted when the work ends.
Data management. Inventory the data you hold and delete what you no longer need. Encrypt stored data and traffic, do not store passwords or credentials in plain text, and check public settings and access permissions in the cloud.

The notice also says attack techniques, including the misuse of AI, are becoming more sophisticated, and asks executives to treat cybersecurity as a management issue, including investment and staffing.

What comes after a breach: account takeover

A leak without card numbers is still a problem. Email addresses, names and dates of birth are used in the following ways.

Convincing phishing

Messages that already know your name, your booking or the fact that you are a member are hard to tell from the real thing. As in the Temairazu case, real details are used to lead people to fake sites that collect passwords or card data. BOOKOFF’s disclosure itself warns members about messages impersonating the group. A password typed into a fake site works on the real one.

Credential stuffing

Most services use the email address as the login ID. Attackers pair lists of leaked email addresses with passwords leaked from other services and try them everywhere. If the user reuses a password, a service with no connection to the breach is opened too. Even hashed passwords can be recovered over time if they are short and easy to guess.

What happens to a taken-over account

Once in, attackers cash out points, buy with saved cards, and change the delivery address or the email address. When the email address is changed, password reset messages no longer reach the real user, and getting the account back becomes hard.

In other words, even if your company was not breached, other companies’ breaches reach your login page. Now is the time to review it.

What to review now

First: patching and monitoring

Preventing the breach itself is the work the government notice lists: fixing vulnerabilities, managing contractors, holding less data and monitoring logs. The authentication measures below do not replace that. Their job is to stop sign-ins that use leaked data.

Measures that assume passwords

Reject easily guessed and known-leaked passwords at sign-up and on password change.
Limit attempts and detect abnormal patterns, not only repeated failures on one account but one source trying many accounts.
Notify users of sign-ins from new devices and of important changes such as password or email changes. Notify the old address when the email address changes.
Hash passwords with a proper algorithm. The notice also asks that passwords and credentials never be stored in plain text.

Multi-factor authentication and its weak point

MFA blocks most fraudulent sign-ins, because a leaked password alone is not enough. But SMS and authenticator-app codes can be entered on a fake site and relayed to the real one in real time. The better the phishing, the more this matters.

Account recovery as a back door

Forgotten-password and email-change flows are easy to overlook. If recovery checks the date of birth or phone number and those have leaked, the check means nothing. A strong sign-in with a weak recovery flow just moves the attack to recovery. Review help-desk identity checks and resets that complete by email alone.

Passkeys to cut off account takeover

Passkeys sign users in with device biometrics using public-key cryptography. Two properties matter against account takeover:

Phishing resistance. The signature is bound to the site’s domain, and the browser will not use the key on a fake site. Even if the user opens a fake site, there is no code or password to copy.
No reusable secret on the server. The service stores only public keys; private keys never leave the user’s device. A leaked database yields nothing that can be used to sign in, and reuse cannot happen.

Passkeys do not prevent intrusion into your servers. If email addresses and names leak, phishing messages will still arrive. What passkeys cut off is the account takeover that follows. Keep the two roles separate.

How to proceed

You do not need to rebuild your login at once. The practical route is to keep the current login and add passkeys alongside it, then encourage users to register.

Add passkeys as an option, from the settings page or a prompt right after sign-in.
Protect enrolment. Accept passkey registration only from a verified session; otherwise an attacker with a stolen password can register their own passkey.
Decide on recovery for users who lose their device before you launch.
Set a date to retire passwords, and phase out password-only sign-in as registrations grow.

How passkeys work and how widely they are used is covered in “What passkeys are, why they took off, and how to add them to an existing service”, and the rollout steps in “How to roll out passkeys”.

SHANNON provides SealGate, a passkey platform that adds passkeys to an existing login. It offers registration, authentication, revocation and recovery through an API, and stores only the mapping between a public key and a user ID.