Workload IAM exposes the secretless governance gap for NHI access

At a glance

What this is: This case study shows how Snowflake moved workload-to-workload access away from long-lived secrets and toward policy-based workload IAM with dynamic credential issuance.

Why it matters: It matters because NHI and IAM teams are being pushed to govern workloads as identities, not just to store and rotate secrets.

By the numbers:

• Snowflake says the approach cut 85% of credential issuance, credential rotation, and auditing follow-up.
• For every human identity your IAM program governs, there are roughly 82 machine identities operating outside it.

👉 Read Snowflake's case study on workload IAM and secretless access

Context

Workload access is a Non-Human Identity problem, not just a secrets problem. When service accounts and API keys are issued to move data between systems, the governance gap appears when those credentials become long-lived, hard to audit, and widely shared across applications. In this case, the primary keyword is workload IAM, and the core issue is whether access can be tied to workload identity instead of static secrets.

Snowflake's account is typical of larger environments that grew up around manual credential issuance, rotation, and owner tracking. That model can keep systems running, but it does not scale cleanly when automation, compliance, and least privilege all need to work at the same time. The shift to identity-based control reflects a broader NHI lifecycle problem that many teams still manage with spreadsheets, tickets, and ad hoc reviews.

Key questions

Q: How should security teams govern workload IAM in cloud environments?

A: Treat workload IAM as part of the identity plane, not as a separate automation task. Each workload should have an owner, a defined purpose, and policy-based access tied to request time conditions. Short-lived credentials reduce exposure, but teams still need logging, review, and revocation paths that work at machine speed.

Q: When does just-in-time access create more risk than it reduces?

A: Just-in-time access becomes risky when the policy engine trusts weak posture signals, when workload ownership is unclear, or when access records are incomplete. In those cases, the organisation may issue cleaner secrets but still expand the blast radius of a compromise. Governance must be stronger than the issuance mechanism.

Q: What is the difference between secret rotation and workload identity governance?

A: Secret rotation changes the credential, while workload identity governance controls who or what is allowed to receive access in the first place. Rotation reduces exposure time, but governance addresses ownership, context, policy, and auditability across the whole lifecycle. Mature programmes need both, but governance comes first.

Q: Why do NHIs complicate zero trust architecture for IAM teams?

A: NHIs complicate Zero Trust Architecture because workloads can request access continuously, at scale, and often without human review. That means trust decisions have to rely on policy, posture, and telemetry rather than user-centric controls. If those signals are weak, Zero Trust becomes a label instead of a control model.

Technical breakdown

How workload identity brokers replace static credential delivery

A workload identity broker sits between the requesting workload and the target service. Instead of handing out a durable secret, it validates the workload's identity, checks policy, and issues a short-lived credential at request time. This changes the control point from secret storage to identity verification and policy decisioning. The practical difference is that access becomes ephemeral and auditable, while the credential itself is no longer the primary trust anchor.

Practical implication: Treat the broker as part of your identity plane and review its policy logic like any other access control system.

Why secretless access still depends on posture and context

Secretless does not mean context-free. In this model, access may depend on workload posture, time of request, environment, and the sensitivity of the target service. That moves the design closer to Zero Trust Architecture, where authentication alone is not enough. The failure mode is simple: if posture signals are weak or stale, the broker can still mint valid credentials for a workload that should not receive them.

Practical implication: Define which posture checks are mandatory before you allow any NHI to receive a live credential.

What changes in the NHI lifecycle when credentials are issued just in time

Just-in-time issuance compresses the useful life of a secret and reduces the need for periodic manual rotation. But it also shifts attention to provisioning, revocation, logging, and owner accountability. If a workload can request access dynamically, then offboarding and entitlement review must be equally dynamic. The lifecycle problem does not disappear, it moves upstream into policy, identity binding, and system-of-record quality.

Practical implication: Map workload identities into your lifecycle process so review, revocation, and audit evidence happen continuously.

Threat narrative

Attacker objective: The attacker wants durable, reusable access to sensitive workload-to-workload paths without needing repeated exploitation.

1. Entry occurs when a workload is given a long-lived service account or API key that can be reused beyond the original request.
2. Escalation follows when multiple humans touch privileged credentials or when one secret is reused across several workloads.
3. Impact is persistence of unauthorized access and a wider blast radius because the credential remains valid until someone finds and rotates it.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Workload IAM is becoming an identity governance problem, not a point solution problem. Moving from credential delivery to policy-based access changes the unit of control from secret to identity. That means IAM teams, platform teams, and security operations now share responsibility for the same access decision. The practical conclusion is that workload access must be governed as part of the identity lifecycle, not handled as a separate automation layer.

