The credentials nobody owns: five September incidents and the inventory that missed them

In the second half of September 2026, five separate incidents reached data or infrastructure without breaking any identity system. Each one used a credential that worked exactly as designed. What they shared is that no person was accountable for the credential, so nobody noticed it was still usable, over-privileged, or public. That is the non-human identity problem stated without the market category around it, and it is the most consistent pattern in this month's news.

What happened

Functional accounts on default passwords. A password-spraying campaign tried more than 5,700 Microsoft 365 accounts across 28 tenants and compromised seven. According to Proofpoint, every one was an unmanaged functional or service account using a default or unrotated password with no MFA. The employees were protected. The accounts nobody owned were not.

A service principal secret in a GitHub issue. Microsoft described an attacker who used two compromised service principals to pull storage keys, delete recovery locks and destroy Azure resources in seven minutes. The credentials for one of them had been posted in a public GitHub issue before the attacks.

An email address that is really a token. GitLab's personal incoming email address, meant for filing issues by email, can also open merge requests that GitLab commits in the user's name and start CI jobs as them. It does not expire and bypasses MFA. GitLab calls it intended behavior.

A public key with no authorization behind it. UpGuard found more than 16,000 Supabase databases readable by anyone because row-level security was missing, so the anonymous key that ships in every page could read every row.

A leaver's token, kept alive on purpose. CrowdSec kept a departing engineer's GitHub access open so he could finish some work. A token stolen from his laptop by supply-chain malware was used to copy about 170 private repositories before the access was closed.

Why inventories miss these

Most identity programs are built outward from the HR system. A person joins, gets accounts, moves, loses some, leaves, loses the rest, and every step has an owner and a ticket. That model is good at people and structurally blind to everything in this list.

A functional mailbox has no manager to certify it. A service principal's secret lives in whatever system the engineer who created it happened to use. The GitLab address is not in any token inventory because it looks like an email address. The Supabase key is public by design, so no scanner flags it. Even the CrowdSec case, which involved a real person, escaped the process: the decision to keep access open was made informally and never became a grant with an owner and an end date.

The common failure is not a missing tool. It is that the inventory is keyed on people, while the attack surface is keyed on anything that can authenticate.

What to change this quarter

Inventory by sign-in capability, not by employment record. Start from what can authenticate: every account allowed to sign in interactively, every service principal and app registration, every API key and personal access token, every alternative input channel such as email-in addresses and inbound webhooks. Then join that list to owners. Anything without an owner is either assigned one this quarter or disabled.

Block interactive sign-in for identities that do not need it. Most functional and service accounts never need a human to type a password. Conditional Access or the equivalent can stop them signing in interactively at all, which is what would have closed the spraying campaign. For the few that must, require an owner, a rotated password and a phishing-resistant method. See shared accounts and service accounts.

Remove secrets instead of guarding them. A client secret can be pasted into a GitHub issue; a federated credential cannot. Move workloads to workload identity federation and managed identities wherever the platform supports it, and treat every remaining static secret as a migration backlog rather than a permanent fixture. See secrets in repositories and CI.

Split destructive rights from everyday rights. The JadePuffer principals could read secrets and delete locks. Few workloads need both, and lock deletion in particular belongs behind a human approval. Review which service principals hold delete, key-listing and role-assignment rights together, and why.

Put expiry on every exception. "Keep his access open so he can finish" is a reasonable request that needs to exist as a time-boxed grant, scoped to what the work needs, with an owner who is told when it lapses. The same applies to contractor access, break-glass accounts and emergency API keys. See orphaned account abuse.

Rotate on exposure, not on proof of use. CrowdSec rotated the secrets in its repositories in September, after the code appeared publicly, for a laptop infected in May. A known infection on a machine is the trigger for rotating everything that machine could reach.

Check authorization, not just authentication, in generated apps. Many of the exposed Supabase projects appear to have been built with AI coding agents. A working demo proves that sign-in works; it proves nothing about whether each table checks who is asking. Make "every table has a policy that references the signed-in user" a review gate.

What this does not mean

It does not mean the answer is a non-human identity product. Discovery tools help with the first step, and several are good at it, but none of these incidents was caused by a lack of visibility tooling so much as by the absence of an owner and an expiry. The inventory, the ownership rule and the removal of static secrets are process decisions that a tool can support and cannot make.

It also does not mean humans are no longer the main target. Vishing and help-desk social engineering drove other incidents this month, including the ShinyHunters activity behind September's arrest. The point is narrower: when the people are well protected, attackers go to the credentials nobody is protecting, and in September that was where they got in.

Related reading

• This Week in Identity, Issue 15, where this pattern first appeared
• Static API key abuse and password spraying
• Workload identity and non-human identity in the glossary
• Secrets management vendors and machine identity vendors