Snowflake’s service account breach shows why NHI governance failed

At a glance

What this is: This analysis explains how the Snowflake compromise exposed the weakness of treating service accounts as low-risk identities when their credentials are long-lived, poorly attributed, and hard to govern.

Why it matters: It matters because IAM, PAM, and NHI programmes need the same lifecycle discipline for service accounts that they already apply to human access, or blast radius will keep outpacing governance.

By the numbers:

• 165 different organizations were victims of this attack.

👉 Read Token Security’s analysis of the Snowflake service account breach

Context

Service accounts are non-human identities that applications, integrations, and automated processes use to access data and systems. In this case, the governance problem was not a software flaw in Snowflake, but the assumption that machine credentials are easier to overlook than human accounts and therefore less likely to be targeted or abused.

Token Security’s analysis of the Snowflake incident shows why that assumption fails. When service account credentials are exposed through infostealer malware, the attacker inherits whatever standing privilege the account already had, and the organisation absorbs the full blast radius of that access across cloud services, contractors, and dependent systems.

Key questions

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. In practice, the break is not the login itself but the gap between compromise and cleanup. The wider the role chain, the larger the blast radius. The 52 NHI Breaches Analysis helps show how often this pattern repeats.

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. That combination gives attackers a quieter path to move from one environment to another after credential theft. The risk rises when role inheritance and contractor access are poorly documented, because the true access scope is larger than the visible account record.

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. Measure the age of active credentials, the percentage of accounts with a clear owner, and the time it takes to disable a compromised identity. If stale secrets remain valid, rotation is only symbolic.

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.

Technical breakdown

How exposed service account credentials become entry points

The Snowflake attack began with credentials belonging to a service account that were exposed by infostealer malware. That matters because service accounts often lack the human-facing controls that make stolen passwords easier to notice, such as interactive MFA prompts or user behaviour baselines. Once credentials are harvested, the attacker does not need to break the platform itself. They only need an identity with valid authentication material and enough privilege to reach valuable data or administrative paths.

Practical implication: inventory every service account with authentication paths that can be stolen, not just those that can be logged into interactively.

Why standing privilege amplifies cloud data exposure

A service account with standing privilege can be reused immediately after compromise, which turns a single exposed secret into broad access. In cloud environments, privilege is often inherited through roles, nested permissions, and indirect grants, so the real access path is wider than the credential itself suggests. Snowflake’s role structure shows how quickly a single identity can fan out into many effective permissions, especially when ownership, usage, and dependency mapping are incomplete.

Practical implication: trace effective permissions through nested roles and remove access paths that no longer have a clear business owner.

Why lifecycle controls matter more than discovery alone

Discovery tells you that a service account exists, but lifecycle governance tells you whether it still should. The Snowflake case highlighted long-standing credentials, absent or partial authentication constraints, and weak visibility into who maintained each identity. That combination means detection without de-provisioning leaves the same exposure in place. For NHI governance, the technical failure is not just secret sprawl. It is the absence of lifecycle ownership for identities that never leave the system on their own.

Practical implication: tie service account review to ownership, last use, and revocation authority, not to periodic inventory alone.

Threat narrative

Attacker objective: The attacker’s objective was to use stolen non-human identity access to reach and exfiltrate high-value customer and company data at scale.

1. Entry occurred when attackers obtained a service account credential exposed through infostealer malware and reused it against Snowflake access paths.
2. Escalation followed through standing role grants and indirect permissions that turned one valid identity into broad environment reach.
3. Impact came from data access at scale, with multiple organisations affected and sensitive customer records exposed across the Snowflake ecosystem.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing credential exposure window: This breach worked because long-lived service account credentials stayed valid long enough to be stolen and reused. That assumption was designed for predictable human or system login patterns, not for identities that can be harvested by malware and replayed without friction. The implication is that access review cadences alone do not shrink the window if the credential remains live between reviews.

