Governing NHIs by access, not credentials, is the real control shift

At a glance

What this is: This analysis says NHI governance fails when teams protect secrets in vaults but do not manage the access they enable across their lifecycle.

Why it matters: IAM, IGA, PAM and NHI teams should treat secrets as governed access grants, because static credentials create persistent privilege that outlives the systems and workflows they support.

👉 Read P0 Security's analysis of why NHI governance starts with access, not credentials

Context

Static credentials are secret values such as API keys, tokens and service-account passwords that grant access without a human login step. In NHI programmes, the governance problem is not where those values are stored but whether anyone owns them, can revoke them, and can prove they are still needed.

P0 Security's article argues that vaulting is a storage control, not an access control. That distinction matters because many cloud and CI/CD environments still leave long-lived credentials embedded in scripts, terraform, containers and internal documents, which turns secrets into unmanaged standing privilege.

The article frames this as an NHI lifecycle problem: if a credential outlives its purpose, the identity behind it remains active long after governance should have closed it. That is a common production pattern, not an edge case.

Key questions

Q: What breaks when organisations rely on scanners or vaults without full NHI governance?

A: Scanners and vaults solve only part of the problem if organisations do not also govern ownership, rotation, exposure, and offboarding. Without those controls, teams may find secrets but still leave them active, duplicated, or overused. The result is false confidence, slow remediation, and persistent access paths that attackers can exploit.

Q: Why do static NHI credentials create more risk than human credentials in cloud environments?

A: Static NHI credentials are reusable, often high privilege, and usually lack the human controls that limit user accounts, such as MFA and session review. They also tend to spread into code, logs, and pipelines, which makes compromise easier to scale across connected systems.

Q: What are the signs that NHI credential governance is broken?

A: Common signs include secrets in repositories, repeated rotation work with no net reduction in exposure, unclear ownership across DevOps and security, and credentials that survive beyond the workload that was meant to use them. Those patterns show that the programme is managing leakage, not governing the credential lifecycle.

Q: How should security teams govern just-in-time access for non-human identities?

A: Security teams should treat JIT as a timing control, not a trust control. Require contextual checks on the issuer, workload, and requested resource before granting access, and define deny rules for identities that behave outside baseline patterns. That approach limits abuse while preserving production continuity.

Technical breakdown

Why vaulting does not equal governance

A secrets manager reduces plaintext exposure, but it does not answer the governance questions that matter for NHI risk. It does not prove ownership, enforce expiry, revoke unused access, or tell you whether a credential is still embedded in an application path. In practice, that means the control protects the secret as data while leaving the underlying access entitlement untouched. When a service account password or API key remains valid after the workload changes, the organisation has preserved convenience but not control. That is why vaulting can create a false sense of security in dynamic cloud environments.

Practical implication: treat vaulting as a storage safeguard and add ownership, lifecycle and revocation controls around every secret.

How standing privilege emerges in cloud and CI/CD workflows

Static credentials persist because modern delivery pipelines reward anything that keeps builds and deployments running. Secrets get copied into terraform, scripts, environment variables and containers, then reused across environments because no one wants to interrupt a working system. Over time, that creates standing privilege, which is access that remains continuously valid rather than being issued only when needed. The operational danger is not just exposure but persistence. Once a credential is embedded in automation, it can survive the workload, the team and sometimes the vendor relationship that originally required it.

Practical implication: inventory where credentials live in automation paths and remove hardcoded access from build and deployment logic.

What ephemeral access changes in NHI governance

Ephemeral access changes the governance model from credential custody to access issuance. Instead of preserving a reusable secret indefinitely, the programme grants short-lived, least-privileged access only for the task and then revokes it automatically. That is the difference between storing an identity artifact and controlling the entitlement itself. The article's central point is that governance begins when access is created, scoped, monitored and removed, not when the secret is placed in a vault. In NHI terms, the lifecycle is the control plane, not the storage layer.

Practical implication: move NHI controls toward short-lived access, automatic revocation and policy checks at issuance time.

Threat narrative

Attacker objective: The attacker wants durable access to sensitive systems through credentials that remain valid long after the environment that issued them has changed.

