Venn of Access Control Taxonomies: Why RBAC Isn’t Going Away, But Why We Need More
For decades, Role-Based Access Control (RBAC) has been the workhorse of enterprise identity systems. RBAC made it practical for IT teams to group users and grant them entitlements in bulk. If you’re in the HR group, you get access to the HR applications. If you’re a manager, you get manager entitlements. This approach simplified access governance and made audits easier.
RBAC isn’t going away. But it’s also true that RBAC is only a small piece of today’s much larger access control puzzle. And if enterprises think that buying a big identity governance tool means they’ve “solved” access control, the tool is more likely to disappoint then sail.
RBAC’s Enduring Value
RBAC remains extremely useful — especially for the workforce. Organizing employees into groups and assigning access rights accordingly makes day-to-day operations manageable. Without roles, every single entitlement would have to be managed individually, a nightmare for both administrators and auditors.
That’s why even the most modern enterprises still rely on groups. It’s efficient. It’s auditable. And it’s familiar. In short: RBAC isn’t dead, and it won’t be any time soon.
Why Enterprises Pay for Tools Like SailPoint
Here’s the interesting part: enterprises don’t pay millions for SailPoint or similar identity governance solutions simply for RBAC. They pay because they want a one-stop shop for access control. A system of record where compliance, attestation, reporting, and provisioning can be centrally managed.
But today projecting those hopes and dreams on a glorified RBAC tool is creating only the illusion of security. RBAC is only a subset of what enterprises actually need. Identity-based access control itself is only a subset of the total access control challenge.
That’s why, despite the glossy marketing, enterprises often find themselves stitching together multiple systems — identity governance, newer “NHI” tools, B2B tools, data-layer security controls — each solving a piece of the puzzle.
Capabilities: A Superset of Identity
Now look again at the graphic above. Notice how small RBAC appears compared to the broader category of Token-Based Access Control (TBAC), and how both are contained within the much larger circle of capabilities.
Capabilities are a more general and flexible way of thinking about access. A “capability” is simply an attestation of an action on a resource. Here’s an extreme example. Let’s say the resource is a car. Can you “drive the car” or “unlock the car”… those two distinct capabilities with distinct risks.
With a capabilities-based approach, you can still express RBAC policies (“this principal has a capability because they’re in the HR group”). But you can also express far richer rules: combining multiple tokens, layering conditions, delegating capabilities across systems. In fact, anything you can do with identity-based access control can be done with capabilities — plus much more.
Why TBAC Matters
Token-Based Access Control (TBAC) operationalizes capabilities. Instead of identity being the single lens for access, tokens become the carriers of evidence, which can be used by a person or software to authorize a capability. A token is input to policy. Want to prove you’re a manager? Present a token. Want to show you’ve completed security training? Present another token. Want to combine both to unlock a sensitive workflow? That’s TBAC.
TBAC makes it possible to enforce fine-grained, context-rich access control across diverse systems. It’s analyzable, composable, and scalable in ways that traditional identity-centric models are not.
The Illusion of Centralized Assurance
This brings us back to SailPoint and other governance tools. They provide value as a control plane for workforce entitlements. But they cannot deliver the kind of end-to-end, policy-driven assurance enterprises now need. At best, they provide an illusion of control — an outdated one at that.
Modern enterprises must think in terms of capabilities, not just identities. And that means new tools are required — tools built for TBAC and beyond. Tools that can reason across multiple tokens, multiple issuers, and multiple contexts. Tools that can actually deliver on the promise of least privilege at scale.
Conclusion: Moving to Capabilities
RBAC is not dead. It’s still useful. It will remain part of the enterprise toolbox for years to come. But let’s be honest: it’s no longer sufficient on its own.
Capabilities-based access control — operationalized through models like TBAC — represents the future. It covers every use case identity can handle, and many more. It provides the flexibility, composability, and analyzability that enterprises now require.
The real question is not whether RBAC will disappear — it won’t — but whether enterprises are ready to take the next step. Because the tools needed for capabilities-based access control are not going to look like your Grandpa’s SailPoint. They’ll be built for a new world of distributed, token-driven trust.
And the sooner we start building and adopting them, the better prepared we’ll be for the future of access control.
