As far as Nikkei has said, nobody broke in. Someone logged in, with valid credentials, to a system that wasn’t the company’s main website or customer platform. Here’s the story, and a practical plan, with no daft jargon.
What happened?
On Friday 16 October, Nikkei Inc., the Tokyo-based publisher of The Nikkei newspaper, said that a cloud service it uses for system development had been accessed without authorisation, and that as of that day about 1.83 million items of personal information had been leaked (Nikkei). Its notice breaks the figure down like this:
About 150,000 items contained one or more of: name, email address, postal address, phone number or date of birth (Nikkei).
About 120,000 of those included an email address (Nikkei).
About 1.68 million items contained only identifiers that can’t identify a person on their own (Nikkei, in Japanese).
No credit card information was included in any of the leaked data (Nikkei).
On how it happened, Nikkei says the credentials used to access the cloud service “were stolen by unknown means”. The unauthorised access ran from the early hours to the morning of 7 October, personal information stored in the cloud was leaked, and Nikkei has since disabled the credentials that were used (Nikkei).
Nikkei reported the incident to Japan’s data protection regulator, the Personal Information Protection Commission, on 11 October. As of 16 October it had found no misuse of the leaked data, and no system outages or data tampering. It says it will contact each person whose data is confirmed as leaked, and is still working out the full scope and cause (Nikkei). ITmedia and Kyodo News report the same account (ITmedia) (Kyodo News).
What’s confirmed, what isn’t, and what we infer
Confirmed: everything in the section above comes from Nikkei’s own notice. Not said publicly (as of 17 October): which cloud service or provider was involved; how the credentials were stolen; whether that account had multi-factor authentication (MFA); when Nikkei discovered the access; what the system was being developed for, or whose data it held; and what the 1.68 million “identifier only” items are. Nikkei hasn’t named anyone responsible, and we found no public claim of responsibility in the coverage we checked.
What we infer (our view, not Nikkei’s): personal information was being stored in a cloud service used for development work. In our experience, development and test systems often get less day-to-day attention than live ones, so their logins can be easier to overlook. We don’t know whether that was a factor here, and we’re not suggesting Nikkei was careless.
Not Nikkei’s first login problem this year
On 4 October, Nikkei disclosed two earlier incidents involving staff accounts. An employee’s Microsoft 365 account was used on 30 September to send about 9,000 spoofed emails with links to malicious websites, including to news sources who had been in touch with staff (Nikkei) (The Record). Separately, an employee’s Google Workspace account had been logged into from late July; Nikkei found out in early August from a Google notification, and names and email addresses of 1,646 people may have been exposed (Nikkei, in Japanese) (BleepingComputer). In November 2025, malware on a staff computer leaked Slack credentials, potentially exposing data on 17,368 people (Nikkei).
Nikkei hasn’t said whether any of these incidents are connected (BleepingComputer), and we’re not suggesting they are. But it’s the same pattern as the ASOS breach we covered on 11 October, where ASOS says an attacker impersonated a trusted contact to obtain an employee’s login credentials (ASOS).
Why this matters to you: one password on a forgotten system is enough
Nikkei says there was no outage and no tampering (Nikkei). Nothing obviously broke, because to the system a stolen login looks just like a real one. In a small business, the account at risk is rarely the one everyone uses daily. It’s the trial account from last year, the test copy of the website, the developer’s cloud account, or the SaaS tool nobody owns any more.
1. Turn on MFA for every cloud account, phishing-resistant where you can
The NCSC says to use MFA on any accounts for online services to protect against password guessing and theft (NCSC), and that a password alone is not strong enough to protect sensitive data in cloud-based services. It recommends choosing services that use phishing-resistant MFA by default (NCSC), such as passkeys or security keys, starting with admin accounts. If a service only offers text-message codes, use them: the NCSC says any 2-step verification is better than none (NCSC).
2. List every cloud and SaaS account, including development and test
The NCSC says your access policies should cover not just systems you control, but anywhere your work identities can be used, such as online services staff sign up to with a work email address (NCSC). Check card statements for subscriptions, ask staff, and ask your web developer or IT supplier for every test site, code repository and cloud account they run for you. Note who owns each one and what data it holds.
3. Review who has access, and offboard properly
The NCSC recommends a “joiners, movers and leavers” process so access is removed when it’s no longer needed, regular reviews of accounts for unnecessary privileges, and being able to revoke third-party access when necessary (NCSC). When a member of staff, a freelancer or an agency finishes, work through your list from step 2, not just their email account.
4. Remove unused accounts, keys and tokens
The NCSC says temporary accounts, such as ones created to test processes, should be removed or suspended when no longer needed (NCSC), and that access to code repositories should be revoked swiftly, with access keys rotated (NCSC). API keys, tokens and app connections often keep working long after the person who made them has left. If nobody can say what an account is for, switch it off.
5. Give people only the access they need
Least privilege means each person or system gets the access their job needs, and no more. The NCSC advises using full admin accounts only when absolutely necessary and keeping separate admin and everyday accounts (NCSC). Our own advice: where you can, keep real customer data out of development and test systems and use made-up data instead. A test system can’t leak data that was never in it.
6. Look after passwords and secrets
Use a password manager. The NCSC suggests password managers to cut down how many passwords people must remember, which discourages reuse (NCSC) (NCSC blog).
No shared logins. The NCSC says you should be able to link every action to the person or account that did it (NCSC). A shared login breaks that, and you can’t cut off one leaver without changing it for everyone.
No credentials in code. The NCSC advises keeping secret credentials separate from source code, scanning code repositories for secret keys, and using two-factor authentication on repository accounts (NCSC). Keys belong in a secrets vault, not a script, config file or chat message.
7. Get alerted to unusual sign-ins
The NCSC says sign-in events should be logged and monitored, and lists warning signs such as failed MFA attempts, logins from unexpected places, password-guessing attacks and unexpected lockouts (NCSC). Nikkei learned of its Google Workspace intrusion from a Google notification (Nikkei, in Japanese): make sure your provider’s alerts go to a mailbox someone reads.
8. Know the ICO 72-hour rule
If personal data you’re responsible for is involved, a reportable breach must be reported to the ICO without undue delay and within 72 hours. The clock starts when you discover the breach, not when it happened. Start a log straight away, and if there’s a high risk to the people affected you must tell them too (ICO). Decide now who makes that call.
Your cloud-account checklist
- List every cloud and SaaS account, including development, test and trial ones, each with an owner.
- Turn on MFA everywhere, with passkeys or security keys for admins where possible.
- Review access quarterly and on every leaver; close unused accounts, keys and tokens.
- Cut admin rights back, and keep real customer data out of test systems.
- Use a password manager, end shared logins, and keep credentials out of code.
- Send sign-in alerts to someone who reads them, and agree who reports to the ICO within 72 hours.
References
- Nikkei Inc., “Personal Information Leak Due to Unauthorized Access”, 16 October 2026
- Nikkei Inc., “不正アクセスによる個人情報漏洩について” (Japanese-language notice), 16 October 2026
- ITmedia NEWS, report on the Nikkei leak (in Japanese), Yuka Okada, 16 October 2026
- Kyodo News, “Japan’s Yamato Transport confirms 5.31 mil. customer records leaked”, 16 October 2026
- Nikkei Inc., “Regarding Information Leaks and the Sending of Suspicious Emails…”, October 2026
- The Record, “Japanese media group Nikkei discloses intrusions targeting employees and users”, 5 Oct 2026
- Nikkei Inc., notice on unauthorised Google Workspace login (in Japanese), 4 October 2026
- BleepingComputer, “Nikkei discloses breaches of employees’ Microsoft, Google email accounts”, 6 Oct 2026
- Nikkei Inc., “Unauthorized access and information leak on the ‘Slack’ business chat platform”, 4 November 2025
- ASOS, “Latest ASOS Security Incident Update”, customer information page, viewed 17 October 2026
- National Cyber Security Centre, “10 Steps to Cyber Security: Identity and access management”
- National Cyber Security Centre, “Not all types of MFA are created equal...”, blog post, 9 October 2024
- National Cyber Security Centre, “Setting up 2-Step Verification (2SV)”
- National Cyber Security Centre, “Secure development and deployment guidance: Protect your code repository”
- National Cyber Security Centre, “Trusting the tech: using password managers and passkeys…”, 24 June 2025
- Information Commissioner’s Office, “72 hours – how to respond to a personal data breach”
Need a hand applying any of this to your business? Get in touch — call +44 1472 564538 or email services@msl.org.uk.