Secrets management vs. access management for NHI governance

At a glance

What this is: This analysis argues that secrets management and access management solve different NHI problems, and that treating them as interchangeable creates governance gaps.

Why it matters: IAM and NHI teams need separate controls for secret storage and runtime authorisation, or they inherit blind spots around least privilege, revocation, and ephemeral access.

👉 Read Aembit’s analysis of secrets management vs. access management for workloads

Context

Secrets management and access management are not the same control plane. In NHI governance, a vault can store credentials safely, but it does not decide whether a workload, agent, or pipeline should receive access at all. That distinction matters because static credentials still create blast-radius risk even when storage is centralised and encrypted.

The article frames a common enterprise failure mode: teams assume rotation and logging are enough, then discover that the credential itself has become the trust model. That is typical in environments where service accounts, API keys, and AI agents are expanding faster than review, offboarding, and revocation processes. The practical question is not whether secrets are protected, but whether access is being governed at the point of use.

Key questions

Q: How should security teams handle trust assumptions when using ephemeral NHI credentials?

A: They should treat ephemeral credentials as a risk reducer, not as a full control model. The credential must be issued only after the workload is authenticated, checked against policy, and limited to the minimum task scope. Otherwise, short lifetime still leaves broad privilege and weak revocation logic in place.

Q: What is the difference between secrets management and access management for workloads?

A: Secrets management stores and rotates credentials. Access management decides whether a workload should receive access, under what conditions, and for how long. The first protects the secret itself, while the second governs the runtime decision that determines whether the secret should exist in the first place.

Q: When does JIT access create more risk than it reduces?

A: JIT access becomes risky when teams focus on speed of issuance and ignore scope, context, and revocation. If the request is approved too broadly, the credential still grants too much access. JIT only improves security when the access window is short and the entitlement is tightly bounded.

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

A: NHIs complicate zero trust because machine-to-machine access is high volume, automated, and often non-interactive. A zero trust model still needs a reliable identity signal, contextual policy, and continuous verification. Without those, teams fall back to static secrets or broad trust relationships that weaken the architecture.

Technical breakdown

Why secrets managers stop at credential delivery

A secrets manager is built to store, encrypt, and deliver credentials such as API keys, tokens, and certificates. Its job ends when it hands a secret to a workload. After that point, it usually has no visibility into whether the secret is cached, copied into logs, reused elsewhere, or replayed from another runtime. That limitation is structural, not a configuration flaw. In NHI environments, the secret is only one part of the trust chain, while authorisation, runtime context, and revocation are separate decisions that need separate controls.

Practical implication: Treat vaulting as storage control, not as a substitute for runtime authorisation or NHI governance.

How workload IAM changes the trust model

Workload IAM shifts trust from possession of a stored secret to verification of a workload identity at runtime. The workload proves who it is through platform signals, attestation, or other cryptographically verifiable context, then receives short-lived credentials that are scoped to the request. This reduces the value of stolen secrets because the credential lifetime is shorter and the access context is narrower. The critical difference is that access is decided dynamically, not preloaded as a standing entitlement. That is why ephemeral credentials help, but only when paired with policy checks that consider the current workload state.

Practical implication: Use short-lived, scoped credentials only after the workload has been authenticated and authorised in context.

Why cloud IAM does not close cross-environment gaps

Cloud-native IAM systems are effective inside their own ecosystems, but enterprise NHI estates rarely stay inside one cloud. A workload in one environment often needs to reach APIs, databases, or SaaS services elsewhere, which pushes teams toward bridging trusts or shared secrets. That reintroduces the same static credential risk they were trying to remove. The technical problem is policy fragmentation: separate identity systems, separate audit trails, and separate lifecycle logic. Without a unifying layer, teams end up managing access by exception rather than by consistent identity rules.

Practical implication: Map every cross-environment dependency and remove shared secrets where federated or workload-native identity can replace them.

Threat narrative

Attacker objective: The attacker aims to reuse a stolen NHI credential to obtain durable access that appears legitimate to downstream systems.

1. Entry occurs when a secret is exposed in a log, ticket, config file, or pipeline artifact and later replayed from outside the intended runtime.
2. Escalation follows when that credential grants broader service-to-service access than the workload actually needs, allowing privilege abuse inside the trust boundary.
3. Impact is achieved when the attacker uses the borrowed identity to move through connected services, access data, or alter production workloads under legitimate-looking access.

Breaches seen in the wild

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

Secrets management is necessary, but it is not access governance. A vault can reduce exposure, centralise storage, and simplify rotation, but it cannot decide whether a workload should be trusted right now. The field keeps collapsing storage control into authorisation control, and that creates a false sense of closure. Practitioner conclusion: separate secret custody from access decisioning.

