Centralised vs Decentralised Secrets Management

Choosing between one central secrets platform and a store per cloud, team or cluster decides how far a single compromise spreads, which secrets ever get rotated and whether anyone can produce a complete inventory. Most estates become decentralised by accident rather than by design. This guide compares the two models, and the hybrid most mature estates reach, on blast radius, rotation coverage, identity federation to the store, inventory visibility, availability dependencies, cost and sprawl. It is for platform, cloud security and identity architects. The principles of secrets management are in the Secrets Management Guide and the procurement questions are in the Secrets Management RFP Template; this page does not repeat either. Products are named only as examples of each pattern and are listed alphabetically.

Key takeaways

Centralise the control plane, not necessarily the storage. One policy model, one inventory and one audit stream matter more than whether every secret physically sits in one product; OWASP notes that standardising and centralising "can mean that you use multiple secret management solutions".
Blast radius follows the access boundary, not the product count. A single vault with one over-broad policy is a bigger target than ten stores; ten stores with copied secrets and no owner are worse still.
Rotation coverage is the deciding metric. Central platforms rotate what they know about; decentralised estates rotate what each team remembers. Measure the share of secrets with a working rotation, per store.
Federation removes the bootstrap secret in both models. Workloads should reach any store with a platform-issued identity (IAM role, managed identity, OIDC token), never a long-lived token kept next to the code.
Hybrid needs one direction of truth. If secrets are synced between stores, pick one system of record, sync one way and alert on drift, or two stores will disagree during the incident that matters.

What each model means

Centralised secrets management runs one platform (sometimes one per regulatory zone) that holds secrets for all teams and clouds. Teams are tenants; a platform team owns the service. HashiCorp Vault Enterprise namespaces are an example of the tenancy pattern: each namespace is "an isolated environment with separate login paths" with its own secrets engines, auth methods, policies and tokens.

Decentralised secrets management uses the store closest to each workload: AWS Secrets Manager in each AWS account, Azure Key Vault per application, Google Secret Manager per project, Kubernetes Secrets per cluster. Ownership sits with the account or application team, and the cloud provider runs the service. Microsoft's Key Vault guidance is an explicit decentralised pattern: "Use one Key Vault per application, region, and environment", and one per tenant in multitenant SaaS.

Hybrid keeps a central system of record and policy, and delivers secrets into local stores where workloads consume them: a central vault syncing into cloud stores, or cloud stores feeding Kubernetes through External Secrets Operator. The Cloud Secrets Managers Guide covers the cloud services themselves.

Side-by-side comparison

Dimension	Centralised (one platform)	Decentralised (store per cloud, account or app)	Hybrid (central record, local delivery)
Blast radius of a store compromise	Potentially every tenant unless namespaces, policies and admin roles are tightly separated	Limited to one account, application or cluster	Central record is high value; local copies limit runtime exposure per environment
Blast radius of a policy mistake	One wildcard policy can expose many teams	One team's mistake stays local, but mistakes repeat across stores	Policy authored centrally; local stores need their own least privilege
Rotation coverage	Uniform engines and schedules; coverage visible in one place	Depends on each team; native rotation is strong for the provider's own services	Rotate at the record; copies refresh on sync
Identity federation to the store	Must trust identities from every cloud and CI system (JWT/OIDC, cloud auth methods)	Native: workloads already hold the provider's identity	Native at the edge; the sync process needs its own federated identity
Inventory visibility	One list, if teams actually use it	Must be aggregated from every account, subscription and cluster	One list at the record, plus drift checks on copies
Availability dependency	Every application depends on one service and its network path	Each workload depends on its own regional cloud service	Runtime reads stay local; central outage delays changes, not reads
Cost model	Platform licence or hosting plus a platform team	Per-secret and per-call fees, spread across many bills	Both, plus sync tooling
Typical sprawl failure	Shadow stores created by teams the central service is too slow for	Duplicate secrets, inconsistent tagging, orphaned stores	Copies that outlive the record, and two-way edits

Threat model for each option

Both models face theft from cloud secret stores (ATT&CK T1555.006 Cloud Secrets Management Stores), credentials left in files (T1552.001) and abuse of cloud accounts that can read them (T1078.004); the attacker's aim point differs.

