Topic starter
07/11/2026 11:48 am
TL;DR: Multi-cloud and edge secrets governance finds that isolated vaults create inconsistent policy enforcement and weak auditability, according to Doppler. Practitioners need a governance layer that normalises access, rotation, and logging across every environment.
Editorial analysis by NHI Mgmt Group, based on content published by Doppler: “Implementing secrets governance across multi-cloud, on-prem, and edge environments”.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Secrets governance becomes necessary when vaults, workloads, and logs are fragmented across cloud, on-prem, and edge environments.
Glossary terms: Governance Control Plane, Dynamic Secret, Workload Identity, Role-Based Access Control
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/11/2026 11:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Secrets governance unifies fragmented vaults across environments