Attribute Based Access Control (ABAC)

ABAC is worth the effort.

When access follows attributes instead of hand built roles, you stop creating a new role every time a team, region, or project shows up. When someone changes departments, their access changes as soon as the attribute does, not at the next review cycle. Reviews shift from thousands of individual assignments to a smaller set of policies and the attribute data behind them. Microsoft walks through a scenario where a single conditional role assignment replaces a design that would have needed 256,000.

But the payoff only shows up if the deployment is done well. I spent some time going through what IAM practitioners are saying about ABAC and what I've seen myself. Here's what keeps breaking and what fixes it.

1. Nobody owns the attribute.
Fix: Assign an owner to each attribute the same way you assign an owner to an application. Each attribute also needs one authoritative source and a check that it's still current. New attributes go through change control and get tested before any production policy uses them.

2. Whoever can write a tag can grant access.
Fix: Treat attribute write access as privileged. In AWS, SCPs can block untagged resources and restrict who changes authorization tags. Also lock down who can tag roles or edit the directory attributes behind session tags. Where you use ABAC in Azure Blob Storage, the tags it evaluates live on the data plane. Control who can write blob index tags, retire Shared Key on those accounts first, and keep both attribute administrator roles in PIM.

3. Trying to go pure ABAC.
Fix: Keep RBAC as the baseline for broad access. Add attributes where roles start multiplying.

4. Exceptions that never go away.
Fix: Every override gets an expiration date and shows up in access reviews.

What's worked for you or has been a real challenge?