So Long RBAC, and Thanks for All the Roles

RBAC—Role-Based Access Control—has been the bread and butter of access control since basically forever. For so many of us, labeling people and systems with roles feels like the most natural and straightforward way to manage security and organize who can access what. It’s certainly simpler than juggling individual permissions, and a very intuitive way to communicate access to everyone involved.

You can literally say, “Admins can do this, Editors can do that, and Viewers can only see content.” That clarity made RBAC the go-to solution for most applications and organizations.

But times are changing. Applications are getting more complex, having more data, more users, and, above all else, more features.

The requirements and expectations from applications have changed completely - access control now needs to consider requirements such as location awareness, time-based rules, quotas, and nested resources.

All of these factors are pushing RBAC to its limits, and in many cases, RBAC just doesn’t cover our requirements anymore. It falls flat, leaving us looking for a more flexible solution - beyond RBAC.

In this article, I’d like to talk about why RBAC has been so valuable, where it falls short, and how those gaps are leading us toward new, more advanced approaches to access control.

Times Are Changing

Let’s talk about this newfound application complexity. In short, what used to be simple, single-user systems are now inherently “multiplayer.” Multiple people are now expected to collaborate, share information, and interact with each other’s data in basically everything we use - from Netflix and Spotify to CMS systems and CRMs.

A simple “Access Request” chart depicting the process implemented through Permit.io’s Access Request embeddable element.

That change alone demands more nuanced access rules than basic role labels could ever offer.

On top of that, we often have to consider details like whether a user is accessing from a specific location or at a specific time, if they’re subject to certain quotas, or if they’re part of complex nested hierarchies of resources. All these factors create scenarios that plain RBAC is just unable to handle.

A simple access control mechanism, as implemented in Notion

If that wasn’t enough, AI-driven apps push complexity even further. AI agents often need permissions on behalf of users and consume services in ways we can’t always predict. Suddenly, the static, role-based assignments we once relied on feel way too rigid.

These shifts are bringing traditional RBAC to the breaking point.

RBAC Still Has Value

So what does this mean? Should we kiss RBAC goodbye—literally, as the title says, “So Long RBAC”? Well, not quite. RBAC is still one of the greatest tools that we have, at least as a way of thinking.

Even though applications are changing and pushing beyond what basic roles can do, people naturally gravitate toward categories and labels—it’s just the way we think.

Organizing permissions around roles like “Admin,” “Editor,” and “Viewer” is still a great mental model for describing who can do what.

RBAC’s straightforward approach makes explaining policy decisions very simple:

“Admins can see and change everything, Editors can publish content, and Viewers can only read.”

There’s no easier way to author policies, convey access rules to your team, or audit them later. That clarity is the main reason RBAC remains a staple in many products.

Even if we eventually adopt more advanced approaches, RBAC continues to serve as an excellent starting point. It’s a common language for talking about authorization, and it gives teams a clear, shared foundation before delving into context-driven or attribute-based models.

But what are those new solutions I keep talking about?

Looking Beyond RBAC: Fine-Grained Authorization

While RBAC got us far, there are several new solutions we have to be aware of in the sphere of access control. I’m talking about concepts like Fine-Grained Authorization (FGA), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC).

Both ABAC and ReBAC let you factor in far more than a single role label, adapting to the dynamic context in which users (or even AI agents) operate.

• ABAC uses attributes—like a person’s location, time of day, or account status—to decide whether an action is allowed. Think of it as checking things like a user’s location (user.location == "US") or subscription status (user.isPaying == true) before allowing or denying an action.
• ReBAC shifts the spotlight onto relationships. It’s often visualized as a graph where edges define who can access which resources, which is perfect for handling nested objects or shared folders.

You’ll often see these combined in real-world systems. For instance, you can start with a basic role—Editor—and then refine it using attributes or relationships, effectively mixing RBAC with ABAC or ReBAC.

Blending RBAC With FGA

As you’ve probably realized in the previous section, all these new models don’t mean we have to abandon roles entirely. Roles provide a clean, human-friendly way to categorize permissions—something there’s no reason to give up on. Instead, we can enhance RBAC by adding the context-aware capabilities of ABAC or ReBAC.

This lets you capture the richer context that many modern applications need without losing the human-friendly labels that made RBAC so valuable in the first place.

FGA ties everything together by giving you the flexibility to pull in roles, attributes, and relationships all at once, and all under one cohesive authorization framework.

Let’s look at an example:

A simple role like “Editor” can be lacking on its own, but when enhanced with FGA, it can be used to create much more nuanced policies, such as:

• “An Editor can only publish GDPR approved content if they are located in the EU” (Using attributes).
• “If someone is the editor of a folder, they can also edit any files in that folder” (Using relationships).

This combination preserves the simplicity of RBAC—people still know who’s an Editor or Viewer—while also letting you respond to real-world nuances. Whether it’s time-bound access, hierarchical structures, or unique rules for AI agents, FGA (through ABAC or ReBAC) picks up where RBAC alone leaves off.

Bye RBAC, See You Soon

At this point, it’s pretty clear to see that we’re not really saying goodbye to RBAC.

RBAC continues to be a powerful conceptual tool and a great place to start when talking about permissions —it’s straightforward, easy to explain, and provides a solid baseline for any access control strategy. The real key is to design your system so that it can quickly evolve beyond simple role assignments whenever you need extra flexibility.

By keeping RBAC as a starting point, you allow stakeholders—both technical and non-technical—to have a clear mental model of user permissions. Then, as your application grows or new requirements appear, you can incrementally add attributes or relationships into the mix.

When combined with FGA, you keep the role-based clarity that everyone understands, while seamlessly taking on complex scenarios like time-based rules, location checks, or multi-level hierarchies.

This also means you don’t have to implement every nuance on day one - start simple with familiar role structures, then gradually weave in attributes and relationships as needed.

The Future of RBAC

RBAC still has plenty of life left as a conceptual backbone for access control. Its human-friendly simplicity keeps it invaluable for introducing new team members to permissions, for drafting initial policies, and for providing a shared language across technical and non-technical stakeholders.

But as the world of software continues to evolve—particularly with AI—we need more flexible, context-aware frameworks to handle complex requirements. That’s where we need FGA, extending RBAC with richer possibilities like attributes (ABAC) and relationships (ReBAC).

RBAC isn’t going anywhere - it’s a great place to start. When your product grows or new needs appear, weave in those extra layers. By embracing the best of both worlds, you’ll retain the clarity of roles while gaining the fine-grained control today’s applications demand.