Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: Secrets management is presented as a lifecycle discipline for tokens, API keys, and certificates, with build-versus-buy framed around scalability, compliance, integration, and long-term operational burden in hybrid and multi-cloud environments, according to Akeyless. The practical issue is not just storage, but whether the programme can sustain rotation, auditability, and least-privilege control without creating brittle bespoke infrastructure.
NHIMG editorial — based on content published by Akeyless: What Is Secrets Management?
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should security teams decide whether to build or buy secrets management?
A: Decide based on who will own rotation, revocation, logging, patching, and incident response after deployment.
Q: Why do decentralized secrets create governance risk in hybrid environments?
A: Decentralized secrets create governance risk because lifecycle actions become fragmented across tools, teams, and platforms.
Q: What breaks when secrets are duplicated across multiple tools and vaults?
A: Revocation becomes unreliable, rotation states diverge, and audit evidence no longer tells a complete story.
Practitioner guidance
- Inventory every secret location Map where credentials exist across vaults, code, pipelines, tickets, and runtime systems before selecting a build or buy path.
- Assign lifecycle ownership explicitly Document who owns rotation, revocation, logging, and emergency disablement for each secret class, including service credentials used by applications and pipelines.
- Require offboarding and revocation tests Verify that expired credentials stop working in every environment, including downstream tools that may cache or mirror them.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step criteria for choosing a commercial secrets platform versus building a custom one.
- Expanded comparison of scalability, integration, compliance, and maintenance trade-offs.
- Implementation considerations for multi-cloud, hybrid, and bare-metal environments.
- Vendor-specific architecture and deployment claims that may matter during product evaluation.
👉 Read Akeyless's guide to secrets management build versus buy decisions →
Secrets management build vs buy: what should IAM teams weigh first?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
Secrets management is an NHI lifecycle problem, not a storage problem. The article correctly treats tokens, API keys, and certificates as credentials whose value depends on rotation, revocation, and auditability. That is the real governance layer, because a secret that cannot be lifecycle-managed behaves like standing privilege. Practitioners should judge any platform by whether it supports lifecycle control across every place the secret appears.
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.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: How can IAM teams reduce the risk of reusable secrets?
A: Reduce reuse by shortening secret lifetimes, binding credentials to context, and limiting where they can be presented. The goal is to make a stolen secret less useful outside its original system or device. That approach matters for both human authentication and NHI governance.
👉 Read our full editorial: Secrets management build vs buy: the governance trade-offs that matter
