Secrets management build vs buy: the governance trade-offs that matter

At a glance

What this is: This is a build-versus-buy analysis of secrets management that argues lifecycle control, scalability, and compliance are the deciding factors, not storage alone.

Why it matters: It matters because secrets management is an NHI governance problem, and weak lifecycle handling of credentials expands breach risk across application, cloud, and pipeline access.

By the numbers:

• 27 days
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read Akeyless's guide to secrets management build versus buy decisions

Context

Secrets management is the control discipline for protecting, rotating, auditing, and revoking credentials such as API keys, tokens, and certificates across their lifecycle. In modern application environments, the primary governance problem is not whether secrets exist, but whether they are centralized, monitored, and revoked before exposure becomes compromise.

The article frames a familiar enterprise decision: build a custom secrets platform or buy a commercial one. For IAM and NHI programmes, that choice is really about whether the organisation can sustain lifecycle governance, audit trails, and least privilege across hybrid, multi-cloud, and CI/CD environments without creating another unmanaged control layer.

Key questions

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. Build only when the organisation can sustain that operational burden at scale. Buy when the main requirement is dependable lifecycle control across many environments, but only if integrations and offboarding are under governance, not left to vendor defaults.

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. Without a unified view, secrets can stay active after their business purpose ends, remain unrotated, or escape policy enforcement altogether. That turns credential management into a visibility and accountability problem, not just a storage problem.

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. A credential may be disabled in one place while still active in another, which means exposure can persist even after the security team believes the secret has been remediated.

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.

Technical breakdown

Why secrets sprawl breaks centralized control

Secrets management becomes fragile when credentials are duplicated across vaults, code repositories, tickets, and runtime systems. Each extra copy widens the exposure surface and creates divergent rotation states, which means the same secret may be valid in one place, expired in another, and still recoverable in a third. That fragmentation undermines centralized revocation and makes audit evidence incomplete. In practice, the control failure is not just storage, but governance consistency across every place a secret can exist.

Practical implication: track secret locations as an inventory problem, not only a vault problem, and remove duplicate credential paths before they create independent trust domains.

Build versus buy changes the operating model, not the risk

A custom secrets platform can fit unusual workflows, but it also creates a standing obligation to engineer rotation logic, logging, monitoring, and patching. A commercial platform shifts some of that burden into the vendor lifecycle, yet the organisation still owns access policy, integration integrity, and offboarding discipline. The key technical question is whether the team wants to own the full control plane for secrets or only govern it. Either way, the risk remains if lifecycle management is treated as a one-time deployment task.

Practical implication: evaluate who owns rotation, revocation, and monitoring after deployment, then assign control ownership explicitly before choosing a path.

Why multi-cloud and CI/CD make secret governance harder

Secrets in multi-cloud and CI/CD environments move through APIs, pipelines, orchestration layers, and developer tooling at high speed. That creates more authentication events, more integration points, and more chances for secrets to be exposed in transit or logged unintentionally. The technical challenge is not merely scale, but consistency of policy enforcement across environments with different identity models and release cadences. Without strong integration and auditability, automation can accelerate exposure as easily as it accelerates delivery.

Practical implication: require secrets governance to work natively across pipelines and cloud platforms before expanding automation or developer self-service.

Threat narrative

Attacker objective: The attacker aims to turn a leaked or stale secret into persistent application access that bypasses normal user controls.

1. Entry occurs when a secret is copied into a repository, ticketing system, pipeline log, or unmanaged vault, creating an unintended access path.
2. Escalation follows when the exposed secret is reused across environments or remains valid after rotation should have removed it.
3. Impact occurs when the credential enables unauthorized application access, lateral movement across workloads, or sensitive data exfiltration.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Build versus buy is really a question of control ownership. Custom platforms can match specialised workflows, but they also make the organisation responsible for patching, monitoring, failover, and compliance evidence. Commercial platforms reduce some engineering burden, yet they do not remove the need for strong policy and offboarding governance. The decisive issue is whether the team can sustain operational discipline after go-live.

Secrets sprawl is the hidden failure mode in hybrid identity programmes. The more vaults, pipelines, and integrations an organisation adds, the more likely it is that duplicate credentials, inconsistent rotation states, and weak audit trails will emerge. This is the secret lifecycle fragmentation problem: control exists in theory, but authority is split across too many runtime locations. Practitioners should treat fragmentation as a governance defect, not an efficiency trade-off.

Least privilege is only meaningful when secret scope matches actual runtime use. A secret that is shared across multiple applications or environments violates the assumption that access can be cleanly bounded at provisioning time. In that condition, compromise radius expands faster than teams can detect it. The lesson for identity programmes is to align secret scope, usage boundary, and offboarding process as one control set.

From our research:

• 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.
• That same research shows 44% of developers are reported to follow security best practices for secrets management, which is why lifecycle control must extend into engineering workflows.

What this signals

Secret lifecycle fragmentation is the operational risk most teams under-estimate. Once the same credential is present in multiple vaults, pipelines, and tickets, rotation stops being a single action and becomes a coordination problem across systems that were never designed to agree.

The next maturity step is not simply tighter storage. It is to treat secrets as governed identities with explicit owners, measurable revocation paths, and tested failure modes across application, cloud, and CI/CD estates.

This is where the NHI Lifecycle Management Guide becomes the more useful reference point than a pure vault strategy, because the real question is whether credentials can be issued, rotated, and removed without leaving residual access behind.

For practitioners

• Inventory every secret location Map where credentials exist across vaults, code, pipelines, tickets, and runtime systems before selecting a build or buy path. The goal is to expose duplicate secret paths and eliminate unmanaged copies that create separate revocation problems.
• 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. Do this before deployment so the control model is not assumed later.
• Require offboarding and revocation tests Verify that expired credentials stop working in every environment, including downstream tools that may cache or mirror them. Use offboarding tests to confirm that former access does not survive in shadow systems.
• Tie CI/CD use to least privilege Limit pipeline credentials to the narrowest runtime scope and check that they cannot be reused across unrelated services. If a secret can authenticate more broadly than the pipeline requires, the blast radius is already too large.

Key takeaways

• Secrets management fails when organisations confuse vaulting with lifecycle governance.
• Duplicate credentials and inconsistent rotation state are the clearest indicators that control has fragmented.
• The practical test is whether a retired secret stops working everywhere, not whether it is stored in a secure system.

Key terms

• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines — typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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.

👉 Akeyless's full article covers implementation trade-offs, scalability considerations, and long-term support questions in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.