Recursive privilege structures create hidden blast radius in cloud identity systems. Snowflake’s role model shows how direct access is only the starting point, while recursive grants define the true exposure surface. When role chains are poorly understood, a single service account can inherit more authority than the creator intended. Practitioners should treat indirect permissions as first-class governance objects, not as a reporting detail.

Best practices only work when they are enforced across every identity type, including contractors and legacy service accounts. The article shows that many organisations still rely on partial controls, such as network policy coverage for some users and MFA for others, while service accounts escape equivalent scrutiny. That creates uneven enforcement and false confidence. Identity programmes need policy parity across human, contractor, and NHI populations.

52 NHI Breaches Analysis shows the same pattern repeatedly: exposed credentials plus unclear ownership equals durable compromise. Snowflake is not an isolated exception. It fits a broader breach pattern where identity provenance is weaker than the attack path. Practitioners should expect credential abuse to remain the dominant NHI failure mode until governance can prove ownership, revocation, and least privilege end to end.

From our research:

• 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.
• For adjacent analysis, read Guide to the Secret Sprawl Challenge for the governance patterns that turn secret exposure into recurring identity risk.

What this signals

Ephemeral secret exposure is becoming a board-level identity problem, not a niche cloud issue. The Snowflake case fits a broader pattern in which stolen machine credentials can create immediate operational blast radius. Teams that still separate IAM, PAM, and NHI governance will miss the point: the attack surface is defined by identity lifetime, not by whether the account is human or non-human.

The practical signal for programmes is that service account inventories need to be tied to ownership, revocation, and dependency mapping before incident response can be effective. If the account can survive after the team that created it has moved on, the programme has not governed it. That gap is especially dangerous where contractor access and recursive permissions are common.

With 64% of valid secrets leaked in 2022 still valid and exploitable today, per The State of Secrets Sprawl 2026, organisations cannot rely on detection alone. They need revocation paths that are operationally proven, not just documented in policy.

For practitioners

• 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. Include contractor-managed identities and legacy accounts that were never reclassified. The goal is to find credentials that survive compromise long enough to matter.
• Enforce ownership for every non-human identity Assign a named human owner, a backup owner, and a revocation path for each service account. If no one can approve rotation, offboarding, or access removal, the identity is already outside governance. Use this as a hard control, not a documentation exercise.
• 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. Strip unused paths, separate administrative roles from runtime roles, and require explicit justification for any persistent high privilege.
• Shorten the usable lifetime of every exposed secret Move service accounts toward shorter-lived credentials, enforced rotation, and revocation workflows that are triggered by compromise signals, not calendar dates alone. Pair that with monitoring for stale keys older than the latest operating baseline.
• Tie contractor access to lifecycle review Reassess external users and integrations at the same cadence as employee access, with explicit checks for necessity, authentication method, and ongoing business purpose. The article shows that outside parties often carry the same damage potential as internal identities.

Key takeaways

• The Snowflake compromise shows that service account abuse is a governance failure, not just an incident response problem.
• Long-lived credentials, unclear ownership, and recursive permissions combine to turn one exposed secret into broad data exposure.
• Organisations need lifecycle control for non-human identities, including ownership, rotation, and revocation, before compromise occurs.

Key terms

• Service Account: A service account is a non-human identity used by software, integrations, or automated processes to authenticate and access resources. Unlike a person, it has no judgment or intent, so its security depends entirely on how well its credentials, permissions, ownership, and lifecycle are governed.
• Standing Privilege: Standing privilege is access that remains active all the time instead of being granted only when needed. For service accounts, this creates a persistent blast radius because compromise of the credential can immediately expose whatever roles and permissions the account already holds.
• Recursive Role Grant: A recursive role grant is a permission chain where one role inherits access from another role, sometimes through several layers. This structure can make effective privilege much broader than the original account record suggests, which is why governance must assess the full inheritance path.

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.

👉 Token Security’s full post covers service account identity handling, recursive permissions, and mitigation steps in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.