RBAC versus ABAC comparisons fill entire pages of search results. Almost all of them stop right at the interesting part: production.
TL;DR: I built an ABAC system for application-level permissions on a platform with more than 25 million users. In production, the policies are not what breaks. Stale attributes, rule explosion, missing enforcement points and silent decisions are. Four failure modes, and the rules that contain them.
This article is for teams outgrowing simple roles and preparing the jump to fine-grained authorization.
The setup
Two definitions first. RBAC grants rights through roles: admin, editor, viewer. ABAC decides through attributes: who is asking, on which resource, in which context.
On the healthcare platform I work on, application permissions depend on the user, the application and the site. More than 25 million users, more than 1,000 sites.
With roles alone, that kind of matrix ends in explosion. One role per combination, hundreds of roles, nobody knows who can do what anymore. That is the classic road to ABAC.
But ABAC does not remove complexity. It moves it: from roles to attributes and policies. And that is where production waits for you.
The RBAC versus ABAC debate is over
The model war ended a while ago. In practice everyone lands on hybrid: RBAC for the baseline, ABAC for the fine grain.
The tooling matured too. OpenFGA became a CNCF incubating project in late 2025. SpiceDB powers the permissions behind ChatGPT Enterprise connectors, through AuthZed. Google's Zanzibar model has many children now.
So picking a model is no longer the real problem. The real problem is what breaks afterwards. And almost nobody writes that part.
Failure mode 1: stale attributes
An ABAC decision is only as fresh as its oldest attribute.
Attributes come from elsewhere. A directory, a site registry, a contract. They synchronize, therefore they go stale.
The trap is silent. A perfect policy, evaluated on wrong attributes, returns wrong decisions with perfect confidence.
My rules. Every attribute has a designated source of truth. Every attribute has a maximum accepted age. And a missing attribute closes access, never the opposite.
Fail closed, always. Fail closed means: when in doubt or during an outage, deny.
Failure mode 2: rule explosion
Second failure mode: policies pile up.
Every edge case becomes a rule. Nobody dares delete a rule they no longer understand. Two rules end up contradicting each other, and evaluation order becomes superstition.
My rules. Every policy has a named owner. Policies get reviewed on a fixed schedule, and a policy without a living owner gets deleted.
Above all: decision tests. Golden cases replayed on every change: this user, this resource, this context, this expected verdict. A policy without regression tests is a roulette wheel.
Failure mode 3: missing enforcement points
The most dangerous failure mode is not a bad policy. It is a code path that never asks the question.
A new endpoint. A batch job. An export. An admin tool. Each one can read data without asking for permission.
A policy without an enforcement point is an opinion.
My rules. One decision gate, a library or a service, and every path goes through it. A second barrier in the database for the most sensitive data.
And tests that attack paths, not policies. Call the endpoint without the right. Expect a denial. Every route must know how to say no.
Failure mode 4: silent decisions
Last mode: silence. An access denial with no trace creates two problems.
Support cannot answer "why don't I have access?". And audit cannot answer "who accessed what". On a healthcare platform, the second question is not optional.
My rules. Log every decision, granted or denied, with the attributes that were evaluated. Watch the journal's content: identifiers and categories, no plaintext personal data.
And a replay tool for support. Same question, same attributes, the decision explained. "Why" should take a minute, not a day of archaeology.
The checklist before you adopt ABAC
The four failure modes do not depend on the tool you pick. Neither does this checklist.
- [ ] Stay hybrid: RBAC for the baseline, ABAC where fine grain pays
- [ ] Give every attribute a source of truth, a max age, and fail closed
- [ ] Name an owner per policy, delete orphaned policies
- [ ] Write golden decision cases, replayed on every change
- [ ] One decision gate, and every path goes through it
- [ ] Test the paths without the right: every endpoint must know how to deny
- [ ] Log every decision with its attributes, no plaintext PII
- [ ] Tool the "why": support must be able to replay a decision
What to remember
ABAC keeps its promise: fine-grained rights that follow the business. But its reliability does not live in the policies. It lives in the attributes, the enforcement points and the logs.
Starting from scratch today, look at OpenFGA or SpiceDB before writing your own. The four failure modes will follow you whatever the tool.
An authorization system to design or to harden? Let's talk.
Sources: NIST SP 800-162, ABAC guide · CNCF, OpenFGA becomes an incubating project (November 2025) · AuthZed, OpenAI customer story (SpiceDB) · Google, the Zanzibar paper
