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.

Sometimes the workaround is using a shared service principal with overly broad permissions. Sometimes it is SSHing through a bastion host that has access, instead of requesting proper access for their own identity. Sometimes it is just bothering a teammate who already has access to run commands on their behalf.

All of these workarounds create more risk than granting the access properly would have. But restrictive IAM feels safer on paper, so it persists.

Why Overly Permissive IAM Fails

When access is too loose:

  • blast radius grows
  • mistakes become outages
  • accountability disappears
  • audits become painful

Convenience without boundaries is just deferred risk.

The opposite extreme is granting everyone Contributor access to everything. No friction. No process. Engineers can move fast.

Until someone accidentally deletes a production resource. Or modifies a network security group and breaks connectivity. Or changes a configuration that cascades into an outage.

Overly permissive access also makes incident response harder. When everyone has access to everything, figuring out who changed what requires digging through activity logs. Accountability becomes a detective exercise instead of a design property.

And during audits, broad permissions are impossible to justify. “Why does this developer have Owner access to the production subscription?” There is rarely a good answer besides “we gave everyone access to avoid friction.”

The Middle Ground Is Boring and Effective

What worked best for us was not clever.

It was:

  • role based access
  • environment scoped permissions
  • time bounded elevation
  • clear defaults
  • documented expectations

Nothing flashy. Everything predictable.

Role based access means developers get Reader access to production and Contributor access to development environments by default. If they need elevated access to production, they request it through a documented process with a specific justification and time window.

Environment scoping helps contain mistakes. If someone experiments with a risky change in development, it does not affect production. If they need production access for troubleshooting, that access is temporary and logged.

Time bounded elevation, often through Azure PIM, ensures that elevated permissions expire automatically. This prevents the accumulation problem where someone gets Contributor access for a one-time task and still has it six months later.

Clear defaults make onboarding predictable. New engineers know what they can access from day one. They do not have to ask for basic permissions or wait for approvals to start contributing.

Documented expectations set the tone. We have a short guide that explains what access is granted by default, what requires approval, and how to request it. This transparency reduces friction and builds trust.

Access as a Workflow

We stopped treating access as a one time decision.

Access became a workflow:

  • request
  • justification
  • review
  • expiration
  • removal

When removal is expected, accumulation slows down.

The workflow is simple. An engineer opens a pull request or submits a ticket requesting access. They include why they need it and for how long. A peer or lead reviews the request. Access is granted for the specified time period.

When the time expires, access is revoked automatically. If they still need it, they request an extension with updated justification. This prevents permissions from accumulating indefinitely.

The key is making removal automatic and non-negotiable. If access expires and gets revoked, that is not a punishment or a failure. It is just how the system works. No one takes it personally. No one feels like they have to hoard permissions to avoid the friction of requesting them again later.

Engineers Want Predictability, Not Power

Most engineers do not want broad access. They want clarity.

They want to know:

  • what they can do
  • where they can do it
  • how to get more when needed

Predictable IAM builds trust. Trust reduces risk.

Final Thought

Good IAM does not feel like security theater.

It feels boring, fair, and consistent.

That is how you give engineers access without creating incidents.

Related reading: