How secrets sprawl happens and how to stop it.

Key Vault feels deceptively simple.

If something is sensitive, put it in the vault. Problem solved.

That logic is how secret sprawl starts.

How the Vault Becomes a Junk Drawer

It usually begins with good intentions.

A new service needs a secret. A developer adds it to Key Vault. Permissions are granted. Everyone moves on.

Repeat this enough times and suddenly:

  • unrelated secrets live together
  • naming conventions drift
  • ownership is unclear
  • access policies grow organically
  • no one knows what is still in use

The vault becomes a dumping ground.

I have seen vaults with hundreds of secrets. Some were API keys for services that no longer exist. Others were connection strings for databases that got decommissioned years ago. A few were labeled things like “temp-key-2” or “backup-secret-do-not-delete” with no indication of what they were for.

The problem is not that these secrets exist. The problem is that no one knows whether deleting them will break something. So they stay. Forever.

This creates real security risk. Every secret in the vault is a potential attack surface. If an identity can read that secret, and that secret is powerful, you have exposure. Even if the secret is not actively used.

Secrets Without Context Are Risky

A secret without context is dangerous.

You need to know:

  • who owns it
  • what depends on it
  • how often it rotates
  • what happens if it changes
  • whether it can be deleted

Key Vault does not enforce any of this. You have to.

Why Sprawl Happens

Secret sprawl is rarely negligence. It is usually missing structure.

Common causes:

  • shared vaults across teams
  • inconsistent naming
  • no lifecycle ownership
  • treating secrets as infra artifacts
  • never deleting old values

Without boundaries, convenience wins.

Shared vaults seem efficient. One vault for the whole team. Everyone has access. No friction.

But shared vaults erode ownership. When everyone can add secrets, no one feels responsible for cleaning them up. When access is granted broadly, no one questions whether a specific identity actually needs access to every secret in the vault.

Naming conventions help, but only if they are enforced. I have seen vaults where half the secrets follow app-env-resource-purpose format and the other half follow purpose-app-env or just descriptive-name-123. Consistency breaks down over time unless it is automated or reviewed.

Lifecycle ownership is the hardest part. Secrets get created when services get deployed. But when services get retired, the secrets often stay behind. There is no built-in mechanism in Azure to tie a secret’s lifecycle to the resource that uses it.

What Worked for Us

We stopped treating Key Vault as a shared utility and started treating it as scoped configuration.

That meant:

  • clear ownership per vault
  • secrets grouped by application or domain
  • naming that encoded purpose
  • access tied to identity, not convenience
  • regular cleanup as a normal task

The vault got smaller. Security got better.

We moved from one shared vault per environment to one vault per application per environment. Each vault is managed by the team that owns the application. Access policies are scoped to the specific identities that need them, usually Managed Identities for the services themselves.

Naming became enforced through Terraform variables and validation rules. If a secret does not match the expected pattern, the deployment fails. This sounds strict, but it prevents the drift that makes vaults unmanageable.

Cleanup became part of the deployment process. When we decommission a service, we delete its secrets as part of the teardown. We also run quarterly reviews where we list all secrets, check their last access time, and challenge anything that has not been used in 90 days.

These changes did not happen overnight. We migrated gradually, one application at a time. But the result was worth it. Our vaults went from dozens or hundreds of secrets to fewer than ten per vault. Access policies became understandable. Security reviews became faster.

Less Is More

A healthy Key Vault feels boring.

Few secrets. Clear names. Predictable access. Easy answers.

If your vault feels busy, that is a signal.

Final Thought

Key Vault is a powerful tool. It is not a strategy.

Without structure, it becomes a liability disguised as security.

Related reading: