Nikkei Data Breach: 1.83 Million Records Exposed After Attackers Used Stolen Cloud Credentials

On October 20, Japanese media giant Nikkei — owner of The Nikkei newspaper and the Financial Times — disclosed that attackers had broken into a cloud service it uses for system development on the morning of October 7, using previously stolen login credentials. As far as disclosed data breaches go, this Nikkei data breach is notable less for its size than for its shape: roughly 1.83 million items of personal information leaked, and the entry point was the oldest trick in the book — valid credentials that belonged to someone else.

What happened: the timeline

• Morning of October 7: Attackers use stolen login credentials to access a cloud service Nikkei uses for system development. No exploit, no zero-day — just a working username and password.
• October 11: Nikkei reports the incident to Japan's Personal Information Protection Commission.
• October 16: The company's assessment stands at roughly 1.83 million leaked items of personal information.
• October 20: Public disclosure.

Nikkei says the stolen credentials have been blocked, the investigation is ongoing, and as of October 16 there were no signs of data misuse, system outages, or data alteration. That's the standard early-disclosure posture: honest about what happened, careful about what hasn't been found yet.

What's in the 1.83 million records

The numbers deserve a closer read, because the headline figure overstates the individual risk. Of the roughly 1.83 million items:

• About 150,000 records contained at least one identifier — a name, email address, postal address, phone number, or date of birth.
• Of those, roughly 120,000 included email addresses — the most immediately phishable field in the set.
• The remaining ~1.68 million records can't identify individuals on their own.

No credit card information was involved, which meaningfully limits the financial fraud exposure. The real risk sits with those 120,000 email addresses: expect them to feed targeted phishing campaigns, possibly impersonating Nikkei or the Financial Times, within weeks. If your address is in that set, treat unexpected Nikkei-branded emails with suspicion and read our guide on what to do after a data breach.

Nikkei Data Breach: The Same Credential-Theft Pattern, Again

Step back and this story looks eerily familiar. Attackers didn't break Nikkei's cloud — they walked in with keys stolen from somewhere else, then reached a development environment holding production-adjacent personal data. Compare it with the ConnectWise–Microsoft 365 supply-chain attack we covered earlier: different victim, different industry, same underlying shape. Legitimate access, abused. The perimeter held; the credentials didn't.

This is now the default shape of the modern enterprise breach. Infostealer malware harvests a developer's or contractor's credentials, those credentials get reused or sold, and months later someone logs into a cloud console at 8am and nobody's alarm goes off because the login looks legitimate. Defending against it has almost nothing to do with firewalls and almost everything to do with identity: hardware-backed MFA on every cloud account, short-lived credentials for development environments, and aggressive rotation when anything looks off.

Nikkei is no stranger to this cycle. The company disclosed a ransomware attack in May 2022 and a separate breach in November 2025 tied to a compromised Slack workspace. Three incidents in four years at a company whose business is information should end any lingering idea that this only happens to careless organizations. It happens to everyone; the difference is in how fast you find it and how honestly you disclose it.

What readers should actually do

If you're not a Nikkei customer or subscriber, this breach probably doesn't touch you directly. But the pattern is the lesson, and it applies to your own accounts:

1. Turn on MFA everywhere that matters — especially email, cloud storage, and anything work-related. App-based or hardware keys beat SMS codes. Our guide to MFA fatigue and push-bombing defenses covers the attacks that target MFA itself.
2. Assume your email is already in breach datasets. The 120,000 addresses here join billions already circulating. Unique passwords per site (via a password manager) are what stop one breach from becoming ten.
3. Check whether you were affected by past breaches with a lookup service — our data-breach email check guide walks through it.
4. Watch for phishing that references real details. The most dangerous follow-up to a breach like this isn't spam — it's a convincing email that knows your name and where you subscribe. Verify through official channels, never through links in the message.

For companies, the takeaway is blunter: development and staging environments are production as far as attackers are concerned. If your dev cloud holds anything resembling personal data, it needs production-grade identity controls — not the shared service account everyone has had since 2021.

Disclosure done right, prevention still pending

Credit where it's due: Nikkei reported to the regulator within four days and disclosed publicly within two weeks, with specific numbers and a clear description of the attack vector. That's better than the breach-notification average, and it stands in contrast to the slow-drip disclosures that defined October's broader breach wave.

But disclosure is the consolation prize. The industry keeps losing the same way — stolen credentials into trusted cloud services — because identity hygiene is unglamorous work that doesn't demo well in a boardroom. Until MFA is universal and dev credentials are short-lived by default, expect to read this exact story again. Probably soon.