Should I use one Azure Key Vault per application or one per environment?

The common recommendation is a vault per application per environment — so 'app-A prod', 'app-A dev', 'app-B prod' each get their own vault. This gives the tightest blast radius and the cleanest access boundary: a compromised app or an over-broad role only ever reaches its own secrets. A single shared vault per environment is simpler to manage but widens the blast radius and pushes all isolation onto RBAC and access policies. Favour per-application vaults unless the management overhead genuinely outweighs the isolation benefit.

Can teams share a Key Vault without seeing each other's secrets?

Partly. With the vault in RBAC authorization mode you grant roles like Key Vault Secrets User scoped to the vault, so anyone with access to a shared vault can read the secrets in it — Key Vault RBAC is scoped at the vault, not the individual secret. To truly keep teams out of each other's secrets you separate them into different vaults. So a shared per-environment vault can isolate people from the vault as a whole, but not from individual secrets within it, which is a key reason to prefer a vault per application.

Does Azure Key Vault have request throttling limits?

Yes. Key Vault enforces a per-vault transaction limit, and requests beyond it are throttled with HTTP 429. If many applications share one vault, their combined traffic can hit that ceiling and throttle everyone at once. Splitting into per-application vaults spreads the load across separate limits. Whatever the design, applications should cache secrets and back off on 429 rather than reading from the vault on every call.

How should a platform team manage Key Vaults for many applications?

A good pattern is a vault per application per environment, provisioned by the platform team through infrastructure as code with consistent naming, RBAC authorization mode, diagnostic logging and network restrictions baked in. Grant each application's managed identity access to only its own vault, let application teams manage their own secrets within their vault, and keep them out of others by the vault boundary itself. This scales better and isolates blast radius far better than one shared vault everyone can reach.

Field notes · Governance

Key Vault: per-app vs per-environment

Azure Key Vault: one per application or one per environment?

By Captain O7 min read

A platform team's tempting shortcut is one big shared vault per environment — easy to run, one thing to manage. It's also the design that puts every team's secrets one over-broad role assignment apart. Here's the real trade-off.

New to cloud? CAMPUX is a free, build-first course. Start here →

Favour one Key Vault per application per environment: app-A-prod, app-A-dev, app-B-prod each get their own vault. It gives the tightest blast radius and the cleanest access boundary — a compromised app or an over-broad role only reaches its own secrets. A single shared per-environment vault is simpler to run but widens the blast radius and can't isolate individual secrets, because Key Vault access is scoped at the vault, not the secret. The convenience of one vault is real; so is the reason not to use it.

This question lands on every platform team eventually: the app teams don't know Azure well, you want to make secrets easy for them, and one shared vault per environment looks like the kind way to do it. The catch is that a vault is a security boundary, and merging boundaries to save management effort is exactly the trade that reads fine until an incident.

The core constraint: access is per-vault, not per-secret

Here's the fact that decides most of this. When a Key Vault is in RBAC authorization mode (the modern default), you grant roles like Key Vault Secrets User scoped to the vault. There's no clean per-secret role — anyone who can read secrets in a vault can read all the secrets in it. So a shared vault can keep people out of the vault entirely, but it can't keep team A out of team B's individual secrets sitting in the same vault. The only reliable wall between two teams' secrets is two vaults.

Per-app vs per-environment, side by side

	Vault per application	Shared vault per environment
Blast radius	Small — one app's secrets	Large — every app in the environment
Secret isolation between teams	Yes (vault boundary)	No (all readers see all secrets)
Throttling	Load spread across vaults	All apps share one 429 ceiling
Management overhead	Higher (more vaults)	Lower (one to run)
Best fit	Most cases, esp. multi-team	A single small app / tight team

The three arguments for per-application vaults

Blast radius — if an app or an identity is compromised, the damage stops at that app's secrets instead of every secret in the environment.
Real isolation — because access is per-vault, separate vaults are the only way to actually keep teams out of each other's secrets (see above).
Throttling headroom — Key Vault has a per-vault transaction limit and returns HTTP 429 past it. Many apps on one vault can throttle each other; separate vaults spread the load across separate limits.

The one argument for a shared vault

Management overhead. One vault is one thing to provision, monitor, and reason about; a hundred are a hundred. For a single small application, or one tight team that genuinely shares everything, a per-environment vault is a defensible, simpler choice. The mistake is reaching for it across many teams to save effort — that's trading a security boundary for a bit of convenience.

The overhead argument mostly dissolves with IaC

"Too many vaults to manage" is largely a symptom of managing them by hand. Provision a vault per app per environment from infrastructure as code — consistent naming, RBAC mode, diagnostic logging, and network rules baked into a module — and creating the hundredth vault costs the same as the first. The managed identity for each app gets access to only its own vault.

The recommended default

One vault per application per environment, provisioned by the platform team via IaC, each app's managed identity scoped to its own vault, app teams free to manage secrets inside their vault, and the vault boundary itself keeping them out of everyone else's. It scales, it isolates blast radius, and it sidesteps the shared-throttling problem — the small extra management cost buys a real security boundary. Reach for a shared per-environment vault only for a genuinely single-tenant, single-team case. This is the same guardrail thinking as the rest of the governance plane: scope tightly, and don't merge boundaries for convenience.

A vault is a wall. One shared vault is one wall around everyone; a vault per app is a wall around each. Walls are the point.

Questions people also ask

One Key Vault per application or per environment?

Usually per application per environment — tightest blast radius and the cleanest access boundary, since a compromised app or over-broad role only reaches its own secrets. A shared per-environment vault is simpler but widens blast radius and can't isolate individual secrets. Favour per-app unless overhead genuinely outweighs isolation.

Can teams share a vault without seeing each other's secrets?

Not cleanly — Key Vault RBAC is scoped to the vault, so anyone who can read secrets in it reads all of them. To keep teams apart, use separate vaults. A shared vault isolates people from the vault as a whole, not from individual secrets.

Does Key Vault throttle requests?

Yes — a per-vault transaction limit, with HTTP 429 past it. Many apps on one vault can throttle each other; per-app vaults spread load across separate limits. Apps should cache secrets and back off on 429 regardless.

How should a platform team manage many vaults?

A vault per app per environment, provisioned via IaC with consistent naming, RBAC mode, logging and network rules; each app's managed identity scoped to its own vault; app teams manage their own secrets. It scales and isolates far better than one shared vault.