Who should own secrets security when organisations use multiple vaults and many delivery pipelines?

Ownership should sit with security and engineering together. Engineering needs to manage implementation in pipelines and applications, while security defines policy, monitors exposure, and sets escalation rules. Multiple vaults do not remove accountability. They increase the need for clear control ownership, standard processes, and regular review of where secrets are stored and used.

Why This Matters for Security Teams

When organisations run multiple vaults and many delivery pipelines, secrets ownership stops being a tooling question and becomes a control question. The real risk is not just where a secret is stored, but who can create, move, duplicate, rotate, and recover it across systems. NHIMG research shows 62% of secrets are duplicated and stored in multiple locations, which turns a single compromise into a broad exposure problem. See the Guide to the Secret Sprawl Challenge.

Security teams often assume a vault solves governance by itself. It does not. A vault is only one control point inside a larger secrets lifecycle that includes CI/CD injection, application runtime access, break-glass recovery, and offboarding. OWASP’s Non-Human Identity Top 10 treats secret handling as part of broader NHI risk, because leaked or overused credentials can be reused across automation paths. In practice, many security teams encounter secret sprawl only after a pipeline has already leaked a token or a duplicated secret has been reused in production.

How It Works in Practice

The cleanest operating model is shared ownership with clear boundaries: engineering owns implementation in pipelines, applications, and deployment tooling, while security owns policy, exception handling, monitoring, and review. That split matters because the people building delivery systems are the ones who know where secrets enter, transform, and exit the workflow. Security defines what is allowed, such as approved vaults, rotation intervals, logging requirements, and escalation triggers, then verifies that pipelines enforce those rules consistently.

In practice, this means every vault should have a named control owner, even if the organisation uses more than one for business, regional, or acquisition-driven reasons. The owner should be accountable for inventory, access review, rotation hygiene, and recovery procedures. A second layer of ownership should cover delivery pipelines, because secrets often move through CI/CD, build agents, deployment jobs, and runtime sidecars. NHIMG’s CI/CD pipeline exploitation case study shows how pipeline trust can become the weakest link when controls are inconsistent.

Useful operating controls usually include:

• One policy standard for secret naming, storage, and expiry, even when vault platforms differ.
• Automated inventory of every secret and every place it is consumed.
• Rotation rules tied to risk, not only to calendar schedules.
• Pipeline guardrails that prevent secrets from being echoed into logs, tickets, or commits.
• Escalation paths for exposed, duplicated, or stale secrets, with measurable response SLAs.

NIST SP 800-53 Rev. 5 supports this approach through access control, audit, and configuration management expectations, even though it does not prescribe a single vault operating model. The practical lesson is that ownership must follow the control surface, not the product boundary. These controls tend to break down when vaults are added by separate teams without central approval, because hidden duplicates and undocumented pipeline paths accumulate faster than review cycles can catch them.

Common Variations and Edge Cases

Tighter central control often increases delivery overhead, so organisations have to balance standardisation against pipeline speed and local platform needs. That tradeoff is real, especially in distributed teams, regulated regions, or acquisition environments where a single vault is not practical. Current guidance suggests the answer is not always “one vault,” but it is always “one accountable control model.”

There is no universal standard for this yet, but best practice is evolving toward federated operations with central policy. In that model, local teams can run approved vaults or platform-specific secret stores, while security retains visibility into inventory, exceptions, and lifecycle events. This becomes more important when secrets are embedded in ephemeral workloads, preview environments, or temporary deployment jobs, because short-lived systems create more churn and more places for secrets to leak. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful context here, especially when deciding whether a secret should be long-lived at all.

Where the model fails is usually not in the vault, but in governance drift: one team adds a vault without approval, another hardcodes a fallback secret for release reliability, and a third stores recovery material outside the standard process. That is why security and engineering must review ownership together on a recurring basis, not only after incidents. Multiple vaults can be acceptable, but only when the organisation can prove who owns each secret, each pipeline, and each exception path.

Related resources from NHI Mgmt Group

• Who should own secrets security and NHI governance across the enterprise?
• How should security teams add governance to existing Infrastructure as Code pipelines without disrupting delivery workflows?
• Who should own secrets governance when developers, DevOps, security, and compliance all touch the same credentials?
• How should organisations secure privileged access, non-human identities, and secrets before an identity security conference or major programme rollout?