What should organisations do when they have secrets in Vault but identities elsewhere?

When Vault is only one control point, what has to be governed?

Vault solves storage, not the full identity and secret lifecycle. If identities are created in cloud IAM, Kubernetes, CI, or application code, the organisation needs a governance layer that reconciles those sources, defines ownership, and keeps creation, rotation, and revocation aligned across the whole estate.

The practical issue is not where the secret sits today, but whether the organisation can explain who can create it, who can use it, who can revoke it, and how that answer stays correct when teams and platforms change.

That is why the governance boundary should follow the credential and the identity together. A secret in Vault with an unmanaged source identity elsewhere is still a live access path, even if the storage system looks well controlled.

Where the control gap usually appears

The common failure is split ownership. Platform teams may manage Vault, while application, cloud, or cluster owners manage the identities that actually mint or consume credentials. When those responsibilities are not joined up, review becomes partial and revocation can miss the upstream actor that can recreate access.

Another gap is lifecycle mismatch. A workload identity, CI token, or cloud role can outlive the secret record in Vault, or the reverse can happen, leaving orphaned access paths, stale permissions, or manual exceptions that nobody revisits. The result is not just clutter, it is loss of control over who can legitimately re-establish trust.

For teams dealing with secret sprawl and rotation at scale, the Secret Sprawl Challenge is a useful reminder that leakage and governance problems often begin before the secret reaches the vault.

When the issue is specifically lifecycle drift, NHI lifecycle management maps the ownership, rotation, and offboarding problems that appear when the credential source and the secret store are governed separately.

What good governance looks like in practice

Good practice is to treat Vault as an enforcement and storage plane, then add an inventory and decision layer above it that knows every external identity source. That layer should reconcile metadata for cloud IAM roles, Kubernetes service accounts, CI jobs, and application-issued credentials so policy can be applied consistently.

It should also support a simple decision rule: if a source identity can recreate or refresh a secret, then revoking the stored secret alone is insufficient. The governance process must also disable, rotate, or re-authorise the upstream identity and record the ownership chain.

Where secrets are issued dynamically, teams often need the discipline described in rotation challenges, because short-lived credentials reduce exposure only when expiry, renewal, and dependency mapping are accurate.

The same logic applies to APIs, service tokens, and machine credentials. If the organisation cannot tell whether a credential is static, dynamic, or recreated by automation, then Vault is being used as a repository rather than a governance control.

Risk and Threat Considerations

When identity and secret creation are split across platforms, the main risk is hidden persistence. An attacker or rogue workflow can keep regaining access through an unmanaged source identity even after the visible secret is rotated or removed from Vault.

Failure mechanism: The stored secret is treated as the control point, while the upstream creator, issuer, or renewer remains active. That leaves a durable path for credential reissuance, privilege retention, or lateral movement through cloud, CI, or Kubernetes trust chains.

Impact: Revocation becomes partial, reviews miss the true authority boundary, and compromised access can survive longer than teams expect. In practice, the blast radius is larger because the organisation believes it has removed access when it has only replaced one secret value.

Practitioner Guidance

What to measure: Track the percentage of secrets with a declared upstream owner, an expiry or rotation rule, and a tested revocation path that reaches the original issuer. Those three signals reveal whether Vault is controlling access or merely storing it.

Decision rule: If a secret can be recreated by an identity outside Vault, treat that upstream identity as part of the control boundary and include it in review, offboarding, and exception handling.

Practitioner takeaway: The real control objective is end-to-end revocation certainty, not centralised storage, so governance must cover every identity that can mint, renew, or reuse the secret.

Practitioner Guidance

What to prioritise: Build a single ownership model for each secret family, with one named owner for the secret, one for the upstream identity, and one for revocation. If those are different teams, make the handoff explicit and auditable.

What to verify: For every high-value secret, verify the source of creation, the systems that can renew it, and the systems that can consume it. If any of those are unknown, the control is incomplete even if the secret itself is stored securely.

Common mistake: Treating Vault cleanup as equivalent to access removal. That assumption fails whenever cloud IAM, Kubernetes, or CI can silently recreate access after the stored value is deleted.

Practitioner takeaway: The organisation should govern the credential supply chain, not just the credential store, because revocation only works when the upstream identity can no longer reissue the access path.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• Why do organisations outgrow basic secrets vaults when they start managing application identities across CI/CD and production environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?