Workload identity replaces secrets in DevOps access management

At a glance

What this is: This is an identity-first analysis of DevOps access management that argues static secrets are the wrong abstraction and workload identity is the better control point.

Why it matters: It matters because IAM, NHI, and platform teams need one access model that works across pipelines, services, and emerging AI workloads without expanding secret sprawl or operational drag.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Aembit's analysis of workload identity as an alternative to DevOps secrets

Context

DevOps access breaks down when teams treat authentication as a secrets-handling problem instead of an identity problem. Static credentials create durable attack paths, while rotation workflows add friction that developers experience as pipeline slowdown and operations overhead. For workload identity, the real governance question is whether access can be made short-lived, auditable, and invisible to the people building software.

That shift matters across pipelines, services, and cloud platforms because the control surface changes from secret storage to identity issuance and policy. It also fits the wider NHI programme, where workload identity, secrets management, and lifecycle governance need to be treated as one connected discipline rather than separate tooling decisions. The article's starting position is typical of organisations that have outgrown manual credential handling but have not yet standardised on identity-first access.

Aembit frames the problem as one of friction, but the operational issue is broader: teams often have multiple identity patterns running in parallel, from static cloud keys to ephemeral tokens and platform-native federation. The more environments an organisation runs, the more dangerous it becomes to rely on secrets as the default access primitive.

Key questions

Q: How should security teams replace static secrets in DevOps pipelines?

A: Start by identifying every pipeline, job, and service that still depends on reusable credentials. Replace those credentials with workload identity and short-lived tokens issued at runtime, then keep policy and audit controls in the identity layer rather than inside code. The goal is to make access ephemeral, scoped, and observable without adding developer friction.

Q: Why do static credentials create more risk than developers expect?

A: Static credentials persist across runs, environments, and people, so one exposure can become long-lived access. They also hide where trust exists, which makes revocation and audit slower than the compromise itself. In practice, the risk is not just leakage but reuse, because one secret often unlocks more systems than the original task required.

Q: What breaks when teams keep rotating secrets instead of changing the access model?

A: Rotation reduces exposure only after a secret already exists, so it leaves the organisation managing the same underlying problem through repeated maintenance. If identities remain static, teams still face secret sprawl, inconsistent revocation, and developer interruptions. The control failure is structural: the organisation is protecting access with better housekeeping instead of redesigning access around runtime identity.

Q: What should IAM teams do when cloud and data centre workloads use different identity primitives?

A: Standardise the governance model even if the token formats differ. Use a common identity policy, logging, and lifecycle approach across environments, then translate into the credential type each platform accepts. That prevents environment-specific exceptions from becoming permanent overprivilege paths and makes workload identity governable at enterprise scale.

Technical breakdown

Static secrets versus ephemeral workload identity

Static secrets are persistent credentials such as access keys, client secrets, and shared tokens. They are simple to deploy but hard to govern because the same value can survive across pipelines, environments, and teams. Ephemeral workload identity changes the model by issuing short-lived credentials tied to a verified runtime identity, such as a CI job or service workload. The key technical difference is that authentication becomes derived from the workload's identity context, not from a reusable secret stored somewhere else. That reduces standing exposure and makes revocation a policy problem rather than a hunt for copied values.

Practical implication: replace durable pipeline credentials with short-lived identity issuance tied to the workload's runtime context.

Why OIDC federation does not solve every workload access case

OIDC federation works well when the target system can consume standard federation tokens directly. The article points out a real limitation: some services, such as Snowflake in this example, may require a different credential format, so identity systems must translate verified workload identity into an acceptable token type. This is not a failure of identity-first design. It is a reminder that the control plane often needs token brokering, policy evaluation, and format conversion to keep authentication invisible while still matching downstream service expectations. The architecture matters because the workload should not inherit a reusable static secret just because a target service is less flexible.

Practical implication: design for credential brokering across heterogeneous services instead of falling back to shared static secrets.

Workload IAM at scale across cloud, data centre, and AI workloads

Workload IAM becomes a scaling problem once organisations operate across multiple clouds, on-premises systems, serverless runtimes, and AI-driven workloads. Each environment introduces different native identity primitives, which makes point solutions brittle and hard to standardise. The article correctly notes that standards such as SPIFFE and emerging workload identity work aim to make authentication portable across systems. The technical challenge is consistency: every workload needs an identity that can be verified, authorised, and audited in the same way, even when the underlying platform differs. Without that, identity logic fragments into environment-specific exceptions.

Practical implication: standardise workload identity patterns before multiplying platform-specific access exceptions.

Threat narrative

Attacker objective: The attacker objective is to convert one exposed credential into durable, multi-system access that can be reused for broader compromise.

1. Entry occurs when attackers or insiders obtain a durable static secret from code, configuration, or a shared credential store and use it to access a pipeline or downstream service.
2. Escalation happens when that long-lived credential is reused across systems or environments, allowing broader access than the original workload required.
3. Impact follows when the exposed credential enables data access, cloud control, or lateral movement into other services that trust the same identity.
4. The attacker objective is to turn a single leaked credential into persistent access that outlives the original pipeline run and expands across connected systems.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 identity is becoming the control plane for DevOps access. The article is right to move the discussion away from secret storage and toward identity issuance, because the operational unit that matters is the workload run, not the human who wrote the pipeline. Once access is tied to runtime identity and policy, secret management stops being the centre of gravity and becomes one downstream implementation detail. The implication is that IAM, PAM, and NHI governance teams should treat pipeline identity as a first-class access domain, not as an exception hidden inside DevOps tooling.

