RBAC vs ABAC vs ReBAC in Plain English

Every IAM job description eventually mentions access control models. RBAC shows up the most. ABAC appears in anything cloud-native or policy-heavy. ReBAC is newer and mostly lives in product security and authorization startups.

The explanations you find online are usually one of two things: a vendor whitepaper trying to sell you their platform, or an academic paper that defines everything precisely but tells you nothing about what the work actually feels like.

Here is what these three models do in practice, when each one matters, and what it means for your career if you are working in or trying to break into IAM.

The Real Question Behind All Three

Before we get into mechanics, it helps to understand what these models are actually arguing about.

They are not arguing about security. All three can be secure or insecure depending on how they are implemented.

They are arguing about who decides who gets access, and how those decisions get expressed as rules.

In RBAC, the answer is: someone designs roles, and roles carry permissions. You get access because of the role you hold.

In ABAC, the answer is: policies evaluate attributes — your department, location, device, risk score, time of day — and make a decision at request time.

In ReBAC, the answer is: your relationship to a resource determines access. You can edit this document because you are its owner. You can view this project because you belong to a team that was granted access.

Same problem. Different mental models for how to encode the rules.

RBAC: Roles Carry the Permissions

Role-Based Access Control is the workhorse of enterprise IAM. If you have used Active Directory groups, Okta group assignments, or SailPoint role bundles, you have used RBAC.

The idea is straightforward: define roles that map to job functions, attach permissions to those roles, then assign users to roles. When someone joins the finance team, they get the Finance Analyst role, which grants them access to the GL system, expense reporting, and the finance SharePoint. When they leave finance, the role gets removed.

Where RBAC works well

RBAC is strong in environments where job functions are stable, well-defined, and do not change every quarter.

A 5,000-person company with clear departments, predictable hiring patterns, and a mature HRIS can run RBAC cleanly. The IAM team designs roles, maps them to entitlements, and ties them to HR attributes like department, title, and location. Joiner-mover-leaver automation handles most of the lifecycle.

This is the bread and butter of identity governance. If you look at IGA platforms like SailPoint, Saviynt, or Oracle Identity Governance, role management and access certification are the core workflows. The tooling assumes RBAC.

Where RBAC breaks

RBAC has a well-known failure mode: role explosion.

It starts innocently. You have 30 roles for 30 job functions. Then someone in marketing needs temporary access to the analytics platform. Rather than redesign the role model, someone creates a "Marketing Analyst + Analytics" role. Then a contractor needs a stripped-down version. Then the London office has slightly different compliance requirements. Within two years, you have 600 roles, half of which overlap, and nobody can explain what "Finance_Analyst_EMEA_v3_Temp" actually grants.

Role explosion is not a theoretical problem. It is the single most common complaint in access review meetings. Reviewers see role names they do not recognize, cannot trace what permissions are bundled inside, and click "approve" because rejecting something they do not understand might break a workflow.

RBAC also struggles with cross-functional work. If your org has project-based teams, matrix reporting, or heavy contractor use, rigid roles tend to lag behind reality. People accumulate roles over time, and nobody cleans them up because the tooling makes removal harder than accumulation.

What job descriptions mean by "RBAC experience"

When a job posting says "experience with RBAC," they usually mean:

• You have designed or maintained role structures in an IGA tool
• You understand birthright vs. request-based access
• You have dealt with role mining, role certification, or role cleanup
• You know why roles drift and what it takes to keep them useful

This shows up most in IGA analyst, IAM analyst, and identity governance roles.

ABAC: Policies Evaluate Attributes at Decision Time

Attribute-Based Access Control shifts the model from pre-assigned roles to real-time policy evaluation. Instead of "you have the Finance role, so you get access," the system asks "does this user, with these attributes, requesting this resource, under these conditions, satisfy this policy?"

The attributes can come from anywhere: the user's department from HR, their device posture from an endpoint agent, their location from IP geolocation, the sensitivity label on the document, the time of day, a risk score from a UEBA platform.

A concrete example: a conditional access policy in Microsoft Entra ID that says "allow access to the finance app only from compliant devices, during business hours, from IP ranges associated with corporate offices, for users in the Finance department." That is ABAC. The decision is not just "are you in the right role?" but "do all these attributes line up right now?"

Where ABAC shines

ABAC is powerful in environments where access decisions need to be context-sensitive and granular.

Cloud environments love ABAC because resources spin up and down constantly, and pre-assigning roles to ephemeral infrastructure does not make sense. AWS IAM policies with conditions on tags, resource ARNs, and request context are ABAC in practice, even if nobody calls it that.

Healthcare and finance use ABAC when regulations require decisions based on data classification, patient relationship, or transaction size — things that cannot be encoded cleanly into a static role.

Zero trust architectures lean on ABAC because the entire premise is "never trust the identity alone — evaluate context at every request."

The operational cost

ABAC's weakness is complexity.

Policy debugging in a pure ABAC system is painful. When a user gets denied, tracing which policy evaluated which attribute and produced which result requires good logging and tooling that most organizations do not have. Compare that to RBAC, where you can usually answer "why does this person have access?" by looking at their role assignments.

Policy management also gets expensive. Writing, testing, and maintaining attribute-based policies requires people who think in boolean logic and understand the full attribute landscape. In a large enterprise, the number of possible attribute combinations is enormous, and unintended policy interactions create access gaps or overprovisioning that are hard to detect.

This is why most real enterprises do not run pure ABAC. They run RBAC as the base layer and layer ABAC on top for specific high-risk or high-variability decisions. Conditional access policies in Entra ID are a common example: roles handle the broad strokes, and attribute-based conditions handle the edge cases.

