Notifications
Clear all
Topic starter
17/08/2026 4:42 pm
TL;DR: Secrets management fragmentation across AWS Secrets Manager, Azure Key Vault, Kubernetes, HashiCorp Vault, and other platforms makes consistent policy enforcement, logging, and access revocation harder, according to Akeyless. The real issue is not tool count but the governance gap created when secrets live in multiple control planes and review cycles diverge.
NHIMG editorial — based on content published by Akeyless: Universal Secrets Connector and the challenge of secrets sprawl across multiple platforms
Questions worth separating out
Q: How should security teams govern secrets spread across multiple managers?
A: Start by assigning one authoritative system for each secret class and one owner for each connector.
Q: Why do secrets managers not fully solve NHI risk?
A: They solve custody, not runtime trust.
Q: What do security teams get wrong about secret management?
A: Teams often treat secret storage as if it were the same as access governance.
Practitioner guidance
- Inventory every secrets manager and connector Build a complete map of where API keys, certificates, passwords, and tokens are stored, used, and synced.
- Assign one authoritative source per secret class Define which system governs creation, update, and revocation for each credential type.
- Unify audit evidence across all secret stores Require a single reporting view for secret access events, privilege changes, and failed access attempts.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- How the Universal Secrets Connector is configured across AWS Secrets Manager, Kubernetes, and HashiCorp Vault
- How bidirectional secret synchronisation behaves when secrets are created, edited, or deleted in different systems
- Which connector targets and authentication methods are used for each platform, including access keys, bearer tokens, and service accounts
- What the demo workflow looks like in the Akeyless console when secrets are managed across multiple back ends
👉 Read Akeyless's article on Universal Secrets Connector and secrets sprawl →
Secrets manager sprawl: what it means for IAM and NHI control?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:47 pm
Secrets sprawl is an NHI governance problem before it is a tooling problem. Once credentials are split across multiple managers, the organisation no longer has one coherent control surface for lifecycle, logging, or revocation. That fragmentation makes it harder to prove who can access which secret, and harder to act when a credential is exposed. The practitioner conclusion is simple: treat secrets topology as part of identity architecture, not as an implementation detail.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do identity teams know whether secrets governance is actually working?
A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path. If they cannot quickly identify where a secret is used or remove it without breaking the workload, governance is still incomplete.
👉 Read our full editorial: Secrets manager sprawl exposes the limits of centralized oversight
