RBAC vs ABAC: Access Control Models Compared, With Examples

Someone on your team just asked for access to the finance folder. Do you give it to them because of their job title, or because of who they are, what the file is and where they’re signing in from? That’s the whole RBAC vs ABAC debate in one question.

Both models answer the same thing: who is allowed to do what. They just reach the answer in different ways. Pick the wrong one and you end up with either hundreds of near-identical roles nobody understands or a policy engine so clever that no one can explain why access was denied.

This guide explains each model in plain English, shows where each one fits, and gives you a practical path that most growing companies follow.

What RBAC means

Role-based access control (RBAC) ties permissions to roles, then puts people into roles. A “Sales rep” role can read the CRM and create quotes. A “Sales manager” role can do that plus approve discounts. When Maria joins sales, you add her to the Sales rep role and she gets everything that role allows.

RBAC has deep roots. NIST developed a formal RBAC model, and it was adopted as an American National Standard (ANSI/INCITS 359-2004) in 2004, then revised in 2012. The standard describes a few building blocks:

• Core RBAC: users, roles, permissions and sessions.
• Role hierarchies: a senior role inherits the permissions of a junior one, so “Sales manager” automatically gets everything “Sales rep” has.
• Separation of duties: rules that stop one person from holding conflicting roles, such as creating a vendor and approving payments to that vendor.

The strength of RBAC is that it matches how businesses already think. You have departments and job titles. Auditors can read a role list and understand it. Most SaaS apps, from Microsoft 365 to your accounting software, ship with built-in roles for exactly this reason.

What ABAC means

Attribute-based access control (ABAC) makes decisions by checking attributes against rules. NIST’s guide on the topic, Special Publication 800-162 (January 2014), describes ABAC as evaluating attributes of the subject (the user), the object (the resource), the requested operation and, in some cases, the environment against policy.

In practice, that means rules like:

• “Doctors can read records of patients assigned to them.”
• “Staff can download files labeled Internal only from company-managed devices.”
• “Project team members can edit resources tagged with their project name.”
• “Contractors can access the billing system only during business hours.”

None of those rules mention a role. They compare a user attribute (assigned patients, device status, project tag, employment type) to a resource attribute (patient ID, data label, resource tag) and a context attribute (time, network, location).

Key takeaway: RBAC asks “What is your job?” ABAC asks “Do the facts about you, this resource and this moment satisfy the rule?” RBAC is easier to manage; ABAC is more precise.

RBAC vs ABAC side by side

Where RBAC starts to break

RBAC works well until your exceptions pile up. The classic failure is role explosion. You start with 10 roles. Then someone needs “Sales rep, but also can view West region invoices.” Then “Sales rep, West, read-only for contracts.” A few years later you have hundreds of roles, many with one member, and nobody dares delete any of them.

AWS calls out a related problem in its IAM documentation. With a traditional RBAC setup, each job-function policy lists the specific resources it can reach, so when your team adds new resources you have to update the policies. If a project spins up new servers, someone must edit the role before the team can use them.

Signs RBAC is straining:

• You’re creating roles for single people.
• Role names include regions, projects or customers (“Support-Acme-ReadOnly”).
• Access reviews take days because no one knows what each role really grants.
• Your rules depend on context, such as device health or location, that roles can’t express.

Where ABAC earns its keep

ABAC shines when the rule depends on which record, not just what kind of record. AWS lists several advantages in its documentation: ABAC permissions scale as new resources are created, you need fewer policies, and you can pass employee attributes from your corporate directory through SAML or OIDC sign-in so permissions follow the person.

Here’s the AWS-style example in plain terms. Tag every cloud resource with a project name. Tag every user or role with the project they work on. Write 1 policy: “Allow actions when the user’s project tag matches the resource’s project tag.” When a new project starts, you don’t write a new policy. You just tag things correctly.

Microsoft takes a similar approach in Azure. Azure ABAC builds on Azure RBAC by adding role assignment conditions, extra checks attached to a role assignment. Microsoft’s docs give the example of granting read access to storage blobs only if they’re tagged Project=Blue. Microsoft notes that conditions currently apply to role assignments with Blob Storage or Queue Storage data actions, so check the docs for the current scope before you plan around them.

ABAC also fits healthcare, finance and legal teams, where “Can this person see this specific record?” matters more than “Is this person in billing?”

The catch with ABAC

ABAC is only as good as your attributes. If your HR system has stale department data or half your cloud resources are untagged, ABAC will make wrong decisions quickly and consistently.

Other trade-offs to plan for:

• Debugging is harder. “Why was I denied?” may require evaluating several rules and attributes.
• Audits need tooling. You can’t just print a role list; you need a way to answer “Who can access X right now?”
• Policy language skills. Rules live in policy engines or languages, such as XACML (an OASIS standard), AWS IAM policy conditions or Cedar, the language used by Amazon Verified Permissions.
• Governance of attributes. Someone must own each attribute, such as department, clearance or project, and keep it accurate.

Most teams use both

The real-world answer is rarely RBAC or ABAC. It’s RBAC for the broad strokes and ABAC conditions for the sharp edges.

• Roles define the job: “Support agent can view tickets and customer profiles.”
• Attributes narrow it: “…only for customers in their assigned region, and only from a managed device.”

Microsoft describes Azure RBAC and ABAC as working together, with RBAC closer to business logic and ABAC adding flexibility. AWS documents that Amazon Verified Permissions supports both models, and that Cedar can combine role-style groups with attribute conditions in a single policy.

This hybrid also fits zero trust security, which expects every request to be checked using context such as device health and location, not just a group membership.

How to choose: a quick decision guide

Where to start

You don’t need a big project to get this right. Follow these steps:

1. Inventory who has access to what. Export users and roles from your identity provider and your top 5 business apps.
2. Define 8–15 core roles based on real job functions. Merge near-duplicates and delete roles with no members.
3. Apply least privilege. Give each role the minimum it needs. Put admin rights in separate roles, ideally covered by privileged access management.
4. Centralize sign-in. Use single sign-on so roles and groups flow from one directory instead of being set app by app.
5. Pick 1 messy area for ABAC. Common first targets are cloud resources (tag-based access) or sensitive data (label-based access).
6. Clean your attributes first. Make sure department, manager, employment type and resource tags are accurate before rules depend on them.
7. Review access every quarter, and remove access immediately when people leave, using an employee offboarding checklist.

If you’re new to the wider topic, start with our guide to identity and access management, then come back to access models. In cloud environments, pair tag-based access with cloud security posture management so misconfigured resources get caught. Unfamiliar terms are defined in the glossary.

The bottom line

RBAC is the reliable default: simple, auditable and built into almost every app you use. ABAC is the precision tool for rules that depend on the specific record, the device or the moment. Start with clean roles, add attribute conditions where roles keep multiplying, and invest in accurate attribute data before you trust it with access decisions.

Sources

• NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations — ABAC definition and federal guidance
• NIST Role Based Access Control project — RBAC model history and ANSI/INCITS 359 standard
• AWS IAM: Define permissions based on attributes with ABAC — RBAC vs ABAC comparison and tag-based example
• Microsoft Learn: What is Azure attribute-based access control (Azure ABAC)? — role assignment conditions and supported services
• Amazon Verified Permissions API reference — Cedar support for RBAC and ABAC
• OASIS XACML 3.0 core specification — standard ABAC policy language