- Nikkei says a stolen login to a cloud service used for system development exposed about 1.83 million records on October 7. About 150,000 held personal details.
- Nikkei's three recent incidents involved a Google Workspace account, a Microsoft 365 account and now a development cloud login. That is one company, not an industry trend.
- Leaders should ask what personal data sits in development tools, who holds those logins, and how fast a stolen one can be shut off.
When an attacker holds a valid login, the system sees an employee, not an intruder. Nikkei's latest breach shows what that costs. The Japanese business news group says someone stole the credentials for a cloud service it uses to build systems. Personal data stored there was then exposed.
What Nikkei reported
Nikkei Inc. says about 1.83 million pieces of personal information had leaked as of October 16. Its notice says unauthorized access took place in the early morning of October 7. The company revoked the credentials used and reported the incident to Japan's Personal Information Protection Commission on October 11.
The figure needs careful reading. Roughly 150,000 of the records, Nikkei says, carried personal details that could point to a real person. Those details ranged from names and email addresses to home addresses, phone numbers and birth dates. About 120,000 of those included an email address. The other roughly 1.68 million were identifiers that cannot identify a person on their own. Nikkei says no credit card data was involved.
Nikkei says it has found no secondary harm, such as misuse of the data. It also reports no system shutdowns or data tampering as of October 16. It is still examining the scope of the breach. Affected people will be told individually.
How a stolen login becomes a breach
Nikkei's notice says the credentials were stolen "by some means". It does not say how. That gap is the first open question.
The mechanism is still simple. A cloud service holds data and decides who may read it. The decision rests on credentials: a username and password, or a key issued to a person or a program. If the credentials are valid, the service does what it is built to do and hands over the data.
Nothing needs to be broken. No flaw has to be found. Defences built to stop break-ins have little to flag when the visitor arrives with a real key. Detection then depends on spotting unusual behaviour, such as access at an odd hour. Nikkei's notice does not say how it noticed the access, so that is another question to ask.
The notice also places personal data in a cloud service used for system development. Development tools are often set up quickly and shared widely. Nikkei does not say why this data was there. Every organisation should know the answer for its own tools.
Three incidents, three kinds of account
BleepingComputer, which reported the disclosure, puts this alongside two earlier Nikkei incidents. Earlier this month, Nikkei disclosed a breach dating to late July. An employee's Google Workspace account was compromised, and personal information about employees and business partners was reached. In September, BleepingComputer reports, Nikkei announced that a second employee's Microsoft 365 login was seized and used to email targeted phishing lures to coworkers.
The accounts differ: a Google Workspace account, a Microsoft 365 account and a development cloud service. The common thread is identity. In each case, the reports describe an account being taken over, not a software vulnerability being exploited.
The reports do not say the incidents are linked or that one attacker is behind them. This is one company, so it is not evidence of an industry-wide trend. It does show that tightening one account type does not protect the others.
Scale matters too. BleepingComputer says Nikkei employs more than 10,100 people and has annual revenue of about $2.5 billion. It also owns the Financial Times. A large organisation has thousands of accounts, and each one is a possible entry point.
Questions to put to your team
First, ask where personal data sits in development and test environments, and whether it needs to be there at all. Data that is not stored cannot leak.
Second, ask who holds credentials for each cloud service and how they are protected. Include keys used by programs, not only passwords used by people.
Third, ask how fast you can revoke a stolen credential, and how you would know it had been used. Nikkei says it revoked the credentials used in this incident. The timing of that step relative to the discovery is not in the notice.
Fourth, ask whether a review after one incident covered every account type. Nikkei's three incidents touched three different services.
A strong lock does not help if the key can be copied. The better test is how quickly you notice, and how little a single key can open.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Nikkei Inc..
