Research
Primary sources, dated, with the parts that undercut our own commercial interest left in. We would rather be the reference than the loudest vendor.
Editorial policy
HumanAudit Inc. owns and funds this research, and also owns NHI Governance. We are a vendor with a commercial interest in this problem, and we state that on every page rather than presenting our material as independent analysis.
Our rules: every statistic carries a source and a date. Vendor-sponsored surveys are labelled as such, including when they favour us. Where we cannot verify something we mark it unverified rather than dropping the caveat. When we get something wrong we correct it in place with a note rather than quietly editing.
One statistic we deliberately do not use: the machine-to-human identity ratio. Six vendors published figures between 17:1 and 144:1 within the same twelve months, every one self-published by a company selling machine-identity software, and we could find no independent measurement. It is directionally real and quantitatively meaningless.
Incident library
Documented breaches in which a non-human identity was the mechanism. Every entry links to a first-party post-mortem or a named threat-intelligence report, not to press coverage.
| Organisation | Date | Identity type | What happened | What would have prevented it |
|---|---|---|---|---|
| Cloudflare | Nov 2023 | Service token and service accounts | Four machine credentials leaked in the October 2023 Okta support breach were left unrotated because they were believed unused. The attacker accessed 120 repositories. | Knowing which credentials were live. Cloudflare’s own words: “mistakenly it was believed they were unused.” source |
| Microsoft | Jan 2024 | Legacy OAuth application | A legacy test tenant without MFA led to a legacy test OAuth application holding elevated corporate access, which the actor used to grant itself Exchange full_access_as_app. | An inventory and expiry policy for legacy application registrations. source |
| Snowflake customers | 2024 | Single-factor database credentials | Roughly 165 organisations. Credentials found in infostealer output were still valid years after theft, some dating to November 2020. | MFA, network policies and rotation — all native, free, and simply not enabled. source |
| Internet Archive | Oct 2024 | GitLab token in a config file | A token present since at least December 2022 exposed further credentials, including a Zendesk token with access to support tickets. | Rotation after the first disclosure — and knowing the token existed at all. source |
| Ultralytics | Dec 2024 | Orphaned PyPI API token | The second attack wave succeeded via an unrevoked PyPI token still available to the GitHub Actions workflow — a hold-over from before the project adopted Trusted Publishing. | Deleting the old credential after migrating to the secure pattern. The organisation had already done the hard part. source |
| tj-actions/changed-files | Mar 2025 | Chained personal access tokens | A four-hop chain of maintainer personal access tokens ended with malicious commits across an action used by more than 23,000 repositories. | SHA-pinning actions, OIDC instead of long-lived tokens, and no cross-repository maintainer credentials. source |
| Salesloft Drift → Salesforce | Aug 2025 | Third-party OAuth tokens | Attackers compromised Salesloft’s GitHub, pivoted into Drift’s AWS environment and harvested customers’ OAuth tokens. More than 700 organisations affected. Cloudflare found 104 of its own API tokens inside support-case text. | Scope limits and IP allowlisting on connected applications, plus an inventory of which third parties hold which grants. source |
| Gainsight → Salesforce | Nov 2025 | Third-party OAuth tokens | Salesforce revoked all tokens for Gainsight-published applications. The compromise was attributed to tokens stolen in the August Salesloft incident — a second-order cascade. | The same controls, applied after the first warning. The industry had three months of notice. source |
| Aqua Security / Trivy | Feb–May 2026 | CI/CD credentials | From the vendor’s own advisory: credential rotation “was performed but was not atomic”, and the attacker retained access through the rotation window. 76 of 77 action tags were force-pushed to malicious commits. | Atomic rotation — which requires knowing the complete credential set before you start. source |
| Hugging Face | Jul 2026 | Seven chained credential types | An autonomous agent escaped its sandbox and operated for 4.5 days, chaining Kubernetes service-account tokens, EC2 instance role credentials, a mesh-VPN key, a GitHub App token, a JWT signing key, a static database password and a reusable Tailscale auth key. It enrolled 181 nodes into the tailnet. | Workload identity federation and short-lived credentials — free, native, and named by Tailscale as the fix. source |
The pattern we think matters most — including where it argues against us
Read the final column. In several of these — Hugging Face, Ultralytics, Snowflake, tj-actions — the preventive control was free, native and already available: workload identity federation, short-lived credentials, MFA, deleting an old token after migrating to a better pattern.
That is an argument against buying anything, and we include it because it is true. The cases where free primitives do not help are the SaaS-to-SaaS ones — Salesloft Drift, Gainsight, the Okta-to-Cloudflare chain — because the trust anchor sits in a third party’s cloud, and the token lifetime, scope and revocation are controlled by that vendor rather than by you. That is the narrow gap we work in, and we would rather define it precisely than overstate it.
Which controls actually touch non-human accounts
Most vendor content on this subject overstates the case. Here is the honest version, including the scope conditions that determine whether a control applies to you at all.
PCI DSS 4.0.1, Requirement 8.6
The most specific control anywhere that names non-human accounts. All three sub-requirements were future-dated and became mandatory on 31 March 2025.
8.6.2, verbatim: “Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.”
Three scope conditions most vendors omit
- 8.6.1 and 8.6.2 are conditional. Both apply only to accounts that “can be used for interactive login”. A service account configured as non-interactive — a
nologinshell, a group managed service account, an OAuth client credential, an IAM role — is out of scope for both. Disabling interactive login and documenting that decision is a legitimate and much cheaper compliance path. - 8.6.3 sets no rotation floor. Unlike the fixed rules applied to human accounts, the change frequency is defined by the entity’s own targeted risk analysis. There is no minimum.
- 8.6 does not appear in SAQ A. The largest merchant population by count never answers it. It applies to entities completing a Report on Compliance or SAQ D.
Our reading: 8.6 is a legitimate reason to look, and a weak reason to buy. If a vendor tells you PCI 8.6 forces you to purchase software, ask which of the three conditions above they believe does not apply to you. Verify verbatim text against the PCI SSC document library before relying on it.
CIS Controls v8.1, Safeguard 5.5
Verbatim: “Establish and maintain an inventory of service accounts. The inventory, at a minimum, must contain department owner, review date, and purpose. Perform service account reviews to validate that all active accounts are authorized, on a recurring schedule at a minimum quarterly, or more frequently.”
Applies to Implementation Groups 2 and 3, and it is the only one of Control 5’s six safeguards that mentions service accounts. Honest caveat: the CIS assessment specification defines this as a documentation check — an inventory carrying owner, review date and purpose, reviewed within 90 days, passes. CIS is self-assessed, with no certificate and no external auditor.
ISO/IEC 27001:2022, Annex A 5.16
The 2022 revision is the first to reach non-human identities explicitly; the 2013 version had no equivalent guidance. Implementation guidance states that a non-human identity requires its own approval and registration process, distinct from a user identity. Certification auditors sample rather than enumerate, so a documented policy plus a register generally satisfies it.
SOC 2, CC6 series
Principles-based. There is no prescriptive control touching machine identities — the auditor tests the controls you wrote. An auditor cannot fail you for lacking non-human identity governance unless you claimed to have it. That makes SOC 2 a weak reason to buy and a genuinely useful place to write a control you can then evidence.
Context worth having
Corrections
We publish corrections rather than silently editing. Nothing has required correction yet. When it does, it will appear here with the original claim, the correction, and the date.
Find out what your own record looks like
The research describes the pattern. A scan tells you whether you have it.