Ephemeral credential trust debt is the hidden cost of static access patterns. Every persistent key creates future remediation work, audit ambiguity, and developer drag. That debt is especially visible when organisations can describe their secret hygiene with confidence but still take weeks to remediate leaks. The field should stop measuring access by how many credentials are issued and start measuring how much standing trust remains in circulation.

Identity for the workload, not the key for the tool: that is the right governance concept for this article. Static secrets were designed for systems where access was granted once and reused many times. That assumption fails when modern delivery pipelines and AI-era workloads need short-lived, auditable, context-bound access that changes with each execution. The implication is not just to add more controls, but to reconsider whether secrets should remain the primary access primitive at all.

Workload identity governance now connects NHI and agentic AI readiness. The same access model that secures pipelines will increasingly be asked to govern autonomous or semi-autonomous runtime actors. That makes workload identity a bridge discipline between traditional NHI controls and emerging agent governance. Practitioners who standardise identity issuance, policy enforcement, and lifecycle oversight now will have fewer exceptions to absorb later.

Least privilege at scale fails when identities are reused across roles and environments. The article highlights a common operational shortcut. Shared or long-lived credentials collapse the distinction between a narrow task and a broad trust relationship, which is exactly how overprovisioning becomes normal. The practical conclusion is that least privilege has to be enforced at issuance time, not patched after the fact with ad hoc rotation and review cycles.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That behaviour gap is why the Guide to the Secret Sprawl Challenge is the natural next resource for teams moving from secret handling to identity-first access.

What this signals

Ephemeral credential trust debt is the governance problem hidden inside many DevOps programmes. As long as access is still issued as reusable material, every pipeline, service, and environment inherits a future remediation obligation that IAM teams will eventually have to pay down. The strategic move is to reduce the amount of standing trust in circulation, not just the number of stored secrets.

With 54% of organisations reporting dissatisfaction because not all secrets are secured, the operating model is already showing strain. That is a programme signal, not just a tooling complaint. Teams should expect more pressure to unify workload identity, secrets governance, and lifecycle oversight under one identity architecture rather than maintaining separate operational lanes.

The identity conversation now extends beyond pipelines into autonomous workloads and agentic execution. That means the same governance discipline used for service accounts, secret rotation, and access review will need to adapt as machine actors become more dynamic. Practitioners should watch for standards work around workload identity and token brokering, then align their internal architecture to those patterns early.

For practitioners

• Map every pipeline credential to a workload identity source Inventory where build and deployment systems still rely on access keys, client secrets, or shared tokens. Replace those paths with workload-bound identity issuance wherever the target service supports it, and document every exception where a static credential remains unavoidable.
• Treat token brokering as a control requirement When a downstream service cannot consume standard federation directly, use a brokering pattern that converts verified workload identity into the credential format the service expects. Keep policy, audit, and expiry logic in the broker rather than embedding secrets inside the pipeline.
• Remove shared credentials from multi-environment delivery paths Separate pipeline access by application, environment, and trust boundary so one leaked credential cannot serve as a universal key. This is especially important where teams deploy across cloud platforms, on-premises infrastructure, and data services with different identity primitives.
• Measure access by standing trust, not by credential count Track how many long-lived credentials remain in code, configuration, secret stores, and shared service accounts. Use that metric to prioritise remediation where persistent access, not just volume, creates the largest blast radius.

Key takeaways

• Static secrets remain an access governance problem, not just a credential hygiene issue, because they preserve standing trust across pipelines and services.
• The evidence shows a widening gap between confidence and reality, with leaked secrets taking weeks to remediate and many teams still struggling with fragmented control.
• The practical answer is to shift from secret management to workload identity, so access becomes short-lived, auditable, and easier to govern at scale.

Key terms

• Workload Identity: A workload identity is the machine-readable identity assigned to a service, pipeline, container, or application so it can authenticate without using a human-managed secret. It lets access decisions be tied to runtime context, lifecycle, and policy rather than to a reusable credential stored in code or a vault.
• Ephemeral Credential: An ephemeral credential is a short-lived access token issued for a specific task, runtime, or session. In workload environments, it reduces standing exposure because the credential expires quickly and is usually bound to a verified identity and policy decision rather than being reused across multiple runs.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of passwords, keys, tokens, and certificates across code, tools, and teams. It creates fragmented ownership, weak visibility, and slow revocation, which makes access governance harder even when organisations believe they are managing secrets centrally.
• Credential Brokering: Credential brokering is the process of translating a verified identity into the specific token or credential format a downstream system accepts. It is useful when a target platform does not support direct federation, because it keeps identity policy in one place while adapting to heterogeneous services.

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: workload identity replaces secrets in DevOps access management. Read the original.