Why I Stopped Relying on RBAC and You Should Too

The Role That Wasn't

A few years ago, I walked into a client's office and saw a 'developer' role that had production access to every database. Why? Because six months earlier, one dev needed to run a report. No one removed it. That's not access control—it's a time bomb. We cling to RBAC because it's familiar, but it quietly turns into a mess. Roles become blunt tools, and the more you rely on them, the more you're gambling with your security.

Context Is the Missing Ingredient

Here's the thing: access shouldn't just depend on who you are. It should depend on what you're doing, when, and from where. ABAC lets you write policies like: 'Allow if the user is in Finance, the resource is the Q3 budget spreadsheet, and it's 9 to 5 on a business day.' That's not a role; that's a rule that reflects reality.

Think of a hospital. A nurse needs to see patient records, but only for patients on their ward, and only during their shift. RBAC would either give them too much access or force you to create a role for every ward and shift. ABAC handles it naturally—subject, object, environment. It's not theory; it's how modern systems should work. But many of us are still building new systems with RBAC alone, and that's a missed opportunity.

Yes, ABAC Is More Work—But Worth It

I get the pushback: 'ABAC is too complex.' True, if you try to model everything at once. But start with one resource, like production database access. Define a handful of attributes: department, project, clearance, time, location. You'll find it's manageable, and the security payoff is huge. With RBAC, you're stuck with role explosion and the constant fear that someone has too much access. Complexity is a trade-off, and in my experience, it's the right one.

Here's a concrete number: We once cut our 'over-privileged' incidents by 80% just by applying ABAC to our admin accounts. That's not a fluke; it's the result of controlling access based on context, not static roles.

Comparing the Models

This isn't just a textbook table. It's a decision tool. If your access needs change or depend on context, ABAC wins. If you have a static workforce with fixed duties, RBAC might work—until it doesn't. And it always does.

Making the Switch (Without Losing Sleep)

• Pilot ABAC on one high-risk resource, like admin access.
• Define a minimal set of attributes: department, project, clearance, time, location.
• Use RBAC as a baseline for everyday permissions, but always ask: 'Should this be attribute-based?'

Quick tip: Don't try to model every possible attribute upfront. Start with the top 10 that matter for security, and iterate.

What I'd Do Differently

If I were starting a new project today, I'd default to ABAC for any resource with sensitive data. I'd use RBAC only for coarse assignments like 'employee' or 'contractor,' then layer ABAC on top for fine-grained decisions. I'd also integrate with an identity provider that supports OIDC or SAML, because you need reliable attributes—OIDC gives you a signed token with proof of authentication, perfect for carrying those attributes. And please, apply least privilege and separation of duties. Don't let anyone hold the keys to the kingdom without a policy that says they need them.

So stop treating RBAC as the answer. It's a tool, not a strategy. ABAC is the strategy for the real world. Let's stop playing roulette and start making deliberate, context-aware decisions.

Sources

• Cisco Duo - https://duo.com/learn/access-control-models
• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• NIST SP 800-53 - https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• OpenID Connect - https://openid.net/connect/