Notifications
Clear all
Topic starter
25/06/2026 3:04 pm
TL;DR: DevOps teams still manage workloads with static credentials even though non-human identities now outnumber humans 45:1, and that mismatch makes least privilege hard to enforce across cloud, SaaS, and CI/CD environments, according to Aembit. The practical break point is structural: dynamic, policy-driven access is the only model that scales with modern workload identity.
NHIMG editorial — based on content published by Aembit: least privilege remains one of cybersecurity’s most fundamental principles, yet DevOps teams are failing at it for non-human identities
By the numbers:
- 45:1 in modern enterprises., tnumber human identities by 45:1 in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams implement least privilege for workloads that change constantly?
A: Security teams should stop relying on static roles and shared credentials for ephemeral workloads.
Q: Why do static secrets undermine zero trust for non-human identities?
A: Static secrets create standing trust before the workload proves anything at runtime.
Q: What do teams get wrong about rotating workload credentials?
A: They often treat rotation as the goal instead of a temporary mitigation.
Practitioner guidance
- Map every bootstrap secret path Trace where workloads first obtain trust, including container images, CI/CD variables, deployment scripts, and cloud init processes.
- Prioritise secretless migration for high-blast-radius workloads Start with databases, production deployment pipelines, and third-party integrations that currently depend on long-lived API keys or shared service accounts.
- Separate rotation from governance remediation Rotate secrets where you must, but do not mistake rotation for least privilege.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- Specific examples of how static secrets persist in CI/CD, container images, and deployment scripts.
- The runtime model for policy-driven credential injection across cloud, SaaS, and on-prem workloads.
- How workload identity attestation changes the bootstrap problem without moving authentication into application code.
- The implementation trade-offs between secret rotation, federation, and secretless access patterns.
👉 Read Aembit's analysis of why ephemeral access is the path to least privilege for workloads →
Static secrets and workload sprawl: why least privilege keeps failing?
Explore further
25/06/2026 4:23 pm
Least privilege for workloads fails because the organisation is still designing for stable identities, not runtime identities. Human IAM models assume access can be granted, reviewed, and removed on a cadence that outlasts the session. Workloads do not behave that way, especially across CI/CD, containers, and serverless. The implication is that access governance has to stop assuming a persistent credential lifecycle as the default.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Another 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, showing that exposure routinely becomes business impact.
A question worth separating out:
Q: How can organisations know whether workload least privilege is actually working?
A: They should be able to answer, in real time, which workload can reach which resource and why. If the answer depends on manual spreadsheets, ad hoc reviews, or tribal knowledge, the control is not working. The strongest signal is whether access can be issued, scoped, and expired without code changes.
👉 Read our full editorial: Ephemeral access is the only path to least privilege for workloads