What job descriptions mean by "ABAC experience"

Roles that mention ABAC tend to be:

• Cloud security or cloud IAM positions working with AWS IAM policies, Azure conditional access, or GCP IAM conditions
• Zero trust architecture roles
• Policy engineering or authorization engineering roles
• Senior IAM architect positions designing hybrid access models

If a job says "ABAC," expect questions about policy design, attribute sources, and how you handle policy conflicts.

ReBAC: Relationships Determine Access

Relationship-Based Access Control is the newest of the three and the least common in traditional enterprise IAM. But it is gaining traction fast in product security, SaaS authorization, and anywhere fine-grained permissions matter.

The core idea: access is determined by the relationship between a user and a resource, modeled as a graph.

You can edit this Google Doc because you are its owner. You can view it because someone shared it with your team. Your manager can see your performance review because the org chart defines that reporting relationship. A contractor can access Project Alpha's files because they were added to the Project Alpha team, which has a "viewer" relationship to the project's folder.

If this sounds like how Google Drive, Notion, GitHub, or Figma permissions already work — that is because it is. These products use relationship-based models under the hood, even if they do not market them as "ReBAC."

Why ReBAC is gaining traction

Google published the Zanzibar paper in 2019 describing the authorization system behind Google Drive, YouTube, and other services. That paper kicked off a wave of open-source and commercial authorization systems: OpenFGA (now part of the CNCF), Ory Keto, Authzed (SpiceDB), Warrant, and others.

The appeal is intuitive permissions that map to how people actually think about access. "I shared this with my team" is easier to reason about than "I assigned the Document_Viewer_ProjectAlpha_Team3 role" or "a policy evaluates the user's team attribute against the document's project tag."

ReBAC also handles deeply nested permissions well. If Team A has access to Folder X, and Folder X contains Document Y, then Team A members can access Document Y — without anyone explicitly granting that permission on the document. The graph traversal handles it.

Where you will actually encounter ReBAC

Most enterprise IAM teams will not encounter ReBAC in their day-to-day IGA or workforce identity work. RBAC and ABAC still dominate those domains.

You will see ReBAC in:

• Product authorization: SaaS companies building multi-tenant permission systems
• Application security engineering: Teams designing authorization for internal or customer-facing apps
• Developer platforms: GitHub's permission model, Google Workspace sharing, collaboration tools
• Fine-grained authorization projects: Any initiative where "who can do what to which specific resource" matters at the object level

If your career is heading toward application security, product security, or authorization engineering, ReBAC is worth understanding deeply. If you are focused on workforce identity or IGA, it is good to know conceptually but unlikely to be your daily work.

When to Use What

There is no universal winner. The right model depends on what kind of access decisions you are making and who is maintaining the rules.

Use RBAC when:

• Job functions are well-defined and relatively stable
• You need auditors to quickly answer "who has access to what and why"
• Your IGA platform expects role-based workflows
• The org has clear departments and a reliable HR feed

Use ABAC when:

• Access decisions depend on context that changes: location, device, time, risk
• You are operating in cloud environments with dynamic resources
• Regulations require fine-grained conditions beyond what roles can express
• You already have RBAC and need an additional control layer for high-risk scenarios

Use ReBAC when:

• Access is about specific resources, not broad application entitlements
• Permissions follow relationships: ownership, team membership, org hierarchy
• You are building or securing a multi-tenant SaaS product
• Users need to share, delegate, or collaborate on individual objects

Most real environments blend these. A company might use RBAC for broad application access through SailPoint, ABAC through Entra ID conditional access policies for context-based controls, and ReBAC inside their own product for customer-facing permissions.

The models are not competitors. They solve different shapes of the same problem.

What This Means for Your Career

Which model you should understand best depends on where you are heading.

IGA and governance roles (SailPoint, Saviynt, Oracle IGO): RBAC is your primary language. Role design, access certification, birthright access, and role mining are the core skills. Know ABAC conceptually, but your daily work will be role-centric.

Cloud IAM and zero trust roles (AWS, Azure, GCP security): ABAC is central. Conditional access, tag-based policies, resource-level permissions, and policy-as-code are the skills that matter. You will still use RBAC for group and role assignments, but the interesting work is in policy design.

Application security and authorization engineering: ReBAC is increasingly relevant. If you are building permission systems, designing authorization models for SaaS products, or working with tools like OpenFGA or SpiceDB, this is your territory.

General IAM analyst and architect roles: You should be able to explain all three, know when each one fits, and articulate the tradeoffs. In interviews, being able to say "RBAC would work here because the roles are stable, but we would need ABAC for the contractor access use case because their context changes weekly" is more useful than memorizing definitions.

The Honest Take

Most access control model debates generate more heat than light. The arguments tend to be between people selling tools, not people running programs.

In practice, the IAM engineer who can look at an access problem, identify which model fits, explain why to a non-technical stakeholder, and implement it without creating a maintenance nightmare is far more valuable than someone who can recite the theoretical advantages of one model over another.

The models are mental tools. Learn them well enough to pick the right one for the job, and move on to the actual work: making sure the right people have the right access, the wrong people do not, and the whole thing does not collapse when someone transfers departments on a Friday afternoon.

If you are building your IAM career and want to see which roles emphasize which models, browse the current listings on IAM Jobs. IGA roles will lean RBAC. Cloud security roles will lean ABAC. Authorization engineering roles — still rare, but growing — will lean ReBAC. Knowing which model maps to which job family helps you target your learning where it will actually pay off.