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: ...
Boundaries matter more with AI than with humans. Trust is contextual. We trust engineers with secrets because they are accountable. We do not trust AI with secrets because it is not. That distinction matters more than people admit. AI Has No Sense of Boundary AI does not understand intent. It does not understand sensitivity. It does not understand consequences. It only understands inputs and outputs. If a secret appears in a prompt, the model treats it as data, not as something to protect. ...
The role assignment is correct. The scope is right. Access is still denied. Here are the hidden reasons why. Propagation Delay Is Real You add a role assignment. You test immediately. It fails. Azure RBAC changes are not instant. Propagation can take up to 30 minutes, though it is usually faster. We spent hours debugging issues that fixed themselves while we investigated. Now we wait five minutes before testing any new role assignment. ...
Role assignments multiply faster than you expect. Here is how we went from structured permissions to chaos, and how we fixed it. It Starts With One Exception You build a clean RBAC model. Groups for teams. Roles at the right scope. Least privilege enforced. Then someone needs access for a demo. Just this once. You add a direct role assignment to their account. You plan to remove it later. You forget. ...
Service principals never clean themselves up. And no one remembers why they exist. Here is how we ended up with hundreds of them. They Start With Good Intentions Someone needs to deploy an app. They create a service principal. Someone needs a CI/CD pipeline. Another service principal. Someone needs cross-tenant access. One more. Each one made sense at the time. Each one solved a real problem. None of them had an expiration date. ...
Why permission models rot over time. Azure RBAC feels simple at first. Assign a role. Pick a scope. Move on. The problems show up later. RBAC Accumulates History Permissions tend to grow, not shrink. Temporary access becomes permanent. Emergency grants never get revisited. Roles pile up across scopes. Over time, no one remembers why access exists. They only remember that removing it feels risky. I have audited Azure subscriptions where people had role assignments from three jobs ago. Former contractors still had Contributor access years after their contracts ended. Service principals created for one-off migrations still had Owner access to production. ...
Practical IAM, not zero trust theater. Access control often swings between two extremes. Everything open. Everything locked down. Neither works. Why Overly Restrictive IAM Fails When access is too hard to get: engineers work around it secrets get shared permissions creep quietly reviews become rubber stamps Security that blocks work does not create safety. It creates shadow systems. I have seen this pattern repeat across multiple teams. Access requests take days or weeks to get approved. The approval process requires three levels of sign-off, none of which understand the technical need. Engineers get frustrated and find workarounds. ...
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: ...
The quiet upgrade most teams underestimate. When we first adopted Managed Identity, it felt incremental. No big architecture change. No dramatic security announcement. Just fewer secrets. What surprised us was not what it replaced. It was what it quietly removed. The Problems We Thought We Had Before Managed Identity, most of our security conversations focused on symptoms. rotating credentials expiring secrets leaked connection strings confusing access reviews We assumed these were the core problems. ...