The most expensive intrusion disclosed in August 2026 did not involve malware, a zero-day or a firewall failure. It involved valid usernames and passwords used against cloud accounts that had no multifactor authentication. The criminal case behind it covers more than 165 victim organizations.
That pattern repeats across the incident register for 1 August to 12 September 2026. Identity, human and machine, was the entry path in at least five material incidents, and probably in several more that disclosed only "unauthorized access". This analysis looks at how those intrusions worked, why identity controls keep failing at the point of use, and what has to change at the connection itself.
Contents
- What the register shows about identity
- Case 1: credentials and missing MFA at cloud scale
- Case 2: a single machine key
- Case 3: social engineering into the cloud
- Why identity controls fail after authentication
- Human identity and machine identity are different problems
- What actually stops these intrusions
- A practical checklist
- What a good week looks like
- Frequently asked questions
Key Takeaways
- At least five material incidents in the window began with stolen credentials, a compromised cloud key or social engineering.
- The Snowflake customer campaign involved cloud accounts without multifactor authentication and led to a guilty plea covering more than 165 organizations.
- One compromised cloud access key at a CRM provider exposed database backups belonging to more than 1,000 charities.
- Machine identities outnumber human ones and rarely have an owner, an expiry or a human to phish, which is precisely why attackers prefer them.
- Authentication decides who gets in. Only control at the connection decides what they can do next.
What the register shows about identity
Of the 27 material incidents disclosed between 1 August and 12 September 2026, five name an identity-based entry path: credential theft against accounts lacking multifactor authentication, a compromised cloud access key, and social engineering of employees at three separate organizations, one of which led directly into a cloud environment.
Another eight incidents disclosed unauthorized access without stating a cause. Given what the named cases show, identity is likely to account for more of the register than the explicit five.
None of these required an exploit. That is the uncomfortable part: the controls that failed were configuration and governance, not detection of something novel.
Case 1: credentials and missing MFA at cloud scale
The US Department of Justice announced that a Canadian man pleaded guilty to hacking a US cloud storage provider and extorting its customers, in a conspiracy that compromised more than 165 victim organizations and led to the theft of billions of customer records. Reporting on the plea described the attacks working through stolen credentials against customer cloud accounts that were not protected by multifactor authentication.
Two details matter for defenders. First, the customer, not the platform, owned the failing control. Second, prosecutors put victim losses at more than US $9.5 million, the only confirmed loss figure in the entire register, and it exists only because a criminal case established it.
Key Insight
A shared platform can be secure while the accounts on it are not. Responsibility for authentication almost always sits with the customer, and attackers read the shared responsibility model more carefully than most buyers do.
Case 2: a single machine key
A CRM provider serving charities disclosed that a compromised Amazon Web Services access key exposed database backups, with more than 1,000 charities potentially affected and contact and donor data involved.
An access key is a machine identity. It does not get phished, does not sit behind MFA, and frequently has no named owner, no expiry and far broader permissions than the job requires. It also tends to live in places humans forget: a repository, a CI pipeline, an old script, a backup job.
One key, more than a thousand downstream organizations. That is the leverage attackers now optimize for.
Case 3: social engineering into the cloud
Three organizations in the window traced intrusions to social engineering: a clothing manufacturer where three employees were manipulated into enabling access to company computers, a communications provider that described sophisticated social engineering with about 1.6 million accounts exposed, and an asset manager where social engineering enabled access to a cloud environment over a four-day period, with personal data including Social Security numbers stolen.
The progression in the third case is the one to note: a person is deceived, a credential is obtained, and the attacker arrives in the cloud as an authenticated identity. Everything after that looks like normal use.
Why identity controls fail after authentication
Most enterprise identity investment goes into the moment of login: stronger factors, conditional access, single sign-on. That moment matters, and MFA would have blocked the largest case in this register. But three structural gaps remain once a session exists.
- Authentication is a one-time decision. After the token is issued, the connection is usually trusted until it expires.
- Machine identities skip the moment entirely. Keys, tokens and service accounts authenticate without a human, so factors and prompts do not apply.
- Legitimate traffic evades tools built for malware. Nothing malicious is executed when an attacker queries a database with a valid credential.
This is why intrusions in the register surfaced through audits, notifications and criminal cases rather than alerts, and why several ran for weeks or months.
Human identity and machine identity are different problems
Human and machine identity differ across every dimension that matters. Typical count: there is usually one human identity per employee, while machine identities number many per service and keep growing with automation and AI agents. Strongest control: phishing-resistant MFA works for humans, while machine identities are best protected by short lifetimes, scoped permissions and rotation. Common failure: humans fail through social engineering, while machine identities fail through long-lived keys with broad scope and no owner. Visibility: human identity lives in directory and HR systems, while machine identity visibility is often none outside the team that created it. And in this register, human identity failures showed up as three social engineering cases, while the machine identity failure showed up as a single cloud key exposing more than 1,000 organizations.
Enterprises now run far more machine identities than human ones, and AI agents add more every week. Our analysis of non-human identity covers that growth in detail, and zero trust was designed for human users explains why the assumptions behind most identity architectures break when the client is software.
What actually stops these intrusions
Identity hygiene comes first: enforce multifactor authentication everywhere it can be enforced, prefer phishing-resistant factors, inventory and scope machine credentials, keep lifetimes short and rotate them. None of that is controversial, and it would have prevented the largest case here.
What hygiene cannot do is govern the session after authentication, and that is where these attacks live. The control has to sit on the connection: every request between users, services, suppliers and agents passing through a single point that checks identity continuously, applies policy per connection, and blocks in seconds rather than raising a ticket.
That is what Conux does as a cybersecurity gateway. Machine identities are governed rather than assumed. Policy is enforced on every connection, not at login. Quantum-safe encryption is applied to the traffic, because data taken today stays valuable. And five agents detect, block, harden and log the evidence without an analyst in the loop, which matters when the alternative is the response times in this register. Conux sits in front of existing cloud, identity and applications, so nothing is replaced.
Key Insight
Stronger authentication reduces the number of front doors. Only control at the connection decides what happens once someone is inside, which is where every incident in this section actually unfolded.
A practical checklist
- Enforce multifactor authentication on every account that touches cloud data, including contractor and service desk paths.
- Inventory machine credentials: keys, tokens, service accounts, CI secrets, agent credentials. Assign an owner to each.
- Set expiry and rotation for machine credentials, and scope permissions to the task.
- Log and review authentication from unusual locations, unusual clients and unusual times for machine identities as well as humans.
- Test what a valid credential can reach. If the answer is "most of the data", the problem is authorization, not authentication.
- Require evidence, not assurance, from suppliers on both MFA and key management.
- Watch for the second-order signal: a spike in data volume moving through an integration that has not changed in months.
What a good week looks like
None of this needs a transformation programme to begin. A useful first week has three outputs: a list of cloud-facing accounts without multifactor authentication, a list of machine credentials older than 90 days with no named owner, and a one-page answer to the question of what the most privileged machine identity in the environment can reach. Those three artefacts tell you more about identity exposure than most annual assessments, and each one maps to an incident in this register.
The second week is harder and more valuable: pick the single integration that would hurt most if its credential leaked, and put it behind a control that verifies identity on every connection rather than once at login.
To review your identity exposure against the entry paths in this register, talk to our team.