Ephemeral credentials lower risk only when the identity decision happens at runtime. Short-lived tokens are an improvement over standing secrets, but they do not solve overprivilege if the issuing policy is too broad. The real control is not the expiry time alone, it is the combination of identity proof, contextual policy, and request-scoped access. Practitioner conclusion: measure privilege width, not just credential duration.

Cross-cloud NHI sprawl is forcing a new governance pattern. Enterprises are no longer managing one vault and one IAM plane, they are managing many identities across workloads, clouds, and automation paths. That environment needs a consistent lifecycle model for provisioning, rotation, offboarding, and audit, or the weakest system becomes the de facto policy engine. Practitioner conclusion: govern the identity graph, not just the secret store.

Identity blast radius is now the key metric for machine access. The question is not whether a secret is encrypted at rest, but how far a compromised credential can travel before containment. That framing aligns better with NHI risk than storage-centric metrics do, because compromise often begins after legitimate issuance. Practitioner conclusion: design controls to shrink blast radius at the point of use.

Agentic AI makes the storage-versus-access distinction unavoidable. Autonomous systems can chain actions, call tools, and cross services without human intervention, which means static credentials create compounding risk if they persist beyond the task. The governance model has to follow the agent through issuance, use, and revocation. Practitioner conclusion: build policy for task-scoped machine identities before agent sprawl hardens into shadow AI.

From our research:

• 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.
• For lifecycle control, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce standing exposure.

What this signals

Identity blast radius is the governance gap most teams under-measure. Secrets storage metrics can look healthy while a compromised token still reaches too many downstream systems. That is why NHI programmes need to measure how far a credential can travel after issuance, not just where it is stored. Teams should align remediation to containment, using the OWASP Non-Human Identity Top 10 as a practical lens.

Lifecycle failure is where secrets sprawl turns into operational debt, and offboarding is the easiest place to see it. Our research shows 91% of former employee tokens remain active after offboarding, which means access removal is still lagging ownership changes and application retirement. Programme owners should connect identity lifecycle reviews to the NHI Lifecycle Management Guide and tighten revocation triggers.

As AI agents and automation expand, static credential models will keep colliding with zero trust expectations. The right response is not more vaults alone, but a governance design that verifies machine identity continuously and issues access only for the task at hand. Teams that map this early will reduce the chance that shadow AI becomes a persistent access path.

For practitioners

• Separate vaulting from authorisation decisions Document which systems store secrets and which systems decide access. Then require a runtime policy layer for every service account, token, or AI agent that needs conditional access beyond simple retrieval.
• Inventory cross-environment credential paths Trace every workload-to-workload and workload-to-SaaS dependency that still relies on shared secrets or manual trust. Replace those paths with federated or workload-native identity where possible.
• Shorten the lifetime of every machine credential Enforce task-scoped credentials with explicit expiry and automatic revocation. Prioritise the secrets that can reach production systems, because those create the widest identity blast radius.
• Tie offboarding to NHI revocation Add service accounts, API keys, and agent identities to offboarding workflows so they are disabled when owners change, pipelines retire, or applications are decomposed.

Key takeaways

• Secrets managers reduce exposure, but they do not replace runtime access governance for NHIs.
• The real control problem is identity blast radius, because a stolen credential is only as safe as the systems it can reach.
• Security teams should pair short-lived credentials with lifecycle revocation, contextual policy, and cross-environment identity controls.

Key terms

• Secrets Manager: A secrets manager is a system that stores credentials, tokens, API keys, and certificates in encrypted form and delivers them when needed. It reduces exposure compared with hardcoded secrets, but it does not decide whether a workload should be trusted or authorised to use the credential at runtime.
• Workload IAM: Workload IAM is the set of controls that verifies nonhuman identities and grants access based on runtime context rather than stored credentials alone. It combines identity proof, policy checks, and short-lived credential issuance so that machine access can be managed as a governed decision, not a static entitlement.
• Identity Blast Radius: Identity blast radius is the amount of access and system reach a compromised nonhuman identity can achieve before it is contained. The concept helps teams evaluate machine credentials by their downstream impact, not just by whether the secret is encrypted, rotated, or stored in a vault.
• Secret Zero: Secret zero is the initial credential or bootstrap trust anchor a workload uses to authenticate to a secrets system or other access service. It is a common weak point because it often lives outside the vault, which means the very mechanism meant to protect secrets still depends on a secret of its own.

Deepen your knowledge

Secrets management vs. access management is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is separating storage from authorisation for the first time, the course provides a practical starting point.

This post draws on content published by Aembit: Secrets Management vs. Access Management: What You Need to Know. Read the original.