Centralised, primary target: the platform's administrative plane. Root or sys-level tokens, the unseal or recovery keys, the identity that can write auth configuration and anyone who can change policy. One compromise at this layer is total. The LastPass breach shows the human version of the same risk: one engineer's vault held the cloud access keys and backup decryption keys, so one compromised person exposed everything.
Centralised, secondary target: broad read policies, where one CI identity can read every team's prefix.
Decentralised, primary target: the cloud identity plane. Anyone who gains a role with read permission on the store reads it; there is no separate vault login to pass. Resource policies matter: AWS warns that granting secretsmanager:PutResourcePolicy lets principals, "even those in other accounts", modify resource policies and escalate to full access.
Decentralised, secondary target: forgotten stores. An account or subscription nobody owns still holds valid secrets, and nobody reviews who can read them. The ARTEX agentic secret harvesting campaign moved from a leaked repository secret to Key Vault exfiltration in minutes, which is how fast an unreviewed store is emptied once any reader identity is exposed.
Hybrid, specific target: the sync identity. The process that writes into every local store holds write access everywhere, and it is often the least reviewed identity in the estate.

Blast radius and isolation boundaries

Microsoft states the principle plainly: "Grouping secrets into the same vault increases the blast radius of a security event because attacks might be able to access secrets across concerns." That is true of any store, so the design question is where the boundary sits.

Boundary	Centralised mechanism	Decentralised mechanism	Check
Team or tenant	Namespace or top-level path per team, with delegated admins	Separate account, subscription or project per team	No policy grants read across two teams' prefixes
Environment	Separate namespaces or clusters for production and non-production	Separate store per environment (the Key Vault guidance)	No non-production identity can read production
Administration	Break-glass root, scoped admin roles, recovery keys split across custodians	Cloud IAM admin roles, store-level resource policies	Count of identities that can change policy on each store
Region or jurisdiction	Separate cluster per jurisdiction where data residency applies	Regional store; Google user-managed replication pins locations	Replica locations match the data classification

A centralised platform matches the isolation of separate stores only if its tenancy and admin roles are actually used.

Rotation coverage

Rotation is where the models diverge most in practice. A central platform offers uniform engines (database, cloud, PKI) and dynamic credentials, so the platform team can report coverage across the estate and push every team towards short-lived secrets; see Dynamic Secrets and Ephemeral Credentials. Cloud-native stores rotate their own provider's resources well (for example AWS Secrets Manager rotation functions for supported databases), but third-party SaaS keys need custom rotation code in every account.

Replicas: AWS rotates the primary and "the new secret value propagates to all of the associated replica secrets", so rotation is configured once per secret, not per Region.
Copies outside the store: any secret copied into a CI variable, Kubernetes Secret or config file is outside rotation unless the copy is refreshed automatically.
Measure per store: the share of secrets with a rotation configured and succeeding, and the age of the oldest secret. See How to measure secret age and rotation coverage.

Identity federation to the store

Decentralised federation is native: the workload already holds the provider's identity. A centralised platform must trust identities from every environment. Vault's JWT auth method is an example: it verifies tokens against the issuer's JWKS, requires bound_audiences to match the token's aud claim exactly, and can require specific bound_claims such as repository or namespace.

Centralised risk: one loosely bound role (no claim on repository, branch or namespace) lets any workload from that issuer log in. Bind every role to the narrowest claims available.
Decentralised risk: cross-account reads. AWS requires a resource policy, an identity policy and a customer managed KMS key for cross-account access, because the AWS managed key cannot be used across accounts; every such grant is a path to audit.
Both: no long-lived token to reach the store; see the Secrets Zero Problem Guide and the Workload Identity Federation Guide.

Inventory visibility

A central platform gives one list of secrets, but only of secrets that teams put there. A decentralised estate gives accurate local lists that nobody aggregates. Either way the inventory needs the metadata OWASP lists: lifecycle events, who and what acted on the secret, contacts, intended use, secret type and rotation timing. Decentralised estates should build it from the control plane (stores per account, tags, last-rotated dates, owner register), then scan for secrets outside any store, because both models leak into code and chat; see Secrets Scanning vs Secrets Management.

Availability dependencies

OWASP warns that a secrets service "could receive a considerable volume of requests within a large organization" and that slow performance degrades dependent applications or startup times. Centralisation concentrates that dependency.

Model	What fails when the store is unreachable	Mitigation
Centralised self-managed	Every new pod, deployment and credential renewal across all clouds	Regional clusters; HashiCorp Vault performance secondaries serve reads locally and forward writes, while DR secondaries stay passive until promoted and share tokens and leases so applications continue
Decentralised cloud-native	Workloads in the affected Region and account only	AWS multi-Region replicas; Google automatic replication; Azure per-region vaults
Hybrid	Changes and rotations stop; local reads continue	Alert on sync lag; keep local copies short-lived enough to bound exposure but long enough to ride out an outage

