RBAC vs ABAC: We Need Both, but Start with Roles

We've Been Told Access Control Is a Pick-One Game

Ask most engineers about authorization models and they'll tell you to choose between Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). That's a false dichotomy. In real production systems, we use both. The question isn't which one to adopt; it's which one to build on first. In my experience, the answer is almost always RBAC as the foundation, with ABAC layered on top for the edge cases. Let's prove that with some concrete criteria.

What You're Actually Choosing Between

RBAC assigns permissions to roles, and users inherit those permissions by being assigned roles. It's the workhorse of access control, standardized in ANSI INCITS 359 (NIST RBAC (INCITS 359)). ABAC, on the other hand, evaluates attributes of the subject, object, action, and environment to make decisions (NIST SP 800-162 (ABAC)). Think of RBAC as the skeleton and ABAC as the nervous system. The two are not mutually exclusive; in fact, most modern organizations use RBAC as a baseline and layer ABAC on top for context-aware decisions, adding MAC only for classified data (Cisco Duo).

Three Criteria That Actually Matter

When we're choosing an authorization strategy, three things dominate: operational simplicity, flexibility for complex policies, and security posture. Let's compare RBAC and ABAC on each.

Operational Simplicity

RBAC wins hands down. With RBAC, you define a handful of roles—'engineer', 'manager', 'auditor'—and assign permissions to those roles. New employees get the right role and they're done. Permissions are inherited, so you don't chase individual users. It's easy to reason about: an auditor role either can read logs or it can't. ABAC, by contrast, requires defining attribute schemas, writing policy rules, and maintaining a policy engine. That's a lot of moving parts. For a team of five, RBAC is a day's work; ABAC is a project.

Flexibility for Complex Policies

Here ABAC shines. RBAC struggles with fine-grained decisions based on context. For example, "allow read access to financial reports only during business hours and only from a compliant device" is nearly impossible to express with roles alone. ABAC evaluates attributes like time, location, and device state (Cisco Duo). NIST SP 800-162 defines ABAC as evaluating attributes of the subject, object, requested operations, and environment conditions against policies. That's exactly the kind of dynamic policy that zero trust demands. In a zero trust architecture, access is granted per session based on dynamic policy considering the state of the user, device, and environment (NIST SP 800-207). ABAC gives you that flexibility; RBAC gives you static assignments.

Security Posture

Both can enforce least privilege, but they do it differently. RBAC supports separation of duty, a principle that divides critical functions so no single individual has enough access to commit fraud (NIST SP 800-53). The INCITS 359 standard defines static and dynamic separation of duty (NIST RBAC (INCITS 359)). ABAC, with its fine-grained attributes, can enforce least privilege down to the individual request. But with great power comes great responsibility: a misconfigured ABAC policy can inadvertently grant access to a wider audience than intended. RBAC is simpler to audit; ABAC requires deeper testing.

Who Should Use Which

If you're a small or mid-sized organization with clear job functions, start with RBAC. It scales well for defined job roles (Cisco Duo). If you're in a regulated industry or handling sensitive data with complex access requirements, you'll likely need ABAC at some point. And if you're building a zero trust architecture, you'll need ABAC-like dynamic policies. But even then, don't throw away your roles. Use RBAC as the baseline and layer ABAC on top. That's the pragmatic path we've seen work.

The Winner: RBAC First, ABAC Second

For most teams, the winning strategy is to implement RBAC first and add ABAC where needed. Why? Because RBAC gives you a solid, auditable foundation that's easy to get right. It's what the NSA and NIST designed for, and it's what most identity management systems support out of the box. ABAC is powerful, but it's also more complex to implement and maintain. You don't want to debug a policy engine when you could be shipping features. Start with roles, get them right, then add attributes for the edge cases.

Consider a concrete example: a healthcare app. You have doctors, nurses, and admins. RBAC handles the role assignments: doctors can view medical records, nurses can update vitals, admins can manage schedules. But what about a doctor who is also a patient? That's an exception. With ABAC, you can add a policy: deny a doctor access to their own record if they're a patient. That's a classic separation of duty scenario. But you don't need ABAC for everything—you need it for the exceptions.

Our Takeaway

Don't choose between RBAC and ABAC. Start with RBAC because it's simpler, more scalable, and easier to audit. Then layer ABAC on top for context-aware decisions like time-of-day restrictions or device compliance. That's how you get the best of both worlds without drowning in complexity. And if you're moving to zero trust, remember that zero trust requires dynamic policy—so ABAC will become your friend. But you'll thank yourself for having a clean RBAC base to build on.

Sources

• Cisco Duo - https://duo.com/learn/access-control-models
• NIST RBAC (INCITS 359) - https://csrc.nist.gov/projects/role-based-access-control
• NIST SP 800-162 (ABAC) - https://csrc.nist.gov/pubs/sp/800/162/final
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• NIST SP 800-53 - https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final