Identity
Nikkei: stolen credentials, a dev cloud and 1.83M records
Attackers used stolen credentials on Nikkei's development cloud service and took 1.83 million records. What is known, and the controls to check on your own.
Nikkei Inc., the Japanese publisher of The Nikkei, said on October 16 that someone logged in to a cloud service it uses for system development with stolen credentials and took about 1.83 million records of personal information. The access ran from the early hours to the morning of October 7. About 150,000 of the records hold at least one of name, email address, postal address, phone number or date of birth, and about 120,000 of those include an email address. The other 1.68 million or so hold only identifiers that Nikkei says cannot identify a person on their own. No credit card data was involved.
This is the third Nikkei account takeover made public in under two weeks, and the fourth in a year. Nikkei has not named the service, said how the credentials were stolen, or said whether multi-factor authentication (MFA) was in place. Any team that runs development tooling in a SaaS (software as a service) product with real customer data in it is exposed to the same thing. Most of the controls that limit it are settings in services you already pay for.
What Nikkei has confirmed
Nikkei's notice is short. Credentials for the development cloud service were "stolen by some means", the attacker used them on October 7, and personal information stored in the service was taken. Nikkei reported the incident to Japan's Personal Information Protection Commission (PPC), the national privacy regulator, on October 11, and has disabled the credentials that were used.
As of October 16, Nikkei had found no misuse of the data, no outage and no tampering, and it will notify each person whose data is confirmed as leaked. SecurityWeek and Security Affairs report the same figures. One wording differs: BleepingComputer describes "a development system on Nikkei's network", while Nikkei's own notice says a cloud service. This post follows the notice.
Nikkei has not said which product the service is, whether the credential was a password, an API key or a token, whether MFA or IP restrictions applied, or whether the records were a copy of production data, and this post does not guess.
How a stolen login turns into a data breach
A development cloud service is anything the engineering team uses to build and test: a source repository, a CI/CD pipeline (the system that builds and deploys code), a cloud database used for testing, or an analytics workspace. People sign in through a web console, ideally behind single sign-on (SSO) and MFA. Scripts and pipelines use long-lived secrets such as API keys, personal access tokens or service account keys, which skip MFA by design.
A stolen credential of either kind works from anywhere unless the service checks more than the secret: without an IP restriction, device check or MFA prompt, a valid key from an unfamiliar network looks like a developer's script. If the account can read a database or storage bucket, an export of 1.83 million rows is a few API calls, and an early morning window like the one on October 7 means few people are watching.
Development environments also collect secrets, in repositories and pipeline variables, and often hold real personal data copied from production to make testing realistic. That copy is what turns a developer credential into a reportable breach.
A pattern across the Nikkei group
Each of the group's earlier incidents was an account takeover:
- November 2025: Nikkei disclosed that malware on an employee's personal computer stole Slack credentials, exposing names, email addresses and chat history for 17,368 people registered on its Slack.
- From late July 2026, an employee's Google Workspace account was accessed from outside. Google alerted Nikkei in early August, and Nikkei changed the password. Names and email addresses of 1,646 employees, business partners and others may have been exposed. Nikkei disclosed this on October 4.
- On September 30, 2026, a different employee's Microsoft 365 account sent about 9,000 emails with links to malicious websites to staff, news sources and other contacts. The same day, an employee at the group publisher Nikkei BP had an email account taken over after a phishing email that appeared to come from a Nikkei employee, putting 26 names and email addresses at risk.
- On October 7, 2026, the development cloud service.
Nikkei has not said whether these are connected, and no group has been named. The November 2025 case shows one route already used against Nikkei: an infostealer, malware that copies saved passwords and session cookies from a browser for resale. Whether that applies to October 7 is unknown.
What to do
1. List every development service and what it holds
Ask each engineering team for the SaaS tools they log in to, including trials, and record the owner, the sign-in method and whether it holds personal data. Expense records and your identity provider's app list find the ones nobody mentions. A service that holds customer records and is not behind SSO goes to the top of the list.
2. Rotate long-lived secrets and give them an expiry
Revoke API keys and tokens that have not been used in 90 days and rotate the rest on a schedule. In AWS, the IAM credential report (aws iam generate-credential-report) shows each access key's age and last use. In Google Cloud, the organisation policy constraint iam.serviceAccountKeyExpiryHours puts an expiry on new service account keys, and iam.disableServiceAccountKeyCreation stops new keys being made at all. Where the platform supports it, replace stored keys in pipelines with short-lived tokens issued per job through workload identity federation (an OpenID Connect trust between the pipeline and the cloud account).
3. Make a password alone not enough
Put every development tool that supports it behind SSO, so a person's login carries your MFA and device policy. In Microsoft Entra ID, a Conditional Access policy can require MFA or a compliant device for those apps and shorten the sign-in frequency session control so stolen session cookies expire sooner. For keys that cannot use SSO, apply the service's IP allowlist so a key only works from your office ranges, VPN egress or build runners.
4. Alert on bulk reads and odd hours
Turn on data access logging, which is often off by default: S3 data events in AWS CloudTrail, Data Access audit logs in Google Cloud, and the audit log of the SaaS tool itself. Then alert on a credential that reads far more rows or objects than usual, on access from a new country or hosting provider, and on activity between midnight and 6am local time for accounts that normally work office hours.
5. Keep production personal data out of development
Use generated or masked test data. Where a real dataset is unavoidable, keep it in an account with its own short-lived access and delete it when testing ends.
If you think a credential has leaked
Disable it first, as Nikkei did, then pull the audit log for everything that credential did from its creation to its revocation. Check whether it created new keys, users or OAuth apps, because those survive the rotation. Search infostealer log monitoring feeds for your company domains. If personal data was in the service, bring in whoever owns breach notification early: Nikkei reported to the PPC four days after the access.
The wider lesson
Development tools are often signed up for by a team, filled with copied production data and never reviewed by security. Fixing that starts with the inventory in step 1, because a team cannot apply conditional access or logging to a service it does not know exists. The Meta GitHub breach earlier this month followed the same route through a different tool.
Our cloud and Kubernetes security reviews map which development services hold which data and who can reach them, and our attack surface management work finds the SaaS tenants and exposed keys that never made it onto an asset list. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Nikkei notice, October 16, 2026 (Japanese), Nikkei notice, October 16, 2026 (English), Nikkei notice on the Microsoft 365 account, October 4, 2026, Nikkei Slack notice, November 4, 2025, Jiji Press via Nippon.com, BleepingComputer, SecurityWeek, Security Affairs, ScanNetSecurity, The Record, Infosecurity Magazine, ScanNetSecurity on Nikkei BP, Computerworld on the Slack breach.