Nikkei Inc., the Japanese media group that owns the Financial Times, says attackers used stolen credentials to raid a cloud development service and take around 1.83 million records. It is the third security incident the publisher has disclosed this month, and the pattern behind them deserves the attention of every UK security team.
What happened
In a notice dated 16 October 2026, Nikkei said a cloud service it uses for system development had been accessed without authorisation. The intrusion ran from the early hours to the morning of 7 October, and the attacker logged in with valid credentials that Nikkei says were stolen “by unknown means”. The company reported the incident to Japan’s Personal Information Protection Commission on 11 October, disabled the credentials and began reviewing what had been taken.
According to Nikkei, roughly 1.83 million items of personal information were exposed. Around 150,000 contained at least one direct identifier, such as a name, email address, postal address, phone number or date of birth, and about 120,000 of those included an email address. The remaining 1.68 million or so held only data that Nikkei says cannot identify an individual on its own. No payment card details were involved. As of 16 October the company had seen no misuse of the data, no outages and no tampering, and it has promised to contact everyone whose information is confirmed as leaked.
This comes less than a fortnight after two other disclosures. In a notice dated 5 October, Nikkei revealed that an employee’s Microsoft 365 account had been hijacked and used on 30 September to send about 9,000 spoofed emails, carrying links to malicious sites, to staff, outside contacts and even journalistic sources. It disclosed at the same time, as The Record reported, that a second employee’s Google Workspace account had been accessed from late July, potentially exposing details of 1,646 employees and business partners. Earlier in the year, in May, its US subsidiary Nikkei America reported a separate Microsoft 365 account takeover. Nikkei has not said whether any of these incidents are linked, and none has been attributed to a named group.
It is worth being clear about scope. Nothing in Nikkei’s statements or the press coverage suggests that Financial Times systems, FT subscribers or UK residents were affected. The UK relevance here lies in the ownership link and, more importantly, in what the incidents reveal about how organisations are being breached.
The technical picture
None of these incidents involved an exotic exploit. In each case the attacker simply signed in. Whether the credentials came from an infostealer infection, a phishing page, password reuse or a leaked token, Nikkei has not said, and we should not guess. What matters is that a single valid identity was enough to reach the data or the mailbox.
The latest incident is the most instructive because of where it happened. Development environments in the cloud often hold copies of production data for testing, sit outside the tighter controls applied to live systems and use service accounts or access keys that are rarely rotated.
The two mailbox compromises follow a familiar model. Once an attacker controls a trusted employee’s account, they can send convincing phishing to everyone that person has dealt with. For a news organisation, that contact list includes sources, which makes the 30 September campaign particularly sensitive even though Nikkei says no reader or source information was exposed in the Google Workspace case.
Why it matters for UK organisations
Stolen credentials are a well-worn route into organisations of every size, and the Nikkei sequence shows how weak identity controls can produce repeated incidents across different platforms within weeks. Hijacked mailboxes also make any unexpected message from a known contact suspect, since attackers use them precisely because recipients trust them.
There is a regulatory dimension too. Had a comparable breach hit a UK controller, UK GDPR would require notification to the regulator within 72 hours of becoming aware of it where there is a risk to individuals. Since 30 September 2026 that regulator is the Information Commission, which took over the functions of the ICO. Nikkei’s four-day gap between intrusion and report to its own regulator is a reminder that the clock starts at awareness, and that UK organisations need a tested process for assessing scope quickly, particularly where test or development data is involved.
Expert view
In my experience, development and test environments are among the most reliably under-protected assets we find on engagements. They are built quickly, owned by project teams rather than security, and quietly accumulate real data. The access controls that would never be accepted on production, such as long-lived keys, shared accounts or no conditional access, survive because “it is only dev”.
The wider lesson from Nikkei is about pattern recognition. A Google Workspace takeover, a Microsoft 365 takeover and a cloud credential compromise look like three separate problems if each is handled as a ticket. Taken together, they suggest an identity problem: credentials may be being harvested from somewhere and phishing-resistant authentication is not yet universal. When we test organisations with several recent account compromises, the root cause is usually upstream: endpoint hygiene, password reuse or MFA gaps on service and legacy accounts.
I would also caution against reading too much comfort into the “cannot identify an individual” category. Data that looks anonymous in isolation can often be linked back to people when combined with other records taken in the same theft.
What to do now
- Inventory non-production environments. Identify every cloud development, test and staging service, who owns it and whether it holds real personal data. Replace live data with synthetic or properly masked data wherever possible.
- Enforce phishing-resistant MFA everywhere, including dev. Extend conditional access and strong MFA to developer tooling, cloud consoles and collaboration suites. This maps directly to the Cyber Essentials user access control requirements.
- Kill long-lived secrets. Rotate access keys and tokens on a schedule, prefer short-lived federated credentials and alert on any use of dormant or unexpected identities.
- Hunt for credential exposure. Monitor infostealer logs and breach data for your domains, and check endpoints of anyone whose account has been abused for signs of malware (Cyber Essentials malware protection and security update management controls apply).
- Treat repeat incidents as one investigation. If you see more than one account takeover in a quarter, look for a common root cause rather than closing each ticket separately.
- Rehearse your 72-hour reporting decision. Make sure your team can scope a breach involving test data and decide on notification to the Information Commission within the statutory window.
Bottom line
Nikkei has not been the victim of a sophisticated technical attack so much as a series of stolen logins, each opening a different door. There is no indication that the FT or UK data was caught up, but the lesson travels well: if your development cloud holds real data and can be reached with a single password, it is a breach waiting to happen. Fix identity first, then go and find where your copies of production data actually live.
Sources
- Nikkei Inc.: Personal Information Leak Due to Unauthorized Access
- Nikkei Inc.: Regarding Information Leaks and the Sending of Suspicious Emails due to a Cyberattack
- Nikkei Inc.: Unauthorized Access to Microsoft 365 Account at U.S. Subsidiary
- BleepingComputer: Nikkei discloses third data breach in a month, 1.8M records exposed
- SecurityWeek: Hackers Steal 1.8 Million Records From Nikkei
- Security Affairs: Nikkei data breach affected over 1.8 million records
- The Record: Japanese media group Nikkei discloses intrusions targeting employees and users
