How do organisations decide whether to centralise or decentralise secrets control?

Why This Matters for Security Teams

Secrets control is not just an administrative choice. It determines whether compromise stays contained or becomes reusable access across cloud, CI/CD, and application layers. When organisations centralise everything without narrowing retrieval, they often create a single high-value path that attackers can target. When they decentralise without policy consistency, secrets sprawl and weak ownership follow. The practical question is where trust must stop, not where provisioning is easiest.

This tension is visible in incidents covered in NHI Management Group research, including the Guide to the Secret Sprawl Challenge and the 52 NHI Breaches Analysis, where overly broad secret reach and weak scoping turn a single exposure into a much wider event. That pattern aligns with the OWASP Non-Human Identity Top 10, which treats unmanaged machine access as a recurring risk rather than an edge case.

In practice, many security teams discover the centralisation problem only after a pipeline, repo, or service account has already been reused outside its intended boundary.

How It Works in Practice

The strongest operating model is usually central policy with decentralised execution. That means one security authority defines how secrets are classified, issued, rotated, logged, and revoked, while applications, pipelines, and services retrieve only the secret they need at the moment they need it. This is the practical middle ground between a single shared vault and uncontrolled local handling.

In mature environments, the pattern often looks like this: central teams own the secret backend, policy-as-code, audit logging, and lifecycle rules; platform teams own integration points; application owners request access through scoped workflows; and runtime workloads authenticate with workload identity before retrieval. That approach matches the broader direction of the Ultimate Guide to NHIs | Static vs Dynamic Secrets, where long-lived credentials are replaced by short-lived, tightly scoped alternatives.

• Use central policy to define approved secret sources, TTL limits, rotation windows, and revocation triggers.
• Use workload identity and just-in-time access so a service proves what it is before receiving a secret.
• Keep retrieval local to the workload, but log every request centrally for detection and review.
• Separate administrative authority from operational access so no single team can both issue and freely consume high-value secrets.

For implementation guidance, SPIFFE is a useful reference for workload identity, and OWASP guidance remains helpful when designing least-privilege secret handling into engineering workflows. These controls tend to break down when legacy systems require shared secrets across multiple services because the integration model itself prevents clean scoping.

Common Variations and Edge Cases

Tighter central control often increases operational friction, so organisations need to balance governance strength against release speed and platform complexity. That tradeoff becomes more pronounced in hybrid estates, regulated environments, and large engineering organisations where many teams deploy independently.

Current guidance suggests there is no universal standard for where the line should be drawn, but there is broad agreement on one point: centralise the policy, decentralise only the minimum retrieval path, and avoid shared reusable credentials wherever possible. The CI/CD pipeline exploitation case study shows why pipelines deserve especially tight scoping, since build systems often become credential brokers if left unchecked.

Edge cases include air-gapped environments, embedded systems, and vendor-managed integrations. In those settings, true decentralisation may be unavoidable, but the compensating controls should still include separate rotation domains, short TTLs, explicit approval gates, and continuous secret discovery. The practical test is simple: if a secret can be reused by more than one workload without fresh authorisation, the design has already drifted toward unsafe centralisation.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams decide whether to keep AWS Secrets Manager as the primary control?
• How should organisations decide whether appsec, IAM, or platform teams own a control failure?
• How do organisations decide whether to prioritise secrets management or access governance first?