Key takeaways
RBAC assigns permissions based on organizational roles, making it straightforward to implement and audit.
ABAC evaluates multiple attributes per request, enabling fine-grained, context-aware access control.
Many organizations combine RBAC and ABAC in a hybrid model to balance simplicity with flexibility.
Both models support zero-trust architectures by controlling access at the resource level.
Why you need an organized method of controlling system access
One of the core components of strong cybersecurity is controlling who is allowed to access the resources and data on your systems. It begins with identity verification and authentication. To learn more about how authentication, authorization, and access control work together, see our guide to trusted access. But that is only the beginning. Just because a user has been authenticated does not mean they should automatically have access to every resource. For example, there is no reason engineers should have access to HR records, nor should support agents have access to proprietary product research.
Strong access controls help prevent account compromise. Many organizations experience account compromises tied to weak access controls, which is why structured models like RBAC and ABAC are essential. RBAC and ABAC approach access control from two different perspectives. RBAC is based on defined user roles, and ABAC is based on user attributes. The RBAC vs. ABAC comparison comes down to a fundamental question: should access decisions be based on job roles or on dynamic attributes? Knowing how these two models function will help you decide which is best for your organization.
Role-based access control (RBAC)
What is RBAC in security? Role-based access control assigns permissions based on predefined organizational roles. Management defines a role for everyone in the organization—for example, product manager, technical support agent, or human resources rep. Each role is assigned a set of access permissions, such as edit product schedules, view customer records, or edit employee reviews. Administrators assign each user to a role, or roles, that define what permissions they have to access resources.
An RBAC policy maps each organizational role to a specific set of permissions. RBAC roles typically align with business logic, grouping together individual positions that share a set of responsibilities or characteristics, such as departments, locations, work responsibilities, or management level. Each role is assigned a set of permissions, which the user inherits by being assigned to that role. This model provides broad granularity in assigning access permissions.
How you assign roles depends on how granular you want to be. For example, you may have a role for HR rep and another for HR manager, where the rep can view employee reviews but only the manager can edit them. Alternatively, you could have separate roles for rep and manager that are combined with the HR role to achieve the same result. RBAC implementations typically require less initial configuration than ABAC because roles map directly to existing organizational structures like departments and job titles.
When implementing RBAC, start by mapping existing job functions to roles. A job function's role, or roles, should have all the permissions required to do the job, but no more. Onboarding new employees becomes as simple as assigning them to the appropriate role.
Role-based access control example
A company defines three roles: Viewer, Editor, and Admin. The Viewer role can read documents but not modify them. The Editor role inherits Viewer permissions and adds the ability to create and edit documents. The Admin role inherits all Editor permissions and adds the ability to manage users and change system settings.
Pros and cons of RBAC
The main benefit of RBAC is its simplicity. Roles are based on job function, so policies are easy to develop, administer, and audit. The same role can be assigned to multiple users, making administration straightforward. Demonstrating compliance is also less time-consuming, since auditors can easily review the role definitions and permission assignments.
The simplicity of RBAC can become a drawback, however, in large or growing organizations when trying to fit everyone into a role leads to what is called role explosion. Trying to cover every nuance or add granularity can result in so many roles it becomes hard to manage. RBAC's simplicity also limits the granularity of control. RBAC tends to grant broad access for the role rather than considering individual needs. And RBAC does not consider the context of the access request. All it knows is that the user in this role has these permissions, regardless of external factors such as the device being used, the time of day, or the risk associated with the request.
RBAC implementations: flat, hierarchical, and constrained
There are three categories of RBAC implementation. The right one depends on your organizational requirements.
Attribute-based access control (ABAC)
What is ABAC in security? Attribute-based access control assigns permissions based on evaluating a set of attributes. Attributes are characteristics associated with the user, the resource being accessed, the action being performed, and the environment in which the access request is being made. ABAC evaluates multiple attributes before granting access.
User attributes: Who is asking for access? User attributes describe the user, such as their department, role within that department, and location.
Resource attributes: What is the object of the request? Resource attributes describe the resource being accessed, such as the resource category, its location, who owns it, and how sensitive it is.
Action attributes: What action is being requested? Action attributes describe the action, such as read, write, or delete.
Environmental attributes: Under what conditions is the request being made? Environmental attributes provide additional context, such as device posture, time of request, threat level, and source of request.
ABAC implementations consider the dynamic factors associated with an access request. Policies are typically created using logical rules that examine the request attributes and determine which combinations are allowed to access the resource. When a user makes an access request, ABAC collects the necessary attributes associated with the user, the resource, the request, and the environment, then evaluates them based on established policies. Allow or deny decisions are made by exercising the logic rules, often implemented as a set of IF–THEN statements, associated with the request. This supports zero-trust access models, where every request—not just initial logins—is verified before being trusted.
Attribute-based access control example
Here is an example of ABAC in action. A policy states that only users in the finance department (user attribute), accessing the payroll application (resource attribute), from a corporate device (environmental attribute), during business hours (environmental attribute), can view salary records (action attribute).
Pros and cons of ABAC
One of the main strengths of ABAC is its ability to create and administer complex business rules. It allows permissions to be based on context as well as user job function. And it is easy to introduce a new permission by combining existing attributes rather than creating a new role. Because ABAC can consider real-time factors such as device security, geo-location, and threat level, it is well suited for zero-trust architectures, where permissions are examined for each request rather than only at the start of a user session.
The flexibility of ABAC can be a drawback if administration resources are limited. ABAC can require a heavy up-front investment in setup and implementation. Policies and allow-or-deny decisions need to be carefully designed to ensure there are no conflicts or gaps in coverage. Attribute quality also needs to be monitored to ensure that attributes remain current and correct.
RBAC vs. ABAC: comparing the two models
RBAC works best in smaller and more stable organizations with well-defined job roles. Permissions reflect who you are in the organization and what your job function is. ABAC works best in dynamic environments where the organization requires highly specific, context-aware, flexible access control. Permissions consider not only who you are, but also what you are doing, and where and when you are doing it. Which model you deploy depends on your organization's size and complexity, business needs, regulatory requirements, and the maturity of your identity and access management.
The table below summarizes some of the key characteristics of both models.
Aspect | RBAC | ABAC |
|---|---|---|
Access model | Based on predefined roles. | Based on user, resource, environment, and action attributes. |
Granularity of access control | Broad-based. | Can be fine-grained and highly targeted. |
Initial investment | Relatively small. | Can be substantial. |
Management | Easy to implement and administer. | Requires mature policy and attribute management. |
Security | Controls access by role assignment; does not evaluate request context. | Evaluates multiple attributes per request, enabling least-privilege access decisions. |
Security maturity | Good for organizations starting to implement, or not yet well-versed in, access control. | Good for organizations with established familiarity with access control. |
Best for | Small or static organizations with well-defined job roles. | Larger, growing, or dynamic organizations needing context-aware control. |
The hybrid RBAC/ABAC model
Some organizations choose a hybrid approach to access control, deploying a combination of ABAC and RBAC. You could deploy RBAC to control broad-based or high-level permissions and use ABAC policies to tighten access for risk-sensitive resources. Assignment of roles and related permissions remains relatively simple, while ABAC adds flexibility when needed in making the allow-or-deny decision.
Other access control models include rule-based access control, which uses predefined system rules rather than user roles or attributes to make access decisions. Organizations sometimes combine rule-based policies with RBAC or ABAC for additional flexibility.
Access control models and zero trust
Organizations that are tightening security around who can access system data and resources are moving toward zero-trust architectures. Zero-trust policies are based on the tenet "never trust, always verify." Zero trust treats every access request as unverified until the system confirms the user's identity and authorization. Both RBAC and ABAC can be used as access control methods supporting zero-trust models. ABAC, with its ability to consider factors such as device state, network conditions, and behavioral signals, is especially well suited for zero-trust architectures.
Cisco Duo's adaptive access policies evaluate contextual signals like device health, location, and user behavior, which aligns with ABAC principles. Most organizations adopt zero trust in phases, starting with identity verification and expanding to device trust and continuous authentication. Deploying phishing-resistant MFA with RBAC or ABAC can help you transition from a basic MFA model to zero trust. To see how to make this transition, read our guide on how to go from MFA to zero trust.
Ready to strengthen your organization against identity-based attacks with phishing-resistant MFA, device trust, and more? Try Duo for free.