Soft delete saved us once. Purge protection blocked us twice. Here is what we learned about Key Vault deletion safeguards. Soft Delete Is Enabled by Default Now Soft delete used to be optional. Now it is mandatory for all new Key Vaults. When you delete a vault, it is not really deleted. It is soft-deleted. It stays in a deleted state for 90 days by default. You can recover it during that time. ...
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: ...
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. ...
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: ...