Where Key Vault belongs and where it does not.

Secrets often get treated like infrastructure.

They are stored with infra. Managed by infra. Reviewed with infra.

That is usually a mistake.

Why Secrets Feel Like Infrastructure

Secrets feel permanent. They feel critical. They feel risky.

So they end up bundled with infrastructure decisions.

But secrets change more often than infrastructure. They also belong closer to applications.

Infrastructure teams often manage Key Vault because it lives in Azure alongside virtual networks, storage accounts, and databases. It gets deployed with Terraform or Bicep. It has firewall rules and access policies. It looks and feels like infrastructure.

This creates a problem. When application teams need to rotate an API key or update a connection string, they have to coordinate with the infrastructure team. The infrastructure team does not know when secrets need to change. The application team does not have direct access to update them.

So secrets get stale. Or they get updated through manual processes that bypass automation and review. Or they stay in sync for production but drift in lower environments because no one wants to bother the infrastructure team for a non-production secret change.

Configuration Lives With Behavior

Secrets influence behavior.

Connection strings. API keys. Credentials.

These are runtime concerns.

They should move and evolve with the application, not with the network.

Think about what a secret actually does. It tells the application where to connect and how to authenticate. It determines which database the app talks to. It controls which third-party API gets called.

These decisions are application-level concerns. They change when the application changes. A new feature might require a new API integration, which means a new API key. A database migration might require a new connection string. A security incident might require rotating all credentials.

Infrastructure rarely changes at this pace. You do not rebuild your virtual network every sprint. You do not move subnets when a new feature ships. But you might rotate secrets or add new ones frequently.

Treating secrets like infrastructure creates friction. Treating them like configuration, owned and managed by the teams who build the applications, keeps them aligned with the code that uses them.

Key Vault Is a Boundary, Not a Brain

Key Vault should store secrets. It should not define architecture.

If your platform logic depends on secret layout, naming, or structure, something is off.

The application should know what it needs. The vault should only protect it.

I have seen systems where the application logic parses secret names to infer environment or resource mappings. The secret name encodes whether it is for production or development. The application reads multiple secrets and stitches them together based on naming conventions.

This is fragile. If the naming convention changes, the application breaks. If someone creates a secret with the wrong name format, the application silently fails or behaves incorrectly.

Key Vault should be dumb storage. The application should explicitly request the secrets it needs by name. The vault returns them or denies access. No interpretation. No clever logic.

This keeps the boundary clean. Infrastructure teams can manage the vault itself, the access policies, the firewall rules. Application teams manage the secrets inside, knowing exactly what they need and when to rotate them.

Separation Improves Ownership

When secrets are treated as configuration:

  • application teams own them
  • rotation becomes normal
  • environments stay aligned
  • infra stays simpler

Clear ownership reduces mistakes.

Application teams know when their API keys expire. They know when a third-party service changes authentication methods. They know when a connection string needs to be updated because of a database migration.

Infrastructure teams do not have this context. If they own the secrets, they depend on application teams to tell them when changes are needed. This creates coordination overhead and delays.

When application teams own the secrets, rotation becomes part of the deployment pipeline. Secrets get updated alongside code changes. New secrets get created when new features ship. Old secrets get removed when integrations are retired.

This also helps with environment consistency. Development, staging, and production environments each have their own secrets, managed by the same process. No special cases. No manual steps that only happen in production.

Infrastructure stays simpler because it does not need to understand application-level concerns. It provides the vault. It ensures access policies are correct. It monitors for security issues. But it does not need to know what each secret is for or when it should change.

Final Thought

Secrets are not infrastructure. They are sensitive configuration.

Putting them in Key Vault protects them. Treating them like infra confuses responsibility.

Knowing the difference matters more than tooling.

Related reading: