Snowflake’s NHI sprawl shows why static credentials no longer scale

At a glance

What this is: This is an analysis of how Snowflake’s growth exposed non-human identity sprawl and why static credentials became the wrong model for workload access.

Why it matters: It matters because identity teams must govern machine, agent, and human access with different control patterns once non-human identities outnumber employees and operational scale changes.

By the numbers:

• 69% of organisations now have more machine identities than human ones.
• Only 38% have automated certificate lifecycle management in place.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents.

👉 Read Aembit’s analysis of Snowflake’s workload identity approach

Context

Snowflake’s workload identity problem is a machine identity governance problem: the environment grew until non-human identities, not employees, became the dominant access surface. Once that happens, static secrets, manual provisioning, and inconsistent service-account controls stop being edge cases and become the operating model.

The key shift is that machine access has to be treated as a lifecycle discipline, not a one-time engineering task. Teams that already struggle with visibility, ownership, and credential rotation should map the problem to workload identity governance, then align it with resources such as the Guide to SPIFFE and SPIRE and the Ultimate Guide to NHIs , Key Challenges and Risks.

Key questions

Q: How should security teams replace static credentials for workloads?

A: They should move workloads to short-lived, policy-based authentication that issues access at runtime and removes reusable secrets from code, pipelines, and shared vaults. The goal is not just better secret handling. It is reducing persistence, limiting blast radius, and making each workload access event traceable to identity and policy.

Q: Why do service accounts become harder to govern at scale?

A: Service accounts become harder to govern when ownership, rotation, and usage are spread across teams and platforms without a single lifecycle view. At scale, the problem is less about creating credentials and more about knowing which ones still need to exist, who can use them, and whether they are still aligned to the workload they support.

Q: What breaks when machine identities rely on manual provisioning?

A: Manual provisioning breaks consistency. It creates delays, duplicates credentials across systems, and leaves teams unable to prove which workloads received which access and why. In practice, that weakens auditability and creates hidden privilege drift across cloud, SaaS, and internal applications.

Q: How do you know workload identity controls are actually working?

A: You should be able to show that access is issued without static secrets, that every workload has a clear owner, and that audit logs reconstruct identity, policy, and destination for each transaction. If those three signals are missing, the control is reducing effort but not yet governing risk.

Technical breakdown

Why static credentials fail in workload identity environments

Static credentials create a durable trust problem because the same secret can be reused, copied, embedded, or left active long after the original need has passed. In a workload-heavy environment, that turns authentication into a persistence mechanism rather than a control. The issue is not just leakage. Long-lived credentials also make it difficult to prove who or what used them, when they were issued, and whether the access path still matches the workload that requested it. That weakens auditability and makes blast radius hard to contain.

Practical implication: replace long-lived secrets with short-lived, policy-issued access paths for workloads.

Policy-based workload access versus manual provisioning

Policy-based access replaces human-operated credential handling with runtime decisions based on workload identity, context, and authorization rules. The security gain comes from removing the need to pre-place reusable secrets in pipelines, applications, or config stores. This is especially important when applications span cloud services, SaaS platforms, and custom integrations, because a single manual process rarely scales cleanly across all three. In practice, the architecture has to answer two questions at once: is this workload who it claims to be, and should it receive this access in this environment now?

Practical implication: centralise workload authentication policy so teams stop issuing bespoke credentials by platform.

How auditability changes when machine access becomes dynamic

Dynamic authentication improves auditability only if the organisation preserves the policy decision, the identity assertion, and the access event together. Without that record, automation can reduce friction while still leaving gaps in evidence. For machine identities, the real control objective is not just access issuance. It is being able to reconstruct the access chain later for incident response, privilege review, and compliance. That is why governance tooling alone is insufficient when it only surfaces inventory and does not close the loop on issuance and revocation.

Practical implication: require centralized logs that tie every workload access event back to identity, policy, and destination.

NHI Mgmt Group analysis

Machine identity sprawl changes the control problem before it changes the toolset. Once non-human identities outnumber employees, governance moves from managing exceptions to managing the default state of access. The relevant frameworks are OWASP-NHI and Zero Trust, because the primary failure mode is not a single exposed secret but an environment where no team can reliably enumerate, classify, or retire every workload identity. Practitioners should treat this as a lifecycle and inventory problem first, and a tooling problem second.

