Workload IAM exposes the secretless governance gap for NHI access

At a glance

What this is: This case study describes Snowflake’s move to Workload IAM for workload-to-workload access, showing how secretless access reduces credential handling while tightening policy-based control and audit visibility.

Why it matters: It matters because IAM teams managing NHI, workload identity and automation need to treat credential issuance, access policy and evidence capture as one governed workflow, not separate tasks.

By the numbers:

• Aembit says Snowflake cut 85% of credential issuance, credential rotation and auditing follow-up after shifting to secretless workload access.
• Snowflake estimated the approach could save 5–10 hours a day across credential issuance, compliance reviews, reporting, auditing and process management.

Context

Workload IAM is the governance model for non-human identities that need to authenticate and access services without relying on static secrets. In this case study, Snowflake’s problem was not simply credential sprawl, but the operational gap between workload access requests, policy enforcement and audit evidence.

The article shows why secretless access becomes compelling when application ecosystems expand: every new workload-to-workload connection adds rotation overhead, manual ownership checks and compliance reporting work. The governance issue is not whether automation exists, but whether it is tied to identity, policy and evidence in the same control plane.

Key questions

Q: What breaks when workload access still depends on static secrets?

A: Static secrets create persistent access paths that outlive the workload, which makes compromise easier to exploit and harder to contain. The real failure is governance, because the environment assumes credentials can be tracked, rotated, and retired at the same pace as services. In cloud-native estates, that assumption is often false.

Q: Why do long-lived workload credentials increase governance and audit risk?

A: They force teams to maintain separate processes for issuance, rotation, ownership and compliance evidence. That fragmentation increases the chance that a credential remains valid after the workload changes, and it makes it difficult to prove who approved access, under what policy and for how long.

Q: How can teams tell whether workload access is still too secret-driven?

A: A strong signal is finding access keys embedded in source code, environment variables, old infrastructure or CI/CD pipelines with no clear owner. Another warning sign is rotation measured in months or quarters instead of runtime issuance. If the team cannot say who last used a credential and for what purpose, governance is too weak.

Q: What should IAM teams do when workload identity spans multiple services?

A: Treat the workload identity as the governed object, not each individual secret. That means mapping the access path, defining policy conditions for the workload’s context, and keeping a single system of record for issuance and review across the services it touches.

Technical breakdown

Why long-lived workload credentials create control drift

Snowflake’s starting model reflects a common NHI pattern: a service account or access credential is issued, stored and reused across application flows. That creates control drift because the credential outlives the original request and may be copied into multiple workloads, while humans remain involved in storage, cataloguing and rotation. The risk is not only exposure. It is that the organisation loses a clean line between who asked for access, what it was for and whether it is still justified. Workload IAM tries to re-establish that line by moving the decision to access time rather than issuance time.

Practical implication: map every workload secret that persists beyond its original purpose and identify where ownership and review have already become ambiguous.

How just-in-time workload access changes the identity model

Just-in-time workload access means credentials are not pre-positioned for indefinite reuse. Instead, the access request is evaluated at runtime and the credential is issued only when policy conditions are met. Snowflake describes this as moving from managing credentials to managing access. That shift matters because the workload presents its native identity, the broker validates it, and the issued credential can be short-lived and scoped to the request. The architectural change is subtle but important: the control point moves from secret storage to policy-driven issuance, which reduces standing access without forcing developers to handle credentials directly.

Practical implication: design workload access flows so that credential issuance happens only after policy evaluation, not as a static setup step.

What identity-based logging and conditional access add to governance

Secretless access alone does not solve governance unless the organisation can prove why access was granted. Snowflake’s case shows the value of logging the request, the policy outcome and the issued credential as a single record. Conditional access adds another layer by checking workload posture before access is granted, such as whether the workload is actively managed or operating in an expected context. This is the difference between removing secrets and actually governing access. Without that evidence chain, teams may reduce rotation work but still lack the audit trail needed to explain access decisions.

Practical implication: require policy decision logs and workload posture checks to be retained with the access event, not stored as separate operational artefacts.

Threat narrative