Secretless architecture reduces exposure, but it does not remove trust debt. A short-lived credential still depends on the broker, the workload posture signal, and the integrity of the policy engine. If any of those trust inputs are weak, the control can become a cleaner path to bad access rather than a prevention layer. Practitioners should treat ephemeral access as a narrower blast radius, not as proof of strong assurance.

Identity blast radius is the right concept for this category. The important question is no longer how many secrets exist, but how far a single workload identity can propagate across services, pipelines, and reporting lines. Once a credential can be issued on demand, the real risk is policy misbinding and hidden reuse across environments. Teams should measure blast radius, not just credential count.

Conditional access for NHI should be judged on evidence quality, not vendor claims. The controls that matter are workload posture, environment binding, request provenance, and revocation speed. Without those, just-in-time issuance can still support broad unauthorized access if the underlying identity is compromised. The practitioner takeaway is to require proof that the policy inputs are monitored, logged, and testable.

The market signal is clear: machine identity governance is converging with access automation. The old split between secrets management and IAM is becoming less useful as workloads, APIs, and agents all request access dynamically. Security leaders should expect more tooling to claim coverage across lifecycle, policy, and audit evidence at once. The right response is to re-evaluate whether your current stack can govern workloads end to end.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• From our research: 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
• The governance lesson is not just visibility. It is lifecycle control, and the NHI Lifecycle Management Guide is the right next step for provisioning, rotation, and offboarding.

What this signals

Identity blast radius is the operational metric that should replace secret count. In environments where workloads can request access dynamically, the question is not whether you have a secrets vault, but how far one compromised workload identity can reach before revocation. With 69% of organisations now having more machine identities than human ones, the control problem is scaling faster than manual governance.

Programme owners should expect workload IAM to converge with policy-as-code, audit automation, and Zero Trust Architecture. That means access reviews will increasingly depend on machine-readable evidence, not ticket history or spreadsheet tracking. The teams that win here will be the ones that can bind identity, posture, and logging together across the lifecycle, using the Ultimate Guide to NHIs for lifecycle management as a baseline.

For practitioners, the forward risk is policy drift. When dynamic access is introduced without clear ownership, revocation, and provenance controls, the environment becomes easier to operate but harder to defend. The right response is to treat workload access as a governed identity class, with explicit links to NIST Cybersecurity Framework 2.0 functions for govern and protect.

For practitioners

• Inventory workload identities and service accounts Build a complete register of workloads, their owning teams, target services, and any long-lived credentials still in use. Prioritise accounts that cross environments or are shared by multiple applications.
• Replace static secrets with short-lived issuance where possible Move high-value workload access to just-in-time credentials and remove direct secret storage from application paths. Validate that break-glass procedures still exist for emergency access.
• Bind access decisions to workload posture Require request-time checks for environment, health, provenance, and expected time window before issuing credentials. Do not rely on identity alone when the workload can be compromised or cloned.
• Integrate workload access into your audit trail Capture who requested access, which workload was evaluated, what policy was applied, and what credential was issued. Use the record for access reviews, offboarding, and incident response.

Key takeaways

• Workload IAM is shifting NHI governance from static secret handling to policy-based identity control.
• The scale problem is already structural, with machine identities outnumbering human identities in most organisations.
• Teams should measure identity blast radius, posture quality, and lifecycle control before they rely on secretless access.

Key terms

• Workload Identity: A workload identity is the machine-facing identity used by software, services, and automation to authenticate and request access. It replaces assumptions based on static secrets with a more structured trust relationship, usually tied to an environment, service, or workload instance.
• 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.
• Identity Blast Radius: Identity blast radius is the amount of access, lateral reach, and operational damage that can follow from one compromised identity. For NHIs, it is shaped by credential reuse, policy scope, environment trust, and how quickly access can be revoked.
• Conditional Access for NHIs: Conditional access for NHIs means issuing or denying access based on workload context, such as posture, time, environment, or request source. It extends least privilege beyond role assignment and makes access decisions more responsive to machine risk.

Deepen your knowledge

Workload IAM and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are moving from static secrets to policy-based workload access, it is worth exploring.

This post draws on content published by Snowflake: Securing Workload Access with Aembit and Workload IAM. Read the original.