Static credential dependence is the wrong trust model for workload access. The article shows why secrets managers, cloud-native point solutions, and manual provisioning all struggle when access is distributed across SaaS, cloud, and custom systems. That aligns with the OWASP Non-Human Identity Top 10 concern set around secret sprawl and overprivilege. The implication is that machine access cannot be governed as if it were a manually reviewed human session.

Policy-based authentication is the operational boundary that matters most for machine identities. The useful shift is not simply moving credentials around faster. It is replacing durable secrets with an access decision that is bound to workload identity, environment, and policy at runtime. That is a workload identity governance problem, and it belongs in the same control conversation as ZT-NIST-207 and NIST-CSF access management. Practitioners should focus on whether their current architecture can issue, explain, and retire access without human handling.

Ephemeral credential trust debt: This article exposes a familiar failure mode in modern machine identity programmes, where short-lived access is promised but long-lived operational habits remain underneath. The debt accumulates when visibility tools, manual provisioning, and ad hoc service accounts keep the old model alive even after teams claim to have modernised. Practitioners should audit where the control plane still depends on human memory and shared operational shortcuts.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• 53% of organisations have experienced a security incident directly related to machine identity management failures, according to SailPoint.
• For broader machine identity governance context, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and overprivilege patterns that make scale hard.

What this signals

With 66% of organisations saying their current tooling is not adequate to manage the scale of machine identities they now have, the programme risk is not a future shortage of features but a present mismatch between access volume and governance design. Teams should expect workload identity ownership, rotation, and audit evidence to become board-level questions, not just platform tasks.

Ephemeral credential trust debt: Organisations that retain manual provisioning, static secrets, and fragmented access logs are accumulating a control debt that gets harder to repay as machine identities grow. The operational signal to watch is whether workload access can be issued and retired without human handling across SaaS, cloud, and internal systems.

The next phase of identity governance will be less about defending the human perimeter and more about proving that machine access is continuously bounded. For teams building Zero Trust programmes, that means workload identity controls now sit alongside IAM, PAM, and lifecycle governance rather than outside them.

For practitioners

• Inventory every non-human identity and owner relationship Build a complete register of applications, service accounts, pipelines, and integrations, then assign a clear owner and lifecycle state to each. Treat unknown ownership as a control failure, not an admin issue.
• Eliminate hardcoded and long-lived workload secrets Move workloads toward short-lived, policy-issued access and remove secrets from code, config files, and shared vault patterns that keep credentials in circulation.
• Standardise runtime policy for cross-platform access Use a single authorization model that can govern access across SaaS, cloud, and custom applications instead of letting each platform define its own credential habit.
• Preserve end-to-end audit evidence for machine authentication Log identity, policy decision, target system, and revocation event together so incident response and access review can reconstruct workload behaviour later.

Key takeaways

• Snowflake’s example shows that non-human identity sprawl becomes a governance problem long before it becomes a headline risk.
• Static credentials and manual provisioning do not scale cleanly across modern workload environments, especially when applications span cloud, SaaS, and custom systems.
• Practitioners need runtime policy, complete ownership, and reconstructable audit evidence if they want workload identity controls to hold at enterprise scale.

Key terms

• Workload Identity: A workload identity is the digital identity used by software rather than a person. It covers applications, services, pipelines, and AI-linked processes that need authenticated access to other systems. In mature programmes, it has an owner, a lifecycle, and policy-bound access rules.
• Static Credential: A static credential is a long-lived secret such as an API key, token, or certificate that remains valid until it is rotated or revoked. In machine environments, static credentials increase exposure because they can be copied, reused, embedded in code, and forgotten after deployment.
• Policy-Based Authentication: Policy-based authentication grants access only when an identity, environment, and authorization rule all align at runtime. For non-human identities, this reduces reliance on hardcoded secrets and makes workload access more traceable, but only if policy and logging are tightly coupled.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and accounts across systems and teams. In machine identity programmes, it usually shows up as duplicated service accounts, unclear ownership, and access paths that no one can confidently inventory or retire.

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.

This post draws on content published by Aembit: Snowflake Secures Workload Access. Read the original.