Notifications
Clear all
Topic starter
06/06/2026 2:31 am
TL;DR: Secrets managers store and rotate credentials, but they do not decide whether a workload should have access, under what conditions, or for how long; Aembit’s analysis argues that workload IAM fills that governance gap by verifying nonhuman identity and issuing short-lived, scoped credentials. The broken assumption is that credential storage can substitute for runtime access control.
NHIMG editorial — based on content published by Aembit: Workload IAM vs. Secrets Management: A Practical Decision Guide
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should security teams handle trust assumptions when using ephemeral NHI credentials?
A: Treat ephemeral credentials as a risk reducer, not a complete control model.
Q: Why do secrets managers fail as access governance for workloads?
A: Secrets managers fail as access governance because they store and deliver credentials, but they do not evaluate whether the workload should still have access.
Q: When should organisations move from vault-centric control to workload identity?
A: Organisations should move when service-to-service access depends on shared secrets, when workloads span more than one cloud, or when rotation is becoming a manual bottleneck.
Practitioner guidance
- Separate secret custody from access decisions Inventory where your vault stores credentials and where policy actually decides access.
- Replace bootstrap secrets with platform identity Eliminate secret zero patterns wherever workloads can authenticate through platform-issued identity signals, federated workload identity, or attested runtime context.
- Audit cross-cloud service trust chains Map every AWS-to-Azure, cloud-to-SaaS, and pipeline-to-database trust path that still relies on shared secrets or manually configured federation.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- A practical decision guide for separating secrets management from workload access governance in hybrid environments
- The runtime identity and conditional access patterns used to replace static secret trust in service-to-service flows
- Why cloud-native IAM boundaries force teams into bridging controls, and where those bridges reintroduce risk
- How AI agents and distributed workloads change the economics of credential rotation and offboarding
👉 Read Aembit's analysis of workload IAM versus secrets management →
Vaults vs workload IAM: what IAM teams need to change now?
Explore further
06/06/2026 4:14 am
Credential storage is not access governance: This article exposes the core control gap in many NHI programmes. A vault can secure a secret, but it cannot judge whether the workload is still trusted at the moment of use, which means least privilege is being approximated through rotation rather than enforced through access policy. Practitioners should treat that as a governance boundary, not a tooling preference.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: What is the difference between secret rotation and workload access governance?
A: Secret rotation changes the lifespan of a credential, while workload access governance decides whether a workload can receive one in the first place. Rotation reduces exposure after issuance. Governance reduces the chance that an untrusted or outdated workload ever gets access, which is the stronger control.
👉 Read our full editorial: Workload IAM is replacing vault-centric access control for NHIs
