Notifications
Clear all
Topic starter
25/06/2026 3:04 pm
TL;DR: DevOps teams can reduce pipeline friction by replacing static secrets with short-lived workload identities, which Aembit argues improves security while preserving developer velocity. The deeper issue is that access controls built around long-lived credentials do not scale cleanly across cloud, data centre, and emerging AI workloads.
NHIMG editorial — based on content published by Aembit: workload identity replaces secrets in DevOps access management
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- How GitLab-style pipeline identity is exchanged for cloud access without storing hard-coded keys
- The credential translation pattern for services that do not support direct OIDC federation
- Why workload identity reduces developer friction in multi-cloud and data centre environments
- The standards context around SPIFFE, OAuth extensions, and WIMSE for portable workload authentication
👉 Read Aembit's analysis of workload identity as an alternative to DevOps secrets →
Workload identity in DevOps pipelines: are secrets still the bottleneck?
Explore further
25/06/2026 4:22 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Workload identity replaces secrets in DevOps access management
