On the morning of October 7, someone logged into a development system inside Nikkei's network using credentials that did not belong to them. From there the attacker reached personal data the company keeps in the cloud. Nikkei disclosed the incident last week: 1.83 million records, of which 150,000 contained at least one of full name, email address, physical address, phone number, or date of birth. Email addresses alone appeared in 120,000 records. The other 1.68 million carried no identifiers, and no card data was exposed.
It was the third breach Nikkei disclosed in about a month. In late July, hackers compromised an employee's Google Workspace account. In September, the company said threat actors hijacked a different employee's Microsoft 365 account and used it to send spear-phishing mail to staff.
Three separate compromises at one company in roughly ten weeks, and as far as the public record goes, all three started with an account. Nikkei revoked the abused credentials and notified Japan's Personal Information Protection Commission on October 11. By October 16 the company said it had no evidence the accessed information was misused, no signs of tampering, and no service outages.
I would not take much comfort from that paragraph if I worked there. Nine days is enough time to conclude you have not seen the data used yet. It is not enough time to conclude it will not be.
A development system is a production system if it holds production data
The detail that matters most in the Nikkei disclosure is where those credentials worked: a development system. Development environments are where security controls go to die. They get broad network access because engineers need to debug. They get shared service accounts because provisioning individual ones is friction. They frequently hold a snapshot of production data because testing against realistic data is easier than synthesizing it. Nikkei's cloud-stored personal information was reachable from a dev box.
If your dev environment can read customer PII, it needs the same identity controls as production: hardware-backed MFA, short-lived credentials, per-service accounts, and no standing access. That is boring advice, and most organizations have not done it.
The Alabama breach shows what recovery actually costs
The Alabama Board of Nursing noticed suspicious activity in its systems in August. A forensic investigation confirmed malicious activity in portions of the environment as of September 1. Investigators found that data had been collected and downloaded. The board contained the ransomware before it escalated, took affected systems offline, and shut down online license renewals.
Applications were processed on paper. For a state licensing board, that means every nurse renewing a single-state license had to find a printer, a stamp, and a mailbox. A replacement renewal website went live on October 19. Single-state renewals work there now, and the board says more application types will be added as they are rebuilt.
That is about two and a half months between "suspicious activity" and a working online renewal flow. Containment took days. Recovery took a season. Most incident response budgets are written around the first number and not the second.
There is another lesson buried in that timeline. The board's containment actions worked in the sense that the ransomware did not spread further. They did not work in the sense that mattered, because the data left before anyone noticed. Once an attacker has copied records out, taking the servers offline protects your availability, not your patients' or licensees' privacy. The order of operations in the response determines which of those you save.
Credential resets are not containment
All three of these stories share a pattern. A workforce account or a service account gets compromised. The organization resets the password, revokes sessions, and announces the incident closed. Then something else falls over a few weeks later.
In Microsoft 365 and Google Workspace, the password is rarely the thing you need to kill. Attackers who reach a mailbox add forwarding rules, register OAuth applications with mail and file scopes, create app passwords, and plant refresh tokens. Nikkei's September incident involved a hijacked M365 account used to phish colleagues, which is exactly the kind of access that survives a password change when nobody audits the tenant.
After any account compromise, the checklist should include: enumerate OAuth grants and service principals, delete unknown app registrations, check mailbox rules and forwarding, review sign-in logs for token reuse from unfamiliar ASNs, rotate every credential the account could reach, and look at everything that account touched in the prior 30 days. That last item is the one people skip. It is also the one most likely to find the second incident before it becomes the third.
PHI is the same problem with higher stakes
Specialty Pharmacy Continuum published a piece this week on protecting PHI in pharmacy systems, and pharmacy is a genuinely hard case. Patient data moves through prescriber networks and claims clearinghouses, and each hop is a separate identity domain with its own credential hygiene. Record sensitivity is high and margins are thin, which is a bad pairing for security budgets.
The controls are not exotic. Encrypt at rest with keys you manage, segment the pharmacy management system away from the corporate network, log every query against patient records and alert on bulk reads, and treat every integration partner as unverified until it authenticates with a scoped credential.
What I would do Monday
Inventory every system that can reach regulated data, including dev, staging, analytics, and the forgotten reporting server nobody owns. For each one, answer two questions: who authenticates to it, and does that identity have standing access. Nikkei's dev system and Alabama's renewal portal both had answers their owners did not like.
Then measure your recovery timeline honestly. If your licensing portal or your order intake system went down tomorrow, how long until a replacement is live, and how much of the workflow runs on paper in the meantime. Alabama's answer was about ten weeks. Most organizations have never worked theirs out, which means the number is whatever the incident happens to be.