Executive summary
In the first week of October 2026, four unrelated organisations disclosed incidents with the same shape. Attackers did not defeat a control. They obtained a valid login, and the login led somewhere it should not have. A Danish university's identity directory was downloaded. A British retailer's customer-messaging channel was used to tell customers it had been hacked. A Japanese publisher saw two employee cloud accounts taken over. An American school-software supplier lost employee records through a flaw in a product it relies on. This paper reads those events together and offers a seven-check review for the systems that decide who can do what, and the channels attached to them.
The central argument is simple. The identity system and the tools connected to it are now the highest-value targets in most organisations, and they are rarely governed as such. They are treated as plumbing.
1. Four incidents, one pattern
DTU. On 2 October the Technical University of Denmark reported that attackers compromised profiles, used them to reach DTUBasen, its identity and access management system, and downloaded a large amount of data. Up to 200,000 current and former users may be affected, with records back to 2003. BleepingComputer reports that stolen credentials were used.
ASOS. On 6 October the retailer says an employee was socially engineered, and the stolen credentials were used on third-party platforms it relies on. Customers received a push notification claiming a hack. Infosecurity Magazine records that Snowflake found no compromise of its platform, and that a reported involvement of the marketing platform Simon AI is unconfirmed. The attacker's claims of what was taken are not independently verified.
Nikkei. The publisher disclosed two incidents: a Google Workspace account accessed in late July, exposing details of 1,646 individuals, and a Microsoft 365 account used in September to send phishing messages to staff and interviewees.
Frontline Education. The school-administration software supplier is notifying districts that attackers exploited a flaw in third-party software and reached employee records, including Social Security numbers. The company has not named the product.
The Danish state register incident of the same week, covered in our earlier article, was also a valid-access story: a partner company's legitimate access to the register was misused.
2. What these have in common
None of the disclosures describes a novel technique. Each involves legitimate access used by someone it was not intended for, and each exposes a system whose purpose is to hold or relay a great deal of information about a great many people. A directory knows everyone. A messaging tool can speak to everyone. A mailbox is a way to impersonate one person to everyone else.
These systems share three properties that make them attractive. They are wide, in that one account reads a lot. They are trusted, in that their output is believed. And they are unowned, in that each sits between teams so nobody carries it on their risk register. DTU's notice illustrates the third: a deletion routine existed for addresses and next-of-kin details, but national identifiers and names were kept, so the policy had been designed without the thing an attacker most wanted.
Governance framework: seven checks
Run these with the people who administer the systems, and keep the answers in writing.
- Name the crown-jewel systems. List every directory, single sign-on provider, customer data platform and mass-messaging tool, with a named owner for each. If two teams each assume the other owns it, that is the finding.
- Measure the blast radius of one ordinary login. For a typical staff account, record what it can read in each system, and how many rows it could export in an hour.
- Minimise before you monitor. For each personal field in the directory, state which process needs it. Move identifiers and next-of-kin data somewhere narrower and apply deletion rules to every field, not just the obvious ones.
- Protect the broadcast channels. Sending a push, SMS or mass email should require strong authentication, a second approver for large sends and a way to be switched off out of hours.
- Close the telephone route. Write down what the help desk and suppliers will need before resetting access or changing a trusted contact, and test it with an internal social-engineering exercise.
- Alert on volume, then rehearse. Alert on unusual reads, exports and message sends per account. Test the alert using a normal login and record who was told and how quickly.
- Prepare to reach the people who have left. Hold a notification plan that works for former staff, students or customers whose contact details are stale, including the regulator timeline and a pre-agreed holding statement.
3. A maturity ladder
At the implicit stage, nobody can list the systems that matter most, broad read rights accumulate and breach notification is improvised. At defined, owners exist, personal fields have stated purposes and broadcast tools require strong sign-in. At tested, volume alerts have been triggered deliberately, deletion rules run on a schedule and the notification plan has been rehearsed with legal and communications. Most organisations we meet are at the first stage for at least one of the systems above, and often the one holding the most data.
4. Risks and how to manage them
The common failure is to answer a breach like this with another login control and nothing else. Stronger authentication matters, and the ASOS case suggests it must also cover the human steps around it. But authentication cannot undo an excess of data. The second failure is to treat minimisation as a compliance exercise run by a privacy team alone. It needs the application owners who use the fields, because a field removed without them tends to reappear in a spreadsheet. The third is to rely on a supplier's statement that a platform was not at fault. Snowflake's position that its platform was not compromised may well be right, and your exposure can still sit in the integration around it.
Conclusion
The week's disclosures are a fair picture of the present: people tricked or credentials taken, a system trusted by everyone, and a pile of data larger than anyone had considered. The remedy is mostly dull. Know the systems, shrink what they hold, narrow who can read it and listen for the moment it is read in bulk. A single working session across the seven checks usually reveals more than a year of generic awareness training, and the follow-up is mostly deletion.
Facts above are drawn from the organisations' own statements and the reports linked, and some attacker claims remain unverified. Details may change as investigations conclude.
Not sure what one stolen login could read?
We can run a short review of your identity directory, customer-messaging tools and broadcast channels against the seven checks in this paper.
Explore more resources
Browse our full library of enterprise cloud, software, data and AI content.