Two behaviours surprise teams: applications must reauthenticate after a Vault performance secondary is promoted, and with Google user-managed replication a write fails during a regional outage and replica locations cannot be changed later.

Cost

Decentralised cost is metered and scattered: AWS Secrets Manager lists $0.40 per secret per month and $0.05 per 10,000 API calls, and Google bills user-managed replicas per selected location. A central platform swaps that for licence or hosting cost and, more significantly, a platform team to run upgrades, unseal procedures, replication and on-call. Below a few thousand secrets in one cloud, native stores are usually cheaper end to end; at multi-cloud scale, maintaining rotation code in every account tends to cost more than running a central platform. Count hidden costs too: customer managed KMS keys for cross-account access and the time spent building inventory across accounts.

Sprawl failure modes and the hybrid sync pattern

Centralised programmes leak sideways into "temporary" team stores; decentralised programmes duplicate the same key across accounts. The hybrid pattern addresses both if it follows four rules.

One system of record per secret. HashiCorp Vault secrets sync is designed this way: Vault "remains the system of records but can cache a subset of secrets on various external systems" (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, GitHub Actions, Vercel), and sync is one-way. External Secrets Operator does the reverse journey into Kubernetes: its controller "fetches secrets from an external API and creates Kubernetes secrets" and keeps them in sync.
One direction. Never edit a synced copy. Vault notes that changes made directly in a destination are not pushed back, so a manual edit is overwritten or, worse, survives until the next sync and confuses an incident.
Scoped sync identities. Give each sync job write access only to its destination, and prefer namespaced SecretStore objects over a cluster-wide ClusterSecretStore where teams share a cluster. See the External Secrets Operator security guide.
Drift and orphan checks. Compare every destination against the record on a schedule; a copy with no record entry is an orphan to delete, and a copy older than the record's last rotation is drift.

Availability: HashiCorp Vault namespaces, replication and secrets sync require a Vault Enterprise licence or an HCP Vault Dedicated cluster, per HashiCorp's documentation. AWS Secrets Manager, Azure Key Vault and Google Secret Manager are billed per use as stated on each provider's pricing pages. External Secrets Operator is an open-source project. Hardening per product: AWS Secrets Manager, Azure Key Vault Security Guide, Google Secret Manager Security Guide and HashiCorp Vault Guide.

Choosing: decision guidance

Your situation	Lean towards	Why
Single cloud, mostly that provider's own services, under a few thousand secrets	Decentralised cloud-native, centrally governed	Native identity and rotation; no platform to run; govern with tagging policy and an aggregated inventory
Two or more clouds plus on-premises	Centralised or hybrid	OWASP notes multi-cloud brings disparate APIs, access models, rotation and logging, and suggests a cloud-agnostic solution
Heavy use of dynamic database or PKI credentials	Centralised	One engine set, one policy model, consistent leases
Strict tenant or data residency isolation (multitenant SaaS, regulated regions)	Decentralised per tenant or region, or centralised with a cluster per zone	Hard boundaries beat logical ones when a regulator or customer asks
Small team, no platform engineering capacity	Decentralised cloud-native	A self-run central vault that nobody patches is worse than managed stores
Kubernetes-heavy estate	Hybrid with an operator or CSI driver	Central record, cluster delivery; see Kubernetes Secrets vs External Secret Stores

Large organisations usually land on hybrid: a central platform for cross-cloud, SaaS and dynamic credentials, native stores for provider-specific secrets, one inventory and policy over both. Small organisations usually do best with native stores under central rules for tagging, ownership and reporting.

Worked scenario: three clouds, forty teams

An illustrative retailer runs AWS for e-commerce, Azure for corporate apps and Google Cloud for analytics, with forty product teams and about 9,000 secrets. An audit finds 31 AWS accounts with Secrets Manager in use, 140 Key Vaults, Kubernetes Secrets in twelve clusters, and the same payment provider API key in five places.