1. Entry occurs through static credentials such as API keys, tokens or service-account passwords embedded in infrastructure or automation.
2. Credential abuse follows when those long-lived secrets remain valid after the original purpose has changed or the secret has been copied into multiple workflows.
3. Impact comes from persistent, over-permissioned access to production systems and data that no one actively governs or expires.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vaulting is a storage control, not an NHI governance model: putting a secret in a vault reduces plaintext exposure but leaves ownership, expiry, revocation and usage entitlement unresolved. That separation matters because a credential can be protected at rest and still function as standing privilege in production. NHI governance starts only when the access grant is managed, not when the secret is stored.

Static credentials create lifecycle debt: every long-lived API key, token or service-account password extends the period in which access can exist without active justification. The longer that lifespan, the more likely the entitlement will drift from the workload, team or environment it originally served. The implication is that lifecycle management, not storage hygiene, is the core governance problem.

Managing access is the right control boundary: the article correctly reframes the issue from secret handling to entitlement handling. That aligns with the practical reality that production risk comes from what a credential can do, not where it lives. Teams should therefore govern creation, ownership, scope, rotation and revocation as one access lifecycle.

Ephemeral credential trust debt: static NHI credentials accumulate trust that is never revalidated because the entitlement persists by default. Each unchanged secret becomes a liability that survives human attention cycles, which is why manual rotation alone does not solve the governance problem. Practitioners should treat that inherited trust as the core exposure to unwind.

Least privilege has to be enforced at issuance time: once a long-lived secret exists, downstream usage tends to outlast the business need that justified it. That makes static credentials incompatible with resilient NHI governance in cloud-native environments. The field should move from secret inventory to policy-driven access lifecycle control, or keep inheriting the same failure mode in new places.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: NHI Authentication Guide

What this signals

Ephemeral credential trust debt: static credentials do not just leak, they accumulate unreviewed trust that survives workload changes and ownership turnover. For NHI programmes, that means the real control objective is not secret storage but the enforced decay of access entitlement over time.

Teams moving from vault-centric thinking to lifecycle governance should expect their biggest gaps to show up in CI/CD, terraform and service-account sprawl, where static access is easiest to hide and hardest to retire. The practical test is simple: if a credential can keep working after the business reason for it disappears, the programme still has standing privilege.

Access reviews alone are too slow for secrets that may never be revalidated before the next deployment. That is why access issuance, expiration and revocation need to become the operational control points rather than manual cleanup after exposure.

For practitioners

• Audit all static NHI credentials Build an inventory of API keys, tokens and service-account passwords across code, terraform, CI/CD and internal documents, then identify which ones still grant production access.
• Assign accountable ownership at creation Require every credential to have a named owner, a business purpose and an expiry or review date so that access can be revoked without ambiguity.
• Replace reusable secrets with federated access Use role assumption and identity federation where the workload supports it, so the system requests short-lived access instead of carrying a persistent secret.
• Block new long-lived credentials in delivery pipelines Add service control policies or CI/CD guardrails that prevent teams from creating net-new static credentials in cloud and deployment workflows.
• Automate revocation and drift detection Detect credentials created outside governance policy, rotate them when exceptions are unavoidable and revoke access as soon as the entitlement is no longer needed.

Key takeaways

• Static credentials are the governance problem here, not just the storage problem, because they create access that persists without active ownership.
• The article's core evidence is operational rather than theoretical: secrets continue to survive in pipelines, scripts and documents even when vaults are in place.
• The control that changes the outcome is lifecycle governance, especially short-lived access, ownership assignment and automatic revocation.

Key terms

• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Ephemeral Access: Ephemeral access is permission that exists only for the duration of a specific task or session. For agents, it reduces the lifetime of credentials and limits blast radius if a workflow is abused or misrouted. The control is only effective when issuance, expiry, and revocation are enforced automatically.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Identity Lifecycle Event: A business event that changes a person’s access, obligations, or record status, such as hiring, role change, or offboarding. In HR programmes, these events often drive entitlement changes and evidence requirements, so they need to be governed as part of the identity lifecycle rather than handled as isolated paperwork.

What's in the full article

P0 Security's full post covers the operational detail this post intentionally leaves for the source:

• A step-by-step maturity path for replacing static credentials with federated identity in production environments
• Specific guidance on using service control policies and CI/CD guardrails to stop new long-lived credentials
• The article's practical examples of how ownership assignment and JIT access fit into ongoing NHI governance
• The context behind why vaults help with storage but still fail to govern where secrets are actually used

👉 P0 Security's full post covers the lifecycle controls, maturity steps and governance practices behind the argument.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.