TL;DR: Snowflake’s 2024 compromise showed how exposed service account credentials, not a product flaw, can drive wide-scale customer data loss, with attackers using stolen NHI access to hit 165 organisations and millions of records, according to Token Security’s analysis. The lesson is that identity visibility, credential rotation, and ownership mapping matter more than assuming machine access is inherently low risk.
NHIMG editorial — based on content published by Token Security covering the Snowflake attack: the hidden threats of non-human identities
By the numbers:
- 165 different organizations were victims of this attack.
Questions worth separating out
Q: What breaks when service accounts have standing privilege and exposed credentials?
A: Standing privilege turns a stolen service account secret into immediate environment access, and exposed credentials make that secret reusable until someone revokes it.
Q: Why do service accounts increase lateral movement risk in cloud environments?
A: Service accounts often hold broad permissions, integrate across systems, and are monitored less consistently than human users.
Q: How do organisations know if NHI credential rotation is actually working?
A: Rotation is working only when old credentials are revoked, not merely replaced, and when no critical service still accepts a previously exposed secret.
Practitioner guidance
- Inventory service accounts with replayable credentials Map every service account that authenticates with passwords, keys, or tokens that can be stolen and reused outside the issuing system.
- Enforce ownership for every non-human identity Assign a named human owner, a backup owner, and a revocation path for each service account.
- Remove standing privilege from indirect role chains Review recursive grants, inherited roles, and nested permissions to identify service accounts whose effective access is wider than expected.
What's in the full article
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- A fuller breakdown of Snowflake’s identity model, including the service versus human account distinction.
- Specific examples of how role recursion can widen effective permissions in Snowflake environments.
- The article’s practical guidance on network policy, MFA, and credential rotation for service accounts.
- The visibility and lifecycle gaps Token Security says its platform addresses across human and non-human identities.
👉 Read Token Security’s analysis of the Snowflake service account breach →
Snowflake service accounts and the NHI governance gap teams missed?
Explore further
Service account governance fails when organisations treat machine identities as disposable infrastructure rather than accountable identities. The Snowflake case shows that ownership, maintenance, and dependency mapping are not administrative extras. They are the only way to know whether a service account can be trusted to exist at all, and whether its access can be defended after compromise. Practitioners need to govern service accounts as living identities with clear lifecycle ownership, not anonymous access artefacts.
A few things that frame the scale:
- 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who is accountable when a service account compromise exposes customer data?
A: Accountability belongs to the team that owns the identity lifecycle, not just the platform team that hosts it. The practical answer is to define who can rotate, revoke, and recertify the account before an incident happens. If no owner can do that, the organisation has created an unmanaged identity. That is a governance failure, not an operational surprise.
👉 Read our full editorial: Snowflake’s service account breach shows why NHI governance failed