TL;DR: Fragmented vaults across cloud, on-prem, and edge environments create visibility, policy, and audit problems that basic secrets managers cannot solve, according to Doppler. A governance plane, not another repository, becomes the control point when secrets lifecycle, access orchestration, and compliance must span every environment.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Doppler's blog post: Multi-environment secrets governance fails when vaults are treated as silos, and a governance plane is needed to unify visibility, policy, automation, and audit across cloud, on-prem, and edge systems.
Why it matters: Identity and security teams need a shared control model for secrets because fragmented lifecycle rules, access paths, and logs create operational risk across NHI and workload estates.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Context
Secrets governance starts with a simple problem: most organisations store credentials in several places, but govern them as if each vault were independent. That model breaks down when the same workload, pipeline, or service identity spans cloud, on-prem, and edge environments, because policy drift and audit gaps follow the secrets rather than the system they support.
The practical issue is not storage alone, but lifecycle control across distributed non-human identities and workloads. When rotation, revocation, ownership, and access approval are handled differently in each environment, teams lose the ability to answer basic questions about who can use which secret, where it is valid, and when it should expire.
That is why a governance layer matters more than another vault: it creates a single policy and visibility model across existing platforms, including secrets management and the systems that depend on them.
Key questions
Q: How do I govern secrets across multiple clouds and on-prem systems?
A: Centralise secret inventory, ownership, rotation, and audit across every platform, then enforce one policy for API keys, tokens, certificates, and service account credentials. A governance layer that centralises inventory, policy, and audit can span cloud and on-prem systems while keeping source systems for storage and rotation separate. That reduces orphaned secrets and makes revocation, expiry, and access review consistent.
Q: What is the difference between a secrets manager and a governance plane?
A: A secrets manager stores, issues, rotates, and retrieves credentials such as API keys, tokens, and certificates. A governance plane coordinates inventory, policy, ownership, approvals, and audit across one or more secret stores, so teams can apply consistent lifecycle control without relying on a single vault for every use case. The distinction is operational control versus credential storage.
Q: How does dynamic secret rotation reduce credential exposure?
A: Dynamic secret rotation reduces exposure by issuing short-lived credentials on demand and replacing them before they can be reused for long. Instead of static passwords or long-lived API keys, the secret exists only for a limited session or transaction, which narrows theft windows and limits blast radius if a credential is logged, copied, or leaked. Revocation and expiry become built-in controls.
Q: What should teams do first when secrets are scattered across environments?
A: First build a complete inventory of where secrets live, including code repositories, CI pipelines, configuration files, image layers, vaults, and on-prem systems. Then classify each secret by owner, type, and privilege level so you can prioritise rotation, remove duplicates, and eliminate unmanaged copies. Without inventory, you cannot safely revoke, rotate, or audit credentials at scale.
Technical breakdown
Why vault sprawl turns secrets governance into a lifecycle problem
Secrets sprawl appears when credentials, keys, and tokens are distributed across separate vaults, pipelines, and runtime environments without a common control model. The technical failure is not only duplication, but inconsistent metadata, ownership, and expiry rules, which makes the same secret behave differently depending on where it lives. In practice, that means one vault may rotate aggressively while another leaves the same class of credential valid for months. Governance has to reconcile these differences at the lifecycle layer, not just centralise storage. Read Guide to the Secret Sprawl Challenge.
Practical implication: Build a single inventory of secret locations, owners, and expiry states before trying to standardise policy.
How a governance plane coordinates access, policy, and audit
A governance plane sits above existing secret stores and coordinates how secrets are issued, used, rotated, and observed. It aggregates metadata from multiple environments, applies global access policy, and centralises audit data so that access events can be correlated across cloud, on-prem, and edge systems. The important architectural distinction is that the plane does not replace the vaults; it binds them into a unified control model. That lets teams enforce consistent rules for role mapping, approval workflows, and temporary access without rewriting every platform.
Practical implication: Define a control layer that can map identities, enforce policy, and normalise audit records across all secret stores.
Why dynamic credentials and event-driven revocation reduce exposure
Dynamic secrets reduce standing exposure by generating credentials on demand and limiting how long they remain valid. That changes the attack surface from persistent secrets to short-lived access windows. Event-driven revocation extends the model by tying secret retirement to identity or operational events, such as deactivation, termination, or incident response. The design works only when issuance, rotation, and revocation are linked to the lifecycle of the workload or user that consumes the secret. Without that linkage, short-lived credentials still drift into long-lived risk. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.
Practical implication: Tie credential issuance and revocation to workload and identity events so secrets do not outlive their operational purpose.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
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
Secrets governance is really workload governance by another name: once credentials move across clouds, clusters, and edge systems, the control problem is no longer where the secret is stored. It is whether the organisation can enforce one set of issuance, rotation, and revocation rules across every runtime that depends on it. The practitioner conclusion is that secrets policy must follow the workload, not the vault.
Vault silos create governance drift faster than they create inventory: separate tools often produce separate ownership models, separate audit trails, and separate expiry habits. That fragmentation turns the same secret class into different risk profiles depending on environment, which is why visibility alone is not enough. The practitioner conclusion is that harmonised policy and audit are inseparable from storage.
Secret sprawl is the named failure mode this model addresses: fragmented vaults, duplicated credentials, and inconsistent logs create a condition where governance cannot answer basic lifecycle questions in time. That is why secret sprawl is not just an operational inconvenience but a structural control gap in multi-environment identity estates. The practitioner conclusion is to treat sprawl as a governance defect, not a housekeeping issue.
Static secrets remain the hardest part of the model because they accumulate hidden trust debt: long-lived credentials survive environment changes, team changes, and application rewrites, while their original approval context disappears. The implication is that governance programmes must assume persistence will outlast intent unless rotation and retirement are explicitly enforced. The practitioner conclusion is to prioritise the classes of credentials that can survive the longest without review.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Read next: Secrets Management Guide
What this signals
Secret governance will increasingly be judged by lifecycle consistency, not vault count: environments can tolerate multiple stores, but they cannot tolerate multiple rules for issuance, expiry, and revocation. The organisations that win here will make the policy layer portable across clouds, edge nodes, and on-prem systems.
Secret sprawl: the failure mode is not simply too many credentials, but too many places where ownership, expiry, and audit semantics diverge. Once that happens, teams lose the ability to prove whether a secret is still valid, where it is allowed to operate, or when it should have been retired.
Practitioners should expect audit pressure to shift toward evidence of centralised control rather than point-in-time vault hygiene. A single inventory, normalised logs, and event-driven revocation will matter more than whether a team can list every secret by hand.
For practitioners
- Map every secret source and runtime dependency Inventory cloud vaults, on-prem stores, CI/CD systems, Kubernetes environments, and edge devices, then record where each secret lives, who owns it, and which workload depends on it.
- Define one governance plane for policy and audit Create a central control layer that aggregates metadata, normalises access rules, and collects audit events across all vaults instead of allowing each environment to operate with its own policy logic.
- Replace static credentials with short-lived issuance Use dynamic secrets, workload identity, and temporary tokens wherever possible so credentials expire quickly and do not remain valid after the task or runtime session ends.
- Automate revocation on identity or lifecycle events Trigger secret retirement when a user is deactivated, a workload is terminated, or an environment is retired, and make the revocation path part of the same workflow that issued the credential.
- Separate location-bound secrets from global policy For regulated or data-residency constrained environments, keep secrets in-region while still pulling policy and log data into the central governance layer for monitoring and compliance reporting.
Key takeaways
- Secrets governance becomes necessary when vaults, workloads, and logs are fragmented across cloud, on-prem, and edge environments.
- The clearest evidence in the source material is that only 44% of organisations use a dedicated secrets management system, 73% of vaults are misconfigured, and only 5.7% have full visibility into service accounts.
- Practitioners need a governance plane that unifies policy, audit, and lifecycle control without forcing a rip-and-replace of existing vaults.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Static vs Dynamic Secrets · Secrets Management Guide · Guide to the Secret Sprawl Challenge · Multi-Cloud Identity Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Doppler's governance model is built around reducing exposed secrets across scattered vaults and logs. |
| NHI-07 — Long-Lived Secrets | Static credentials and slow rotation are central to the exposure model this post addresses. | |
| NHI-05 — Overprivileged NHI | The article stresses role mapping and access scope control to stop workloads inheriting excessive secret access. | |
| Recommendation — Scan every environment for exposed secrets and revoke or replace any credential that appears in code, logs, or pipelines. Replace long-lived secrets with short-lived credentials and enforce rotation deadlines across all vaults. Limit NHI access scopes to the minimum required for each workload and review inherited permissions regularly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The governance plane standardises secret access across environments through mapped identities and approvals. |
| DE.CM-01 — Continuous Monitoring | Centralised audit collection and SIEM correlation are core to the article's governance model. | |
| Recommendation — Apply PR.AA-05 to enforce consistent permissions and approval rules for secrets access across environments. Feed secret access events into continuous monitoring so abnormal use is visible across all environments. | ||
Key terms
- Governance Control Plane: The layer where identity policy is enforced across approvals, reviews, and revocations. It becomes materially stronger when it can consume external risk signals in real time, because access decisions are no longer isolated from the security state of the identities they govern.
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
Deepen your knowledge
NHI governance, machine identity security, 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 programme, it is worth exploring.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org