Decide the record: provider-specific secrets (RDS credentials, storage keys) stay in each cloud's store; SaaS keys, shared database credentials and PKI move to one central platform as system of record.
Federate access: workloads reach native stores with their cloud identity; CI pipelines and clusters reach the central platform with OIDC tokens bound to repository and namespace claims.
Deliver locally: the central platform syncs one way into the cloud stores that applications already read, and External Secrets Operator delivers into clusters with a namespaced store per team.
Aggregate inventory: a nightly job lists every native store and the central record, joins owners and last-rotated dates, and flags duplicates by fingerprint.
Result: the payment key has one record, one owner and one rotation, with copies refreshed by sync.

How to implement: phased approach

Inventory first: enumerate every store in every account, subscription, project and cluster, plus scanner findings outside stores. Do not choose a model before you know what exists.
Write the standard: approved store types, the system of record per secret class, tagging and owner metadata, maximum age per class, and the rule that synced copies are never edited.
Federate before you migrate: set up workload identity to the target store so migrated secrets are never accessed with a static bootstrap token.
Pilot one team per pattern: cloud-native, central platform and Kubernetes; run drift checks in report-only mode before cutting reads over.
Migrate by rotation, not copy: issue a new credential in the target store, move consumers, then revoke the old one.
Rollback: keep the old store read-only (not deleted) until the new path has run a full rotation cycle; Azure soft delete and purge protection, and AWS replica promotion, give recovery options during the switch.

Detection and measurement

Log: every read, policy change, auth configuration change and admin login on the central platform; CloudTrail, Azure diagnostic logs and Cloud Audit Logs for native stores; sync job writes and failures. OWASP requires audit that resists tampering and has correct timestamps.
Alert: reads from a new identity or network, bulk reads across many secrets, cross-account resource policy changes, new stores outside approved accounts, and sync drift.

Metric	Target direction	What it shows
Share of secrets with a named owner and system of record	Towards 100%	Inventory is real, not aspirational
Rotation coverage per store type	Rising, and equal across stores	Whether one model is leaving secrets behind
Number of identities able to change policy on each store	Falling	Administrative blast radius
Duplicate secret values across stores	Falling to zero outside sync	Sprawl
Sync drift and lag incidents per month	Near zero	Hybrid health
Stores created outside the standard per month	Falling	Whether the central offer is fast enough to stop shadow stores

Programme-level checks are in the Secrets Management Health Check.

Common failure patterns

Centralising storage without centralising policy: a vault with one admin group and wildcard read policies concentrates risk without reducing it.
Two-way edits in a hybrid: someone fixes a synced copy by hand during an outage; the record and the copy now disagree.
Orphaned native stores: accounts from finished projects keep valid secrets with readers nobody reviews.
Cross-account grants without review: resource and KMS key policies opened for a migration and never closed.
Central platform too slow to onboard: teams route around it, and the decentralised sprawl the programme was meant to stop returns in a different form. The Top 10 Secrets Management Mistakes covers the wider list.

Framework mapping

Framework	Reference	Relevance to the model choice
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; IA-5(7) No Embedded Unencrypted Static Authenticators	Lifecycle and rotation of secrets in whichever store holds them
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; SC-12 Cryptographic Key Establishment and Management; SC-28 Protection of Information at Rest	Store access boundaries, KMS keys behind stores, encryption at rest
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory; AU-2 Event Logging; CP-7 Alternate Processing Site	Inventory of stores, audit of reads, availability of the service
NIST CSF 2.0	PR.AA-01, PR.AA-05, PR.DS-01, ID.AM-08, DE.CM-03	Credential management, access policy, data at rest, lifecycle, monitoring
ISO/IEC 27001:2022 Annex A	A.5.17 Authentication information; A.8.24 Use of cryptography	Allocation and management of secrets; key management
MITRE ATT&CK	T1555.006 Cloud Secrets Management Stores; T1552.001 Credentials In Files; T1078.004 Cloud Accounts	Techniques each model must detect

Practitioner checklist

Inventory every secrets store across accounts, subscriptions, projects and clusters before choosing a model.
Name one system of record for each class of secret and write it into the standard.
Separate tenants and environments with namespaces, accounts or vaults, and confirm no policy reads across them.
Reach every store with federated workload identity, binding roles to the narrowest claims.
Count and reduce the identities that can change store policy or auth configuration.
Sync one way only, scope each sync identity to its destination and alert on drift.
Measure rotation coverage per store type and close the gap where one model lags.
Test failover, including promotion and reauthentication.
Delete orphaned stores and alert on unapproved new ones.

Centralised vs Decentralised Secrets Management: Blast Radius, Rotation and Sprawl Compared