We thought more vaults meant better security.
It just meant more complexity.
Here is what we should have done instead.
The Logic Seemed Sound
Each app gets its own Key Vault.
Perfect isolation. Clear ownership. No shared access.
It sounded like best practice.
We created:
- one vault per microservice
- one vault per environment
- one vault per team
Within six months, we had over 100 Key Vaults.
Management Became Impossible
Every vault needed:
- RBAC configuration
- network rules
- private endpoints
- monitoring
- backup and recovery plans
- compliance attestation
We spent more time managing vaults than using them.
Onboarding a new app meant:
- create a vault
- configure access policies
- set up private endpoint
- link to private DNS zone
- grant Managed Identity access
- configure logging
It took two hours. For a vault that stored three secrets.
Cost Added Up
Key Vault pricing is low per vault.
But 100 vaults add up:
- vault instance cost
- private endpoint cost (one per vault)
- data transfer cost
- operations cost
We were spending more on Key Vault infrastructure than on the secrets themselves.
Secrets Were Not As Isolated As We Thought
Different apps needed the same secrets.
Database connection strings. API keys. Service endpoints.
We ended up duplicating secrets across vaults.
Now we had:
- multiple copies of the same secret
- inconsistent rotation schedules
- unclear source of truth
When we rotated a secret in one vault, we had to remember to rotate it in five others.
We missed rotations. Outages happened.
RBAC Became Fragmented
Each vault had its own access policies.
We had to grant:
- Managed Identity access per vault
- developer access per vault
- operations access per vault
- security team access per vault
Auditing permissions required checking 100+ vaults.
We could not answer “who has access to production secrets” without running queries against every vault.
What We Should Have Done
We re-architected our vault strategy:
One vault per environment:
- dev-keyvault
- staging-keyvault
- prod-keyvault
All apps in that environment share the vault.
We used:
- naming conventions for secrets (appname-secretname)
- RBAC to control access (not access policies)
- Managed Identity for app access
- secret tags for ownership and metadata
We went from 100+ vaults to 6.
Management time dropped by 80%.
Isolation Through RBAC, Not Vaults
We use RBAC to enforce isolation:
- each app’s Managed Identity has “Get Secret” permission on only its secrets
- developers have access scoped to their app’s secrets
- security teams have read access to everything
- break-glass accounts have full access
The vault is shared. The permissions are isolated.
We get the same security posture with far less overhead.
Shared Secrets Are Explicit
We now have a “shared” namespace for secrets multiple apps need.
Example:
- shared-database-connection-string
- shared-api-gateway-url
Apps request access to shared secrets through a documented process.
We know which apps use which shared secrets.
Rotation happens once, and all apps get the updated value.
Monitoring Is Simpler
With six vaults instead of 100, we can:
- configure alerts once per environment
- review audit logs in one place
- track metrics without aggregation complexity
- respond to security events faster
We have better visibility with fewer resources.
When We Still Use Separate Vaults
We use separate vaults when:
- compliance requires physical isolation
- cross-tenant access is needed
- a third-party integration demands it
But that is rare.
Most of the time, one vault per environment works.
The Lesson
More resources do not mean better security.
They mean more surface area. More complexity. More things to manage.
Security comes from:
- correct RBAC
- least privilege
- good rotation practices
- monitoring and alerting
Not from multiplying infrastructure.
We learned that the hard way.
Now we default to fewer, well-managed resources instead of many poorly-managed ones.
That applies to more than just Key Vault.
It applies to everything.