Attacker objective: The objective is to exploit stale or overused workload credentials to gain persistent access to internal services or sensitive data paths.

1. Entry occurs through routine workload-to-workload access requests that depend on service accounts and stored credentials rather than ephemeral identity decisions.
2. Escalation happens when long-lived credentials are reused beyond the original workload or touched by multiple humans, expanding the effective trust boundary.
3. Impact is prolonged maintenance burden, weaker auditability and a larger attack surface for workload access abuse.

Breaches seen in the wild

• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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

NHI Mgmt Group analysis

Secretless access does not remove the governance problem, it relocates it. The central question is no longer where to store the secret, but how access is issued, checked and evidenced at the moment of use. That is why workload IAM must be treated as an identity governance control plane, not a convenience layer. Practitioners should judge the design by whether it closes the loop between request, policy decision and audit record.

Workload IAM exposes the secretless governance gap: static credential reduction is only half the model if policy and evidence remain fragmented. Snowflake’s case shows that rotation, ownership tracking and audit follow-up are all symptoms of the same problem, which is unmanaged workload access lifecycles. The practitioner implication is that secretless does not mean control-less, and it fails when identity, policy and reporting are still separate workflows.

Workload identity becomes the durable control point for NHI governance. Once applications and services authenticate as workloads rather than as shared credentials, the governance burden shifts to identity verification, policy conditions and issuance logging. That aligns with OWASP-NHI concerns around long-lived secrets and overprivileged NHI, but only if the organisation actually uses the workload identity as the primary access decision point. Teams should reframe workload access as lifecycle governance, not tool administration.

The mature model is not secrets elimination, it is managed access with evidence. The strongest signal in this case study is the move to a central system of record for workload-to-workload access. That gives governance teams the artefacts they need for review, compliance and incident investigation. Practitioners should treat that record as part of the control itself, because without it secretless access can still become undocumented access.

Named concept: secretless governance gap. This is the space between removing static credentials and proving that access is still authorised, posture-checked and auditable. It matters because many NHI programmes stop at secret reduction and never close the evidentiary gap. The practitioner conclusion is straightforward: if you cannot prove the access decision, you have not governed the access, even if no secret was stored.

What this signals

Secretless controls only work when issuance, policy and evidence stay bound together. If access review, credential delivery and audit logging are split across teams or tools, the organisation may reduce secret exposure without improving governance. The stronger pattern is runtime issuance plus retained decision evidence, because that is what lets IAM teams prove access was authorised.

Workload identity changes the governance boundary for NHI programmes. The control objective shifts from protecting a secret at rest to governing the full access decision lifecycle for a workload. That has direct implications for NHI lifecycle management, privileged access oversight and compliance reporting, especially where service accounts once acted as the default trust primitive.

For practitioners

• Audit workload credentials with standing reuse Identify service accounts and access credentials that persist beyond their original workload purpose, especially where multiple applications or humans touch them.
• Move issuance to runtime policy checks Require workload access requests to be evaluated at the moment of use, with short-lived credentials issued only after policy conditions are met.
• Add workload posture checks before access Verify that the requesting workload is in an expected managed state before issuing credentials, rather than trusting the request path alone.
• Centralise access evidence for review Keep the request, the policy outcome and the issued credential together so compliance reviews and audit follow-up do not depend on manual chase-down.

Key takeaways

• Workload IAM addresses a familiar NHI problem: static credentials make access hard to govern once they are stored, reused and rotated manually.
• The article’s key evidence is operational as well as security-related, with Snowflake describing an 85% reduction in credential issuance, rotation and auditing follow-up.
• The governance lesson is that secretless access only improves security when identity verification, policy enforcement and audit evidence are managed together.

Key terms

• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.
• Just-in-time Credential Issuance: Just-in-time credential issuance creates access only when a request meets policy and then limits how long the credential remains valid. It reduces standing exposure, but it still depends on strong policy, accurate context, and reliable revocation handling.
• Workload Posture Check: A workload posture check is an access decision signal that evaluates the state of the requesting workload before a credential is issued. It can include management status, expected operating context and other conditions that help distinguish a legitimate workload from an untrusted one.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.