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. ...
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. ...