The Snowflake breach involved threat actors using valid credentials — including service account credentials and session tokens — obtained through infostealer malware to authenticate directly to customer Snowflake instances. The breach was enabled by absence of multi-factor authentication enforcement for service account access and use of long-lived credentials that remained valid for extended periods after being stolen. Service account credentials were not protected by MFA because MFA is typically designed for human interactive authentication and is not applied to service accounts in most environments.
Why This Matters for Security Teams
The Snowflake breach is a textbook example of why NHI governance cannot stop at human IAM assumptions. Threat actors did not need to break MFA on a person. They used stolen service account credentials and session tokens that were still valid, which is exactly the risk pattern documented in 52 NHI Breaches Analysis. That matters because service accounts, API keys, and tokens often sit outside the controls security teams rely on for employee accounts.
Current guidance from NIST Cybersecurity Framework 2.0 still supports disciplined access control, but the Snowflake case shows that the real weakness was operational: long-lived secrets, weak secret hygiene, and limited visibility into where credentials were stored and how long they remained usable. NHIs are also frequently over-permissioned, which turns a single stolen credential into broad reach across data and workloads, as discussed in Ultimate Guide to NHIs.
In practice, many security teams only discover this failure mode after a valid token has already been used from an unexpected location.
How It Works in Practice
The breach path was straightforward: infostealer malware harvested credentials from endpoint or browser environments, then attackers replayed those secrets directly against Snowflake tenants. Because service accounts are not usually governed by interactive MFA, the stolen secret itself became the authentication factor. That is why the problem is less about “missing MFA” in the human sense and more about failing to treat secrets as high-value identities with their own lifecycle, telemetry, and revocation process.
Operationally, stronger NHI control means short-lived access, tight scoping, and rapid invalidation. Security teams should distinguish between humans, workloads, and agents, then assign each a different trust model. For machine-to-machine access, best practice is moving toward workload identity, ephemeral issuance, and policy decisions made at request time, not just at onboarding. The same logic appears in NHI lifecycle guidance and in broader identity coverage from Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- Use JIT credentials with short TTLs so stolen secrets expire quickly.
- Store secrets in a managed vault, not in code, config files, or CI/CD variables.
- Bind service accounts to narrowly defined roles and review entitlements routinely.
- Log token use, source, and anomaly signals so replay is easier to detect.
- Revoke access immediately when compromise is suspected, rather than waiting for periodic rotation.
For implementation details, teams should align workload identity and policy enforcement with the identity and trust model described in NIST Cybersecurity Framework 2.0 and the control themes in Top 10 NHI Issues. These controls tend to break down when service credentials are embedded in legacy scripts, because the secret cannot be rotated or traced without disrupting production.
Common Variations and Edge Cases
Tighter NHI control often increases operational overhead, requiring organisations to balance faster rotation and narrower access against uptime and developer friction. That tradeoff is especially visible in data platforms, SaaS integrations, and batch automation where teams historically relied on durable credentials for convenience.
There is no universal standard yet for how every service account should be governed, but current guidance suggests treating high-impact NHIs differently from low-risk automation. Some environments can adopt full JIT issuance and workload identity quickly; others need a transition plan that starts with secret inventory, owner assignment, and forced rotation. If the account is used by external tooling, contractors, or data pipelines, the blast radius grows further, which is why Ultimate Guide to NHIs and Cisco DevHub NHI breach are useful references for understanding how quickly exposed credentials can be abused.
External reports also show the problem is not isolated. The Anthropic — first AI-orchestrated cyber espionage campaign report reinforces that automated, goal-driven actors can accelerate misuse once they obtain valid access. The NHI lesson from Snowflake is simple: if a secret can outlive the intent that created it, attackers only need one leak to turn authentication into unauthorised access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived, stolen credentials were the core failure mode in Snowflake. |
| NIST CSF 2.0 | PR.AC-4 | Snowflake shows why machine access needs tighter identity and entitlement control. |
| SPIFFE/SPIRE | Workload identity helps replace reusable secrets with cryptographic identity. |
Apply least privilege to service accounts and review entitlements as part of routine access governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
