1 Access Control Models: RBAC, ABAC, ReBAC, PBAC and Beyond
Early literature often depicted RBAC as the stepping stone to ABAC, followed by even more dynamic models [1].
This raised the question: is there a logical sequence (e.g. RBAC then ABAC), or can multiple models be blended for the best of both? [2] But it's time for a new stocktaking anyway: What authorization models are currently available? How do they differ? What do they have in common? And what trends are discernible?
2 Origins and Motivation of Each Access Control Model
2.1 Discretionary Access Control (DAC):
One of the earliest models, DAC emerged in the 1970s. It allows resource owners (or subjects) to discretionarily grant or revoke access to their objects (e.g. file owners set access control lists on who can read/write) [3]. DAC was created for flexibility in timesharing systems, but it can be error-prone (users might grant access insecurely) and doesn’t enforce a central policy – which led to the need for more structured models.
2.2 Mandatory Access Control (MAC):
Developed for high-security environments (e.g. military), MAC assigns fixed security labels to users and data (e.g. classified levels). Access is decided by a system-enforced policy (e.g. “Top Secret” clearance required to read “Top Secret” files) rather than by owners. MAC’s origin lies in preventing leakage of sensitive information by strict rules, but it’s inflexible for general business use (it’s largely confined to government and defence industries).
2.3 Role-Based Access Control (RBAC):
Formalized in the early 1990s (Ferraiolo and Kuhn, 1992) and standardized by 2004 [4], RBAC was created to simplify administration by grouping permissions into roles. Instead of managing access per user or per object, administrators assign users to roles (like “Employee,” “Manager”) and grant permissions to those roles. This model reflects organizational job functions, which usually change slowly, while users can enter/leave roles dynamically [5]. RBAC gained popularity because it aligns with business hierarchies and makes audits easier (you can review role permissions rather than individual user rights). It also introduced role hierarchies (roles inheriting permissions from other roles) to reduce duplication [6], and it naturally supports separation-of-duties policies (e.g. ensuring no single role has all critical powers) [7]. RBAC became widely used in enterprises [8] across many industries (especially where job titles or departments correlate with access needs, such as finance or healthcare). Its creation was motivated by the shortcomings of DAC/MAC in business contexts – RBAC provided a practical and scalable way to manage corporate access centrally.
2.4 Attribute-Based Access Control (ABAC):
By the mid-2000s, organizations faced more dynamic access requirements that RBAC struggled with. Issues like “role explosion” (too many roles needed to cover all cases) and the desire for contextual decisions (based on time, location, device, etc.) led to ABAC’s emergence [9], [10]. ABAC determines access through evaluation of attributes of the user, resource, action, and environment against policies (rule sets). For example, a policy might grant access if department = Finance and transaction amount < $10,000 and request during work hours – something hard to express with pure roles. Early work (e.g. Karp et al., 2009) traced ABAC concepts and set the stage for formalizing it [11]. ABAC wasn’t defined by a single standard initially, and even today it’s more of a conceptual approach than one strict model [12]. In practice, ABAC relies on a policy engine (evaluating rules) and attribute data from various sources [13]. ABAC is sometimes referred to as Policy-Based Access Control (PBAC) or Claims-Based Access Control (CBAC) [14] – highlighting that attributes (or claims) and policies are central. (In fact, some use “PBAC” as an umbrella term under which ABAC falls [15].) The motivation for ABAC was to achieve fine-grained, context-aware decisions and greater agility in access management than static roles allowed [16]. ABAC gained theoretical support from NIST (see NIST SP 800-162 defining ABAC [17]) and practical support through standards like XACML (OASIS’s eXtensible Access Control Markup Language) which was designed to express ABAC policies [18]. ABAC is broadly applicable across industries – especially for large enterprises, cloud services, and government agencies that require dynamic policy enforcement beyond simple role checks.
2.5 Policy-Based Access Control (PBAC):
The term PBAC is often used interchangeably with ABAC, but it emphasizes the management of policies as first-class objects. In PBAC, an organization defines high-level policies (often in code or declarative language) that directly encode business rules, and these policies use attributes to make decisions [19]. The nuance between ABAC and PBAC is subtle: ABAC usually implies that attributes and attribute-based rules drive decisions, whereas PBAC implies that policies (potentially maintained separately from application code) determine which attributes and logic to apply [20]. In effect, PBAC is an evolution of ABAC – recognizing that as attribute-based rules grow complex, managing them as centralized policies (with proper tools, possibly a GUI for business admins) becomes crucial [21]. PBAC emerged in the 2010s as organizations sought to delegate authorization logic to policy engines (like OPA’s Rego or AWS’s Cedar policy language) instead of hardcoding rules. Analyst firms like KuppingerCole identified PBAC as a growing market, reflecting demand for easier policy authoring and maintenance [22]. In summary, PBAC was “created” not as an entirely new model but as a practical approach to implement ABAC at scale – combining attributes with structured policies, often to achieve easier compliance and to empower non-developers to adjust access rules. This approach is very relevant in cloud and microservices environments, where policy-as-code and externalized authorization are now best practices.
2.6 Relationship-Based Access Control (ReBAC):
ReBAC is a newer paradigm that gained attention in the 2010s, driven by use cases like social networks, collaboration platforms, and multi-tenant cloud applications. The term was first coined by researcher Carrie Gates around 2007 [23], who observed that traditional models focus on roles or attributes of a single user, whereas many real-world decisions are based on relationships (e.g. connections between users, group membership, ownership of resources). ReBAC uses the presence of a relationship between entities as a basis for access. For example, Alice can view a document because she is the owner’s manager, or a photo is visible because the viewer is a friend-of-a-friend of the owner. Essentially, ReBAC treats authorization as a graph problem: users, resources, and other entities are nodes, and edges (relations) like friend, parent, member-of-team, owns-resource determine permissions [24]. The model was popularized when Google in 2019 revealed Zanzibar, its global authorization system that uses relationship tuples to manage permissions across Google services [25]. Zanzibar demonstrated that a ReBAC approach can handle very complex, hierarchical sharing scenarios with high performance and consistency. ReBAC was created to address scenarios where the access policy isn’t just about user’s attributes or role, but about how the user is related to the resource or to other users. A classic example is in content-sharing apps: rather than creating an attribute for “owner = Alice” on every file (as ABAC would do), ReBAC can naturally say “Alice has owner relationship to File1, therefore grant all owner permissions on File1” [26]. ReBAC’s rise also coincides with the microservices trend – companies like Facebook, Google, and Amazon needed ways to externalize authorization with graph-based logic. While still emerging, ReBAC has inspired many open-source implementations (e.g. Oso, Ory Keto, SpiceDB/OpenFGA) that implement Zanzibar-like models [27]. In short, ReBAC was motivated by the need for fine-grained sharing and hierarchical access control that is cumbersome to implement with just roles or attributes.
2.7 Risk-Adaptive Access Control (RAdAC):
Also known as risk-based or risk-aware access control, RAdAC is an extension of ABAC that incorporates real-time risk assessment into decisions. It was proposed in the late 2000s by the U.S. Department of Defence and NIST as a way to “adapt” access decisions based on context risk factors [28]. Traditional models treat access as a yes/no based on static rules; RAdAC was created to emulate real-world decision making by balancing the security risk of granting access against the operational need for access [29]. For example, under RAdAC a user might normally be denied access to certain data, but if there is a critical emergency (high operational need) and the security risk is acceptable, the system adapts to grant access temporarily [30]. Conversely, if a user’s context seems risky (e.g. logging in from an unusual location or failing some security checks), the system might restrict or reduce their access even if they technically have permissions – effectively tuning access based on a risk threshold. RAdAC builds on ABAC by using attributes like threat level, user trust score, or environment risk indicators in the policy. The model came about as organizations adopted “zero trust” and continuous monitoring philosophies, especially in government and finance sectors where the balance between sharing information and security is delicate. It’s not as widely formalized in products, but the concept is influential – modern Adaptive Authentication and Conditional Access policies (such as requiring MFA if risk is high) are real-world manifestations of risk-based control. In summary, RAdAC’s creation was driven by the need for dynamic, context-sensitive authorization that can tighten or relax access based on real-time risk assessments [31].
2.8 Other Notable Models:
Beyond the above, academia and industry have proposed other models, though with more niche adoption. Organization-Based Access Control (OrBAC), for instance, was introduced by researchers in the 2000s to factor in organizational structure – defining permissions in terms of roles, activities, and contexts (making policies easier to manage across an organization’s units). Capability-Based Access Control (originating from research in the 1970s on capability systems) is another model, where a capability (an unforgeable token or key) is required to access an object; this model influenced designs in operating systems and cloud object storage (e.g. presigned URLs act like capabilities). These and other variants (context-based, rule-based, purpose-based access control, etc.) often overlap or build on the core concepts of RBAC and ABAC. In practice, many “new” models are attempts to blend or fine-tune existing ones to solve specific problems (for example, Purpose-Based Access Control in healthcare ensures data is accessed only for allowed purposes – effectively an attribute/policy added to ABAC for privacy compliance).
Overall, the creation of each model was a response to the limitations of earlier approaches: as business and security requirements evolved (more users, more data sharing, stricter compliance, dynamic threats), new models were developed to fill those gaps.
3 What the Access Control Models Have in Common
Despite their differences, all these access control models share some fundamental goals and traits:
3.1 Policy-Driven Decision Making:
Each model provides a structured way to decide “who can do what on which resource” based on a set of rules or policies. Whether the rule is “Alice has role Manager” (RBAC) or “Alice’s department is X and it’s before 5PM” (ABAC), the decision is made by evaluating defined criteria rather than on an ad-hoc basis. In other words, all the models externalize authorization logic into some form of policy (roles, attribute rules, relationships, etc.), rather than leaving access up to individual whims. This makes access management systematic and repeatable.
3.2 Abstraction and Simplification:
The models introduce an abstraction layer between users and permissions. For example, RBAC abstracts via roles, ABAC via attributes, ReBAC via relationships. This abstraction is a common strategy to simplify management: administrators deal with higher-level concepts (like “role = Accountant” or “project team relationship”) instead of managing thousands of individual user-to-resource permissions. The goal is to make administration and reviews easier by grouping and reasoning at a higher level.
3.3 Principle of Least Privilege:
All models aim (or can be configured) to enforce least privilege, meaning users should only have the minimum access necessary. The models provide different mechanisms to achieve this (e.g. RBAC allows assigning only appropriate roles to each job, ABAC allows fine-grained conditions to narrow when access is allowed, etc.). In essence, each framework is a means to avoid overly broad access by using structured rules.
3.4 Separation of Policy from Enforcement:
In all cases, there is a conceptual separation between the policy that decides access and the enforcement mechanism (like the system or application that checks the policy). For example, RBAC policy might live in a central IAM system, ABAC policies in a policy engine or config, and ReBAC rules in a database of relationships. They all have a notion of a policy decision point (PDP) and policy enforcement point (PEP), even if not explicitly named in simpler models [32]. This separation is common to modern authorization: a request is evaluated by referencing the policy model, and then allowed or denied by the system.
3.5 Combining Multiple Factors:
Eachsuccessive model expanded the range of factors that could be considered in an access decision, but they all can work together. For instance, attributes (ABAC) can be used within role definitions (RBAC) as constraints, and relationships (ReBAC) can be represented as special attributes or vice versa. At a high level, every model deals with subjects, objects, actions, and often context – just with different emphasis. This is why many experts view RBAC and ABAC as not mutually exclusive but complementary pieces of a larger “×BAC” puzzle [33]. In practice, real-world systems tend to use a hybrid approach, combining roles, attributes, and sometimes relationships to meet their needs [34]. The common thread is that all these models provide a framework for fine-grained authorization that can be mixed and matched.
3.6 Standardization Efforts:
Another commonality is that many of these models have been subject to standardization or at least formal description. For example, RBAC has an ANSI/NIST standard defining its core element [35], and ABAC is described in NIST guides [36]. While not all models have official standards (ReBAC is still emerging), they all inspire best practices and frameworks. This reflects a shared recognition that access control decisions must be consistent and verifiable, which drives communities to document and agree on common semantics for roles, attributes, policies, etc. All models benefit from having governance processes and maybe certification (e.g., ISO 27001 touches on access control but doesn’t mandate a model). In short, each model, old or new, exists to make access decisions more structured, transparent, and controllable.
3.7 In summary, …
The models share the aim of managing complexity in authorization. They each abstract away individual permission bits into broader concepts (roles, attributes, relations), and they rely on defined policies to ensure only authorized interactions occur. They differ in what they abstract and how they express policies, but all are responses to the fundamental need to protect resources while enabling business or user needs.
4 Key Differences Between RBAC, ABAC, ReBAC, PBAC, etc.
While the models can overlap and be combined, each has distinct characteristics. The key differences include the factors used for decisions, the granularity and dynamism of access control, complexity for administrators, and typical use cases. Below we break down major differences:
4.1 Primary Control Factor:
RBAC’s decisions are based on roles (sets of permissions) assigned to users [37]. ABAC decisions are based on attributes of subjects, objects, actions, and environment, evaluated against logical rules/policies [38]. ReBAC decisions hinge on relationships (e.g. edges in a graph) between users and resources (or between users) [39]. PBAC, as a variant of ABAC, centres on policies that dictate which attributes and rules to apply [40]. RAdAC incorporates an extra factor: risk level or operational urgency, adjusting decisions dynamically based on risk analysis [41]. In DAC, the primary factor is the identity of the accessor, as stored in an access control list by the object’s owner. In MAC, it’s the security labels (classification level and compartments) on subjects/objects. So, each model emphasizes a different decision input: RBAC = role, ABAC = flexible attributes, ReBAC = graph relationships, RAdAC = calculated risk, etc.
4.2 Policy Granularity and Expressiveness:
RBAC is often called coarse-grained – a role can cover a broad set of permissions, and it’s binary (you either have a role or not, no further context) [42]. ABAC allows fine-grained specifications, since you can combine many attributes and conditions (date, time, IP address, clearance level, etc.) to finely slice who can do what [43]. It can enforce very granular rules (down to specific object attributes or fields) that RBAC alone cannot easily handle. ReBAC is also fine-grained in that it can distinguish access at the level of individual relationships (e.g. only members of this particular project can access this file). However, ReBAC by itself might not handle dynamic conditions well – it excels at capturing static hierarchies and group memberships but not things like time-of-day without introducing those as additional attributes [44]. PBAC’s granularity is similar to ABAC (since it uses attributes under the hood), but it can simplify management of fine-grained policies by structuring them in high-level rules [45]. RAdAC effectively adds another layer of granularity – the decision might vary each time based on risk context, making it adaptive. In short, ABAC (and PBAC) typically offers the highest granularity and flexibility (any attribute combination), ReBAC is very expressive for hierarchical or social structures, and RBAC groups permissions in larger chunks (roles).
4.3 Dynamism and Context Handling:
RBAC roles are generally static assignments (a user’s role changes only when an admin updates it, not due to context at runtime). ABAC is dynamic by design – attribute values or environment context can change at runtime, and the policy will grant/deny accordingly in real time [46]. For instance, access can automatically expire when a project attribute changes or when outside business hours. ReBAC sits somewhat in between: relationships (like group membership) can change, but they usually change through an explicit action (someone added to a group). ReBAC doesn’t inherently incorporate ephemeral context like time or location – those would be additional attributes beyond the relationship itself. PBAC, like ABAC, can evaluate in real time as conditions change, since it’s effectively attribute-driven beneath the policy. RAdAC is highly dynamic: it adjusts to runtime risk assessments (which might change with each login or transaction). A RAdAC system might allow a normally forbidden action if an emergency flag is on (context), or require extra approval if risk is high – effectively the policy thresholds shift on the fly [47]. Thus, ABAC/PBAC and RAdAC are oriented towards adaptive, context-aware control, whereas RBAC is context-neutral (unless combined with ABAC constraints), and ReBAC is context-neutral except for the state of the relationship graph.
4.4 Simplicity vs. Complexity (Admin and User Perspective):
RBAC is known for administrative simplicity: once roles and permissions are defined, it’s straightforward to add a user to a role and know roughly what they’ll get. It’s also easier for auditors to review “who has access to what” by looking at role membership. ABAC trades that simplicity for flexibility – it can suffer from complexity because you have potentially many attributes and rules interacting [48], [49]. Determining why a user has (or doesn’t have) access in an ABAC system can be non-intuitive if many policies overlap. ReBAC introduces complexity of a different kind: understanding and managing a graph of relationships can be hard, especially as it grows deeply nested (e.g. user -> group -> subgroup -> resource relationships). Auditing ReBAC can be challenging, since one must trace through graph connections to figure out effective access [50], [51]. However, ReBAC can also simplify certain scenarios (like hierarchical permissions) that ABAC would make verbose [52], [53]. PBAC attempts to reduce complexity by providing a higher-level language or interface for writing policies, which can mitigate some ABAC difficulties (for example, a user-friendly policy GUI might let compliance managers set rules without coding) [54]. In terms of user experience, RBAC is transparent – a user either has a role or not, whereas ABAC/RAdAC might be less predictable (access might be allowed one day but denied the next if an attribute or risk level changed). ReBAC’s user experience is intuitive in social terms (“you have access because you’re in this group” is easy to grasp), but the transitive effects (like friend-of-friend access) can surprise users if not clearly communicated. Summing up: RBAC is easiest to understand and manage at small scale, ABAC/PBAC offer more power at the cost of complexity, and ReBAC adds complexity in managing relationships but simplifies certain hierarchical policy definitions [55], [56]. RAdAC is complex in that it requires integrating risk engines and may be hard to tune correctly (you need to define risk models), but it provides a very adaptive security posture.
4.5 Scalability and Performance:
In terms of technical performance, the models differ in how decisions are computed. RBAC is typically fast – it’s essentially a set membership check (is user X in role Y and does role Y allow action Z?). ABAC can be more performance-heavy, especially if there are many policies to evaluate or if attributes need to be fetched from multiple sources at runtime [57]. ABAC decisions might involve database lookups for attributes, complex boolean rule evaluations, etc. ReBAC decisions often require graph traversals – e.g., checking if there is a path between user and resource nodes with a certain relationship. In large graphs, naive traversal can be slow, but systems like Zanzibar use caching and index optimization to make this efficient [58], [59]. In fact, ReBAC naturally supports reverse index queries (e.g. “who has access to resource Y?”) which are hard in ABAC [60]. PBAC performance is similar to ABAC, but one advantage is that policies can be optimized and pre-compiled since they’re code – a well-implemented PBAC engine (like OPA) can evaluate policy logic very quickly in memory. RAdAC adds overhead because it might call risk analytics or require up-to-the-moment context (like running a fraud detection model before allowing access), which can introduce latency. Scalability-wise, RBAC struggles when roles proliferate (role explosion = admin scalability issue), whereas ABAC scales in terms of policy definitions but might hit computational scaling issues if not managed (too many simultaneous attribute evaluations). ReBAC is designed to scale to very large numbers of relationships; its challenge is more data modelling (ensuring your relationship definitions cover all needed scenarios). Cloud providers and large-scale applications have shown ABAC and ReBAC can scale if implemented carefully (AWS IAM uses attribute-based policies under the hood, Google uses ReBAC globally), but the complexity must be tamed. In summary, RBAC is computationally simple but administratively can become unwieldy at scale; ABAC/PBAC can encode complex logic in fewer policies but need efficient engines and good governance; ReBAC can be highly scalable for the right patterns (lots of objects with group memberships) but needs graph tech to be efficient.
4.6 Theoretical Power:
There’s an ongoing debate about the expressive power of ABAC vs ReBAC. Some argue that ABAC is more general – after all, one can express relationship checks as just another attribute/policy condition (e.g. a rule “permit if user is in resource.owner.friends list” could mimic a friendship relationship) [61]. From this perspective, ReBAC might be seen as a subset or special case of ABAC (just focusing on one kind of attribute: relationships) [62]. On the other hand, proponents of ReBAC note that graph-based policies can naturally handle recursive relationships and transitive permissions in ways that ABAC finds clumsy or inefficient [63]. For instance, granting access to all files in a folder hierarchy is simple with ReBAC (just check ancestor relationships), whereas ABAC might require propagating an attribute down to every file or writing recursive rules [64], [65]. In practice, each model can emulate aspects of the other, but with effort: you can implement role checks as an attribute in ABAC (“role = Manager” as an attribute), or simulate a relationship in ABAC, and conversely you can enforce attribute-like conditions in a ReBAC system by encoding them as special relationship types or by combining with ABAC. DAC vs MAC also differ in power: DAC gives autonomy to owners, whereas MAC imposes global rules – MAC can enforce restrictions (like no read-down, no write-up in classified systems) that DAC or RBAC cannot on their own. These differences reflect that each model is optimized for certain policy types. The theoretical takeaway is that no single model is strictly “more powerful” in all aspects; rather, each can express certain policies more naturally than the others. This is why modern frameworks often combine multiple models to leverage the strengths of each [66].
To illustrate differences concisely, consider an example scenario: “A manager needs to approve an expense report if it’s over $1000, but any employee can view their own reports.”
- In RBAC, you might create a “Manager” role that has approval permission, and a “ReportOwner” role for each report (which is awkward – you’d end up with many roles or have to handle ownership outside RBAC).
- In ABAC, you can write a policy: permit view if user.id == report.owner_id; permit approve if user.role == Manager and report.amount > 1000. This directly encodes the condition.
- In ReBAC, you could represent “owns” and “manages” relationships: user ←[owns]– report, user ←[manages]– report. A policy could then say: permit view if user owns report; permit approve if user manages report. If “manages” is defined such that a manager has that relationship to reports in their department, it covers the rule. For the amount condition, ReBAC alone doesn’t express numeric conditions – you’d need to incorporate an attribute (so a mix of ReBAC and ABAC).
- In RAdAC, you might incorporate risk by saying: if riskLevel is high, even managers need a second approval (adapting the policy when certain risk thresholds are met).
- In PBAC, you’d likely have a high-level policy (written perhaps in a human-readable form) that encapsulates all these rules in one place, and the system would handle evaluating the user’s attributes/relationships accordingly.
Each approach differs in how the rule is modelled (role vs attribute vs relationship vs risk condition), and that impacts how many moving parts (roles, policies) you have to manage and how easy it is to update the rule later. The best choice often depends on which difference matters more for the situation: simplicity vs specificity, static vs dynamic needs, and so on.
5 Best-Fit Environments and Use Cases for Each Model
Different models shine in different environments. Below we outline where each model fits best (and any industry tendencies or limitations):
5.1 Discretionary Access Control (DAC):
DAC is still common in localized, small-scale environments where data owners should control access. For example, on a personal computer or a small business file server, the owner of a file deciding permissions is convenient. It’s also the default for many operating systems (Windows, Unix) – users set file ACLs. However, DAC is less suitable in large organizations where a central policy is needed for consistency. Industries with strict compliance tend to avoid pure DAC because an individual could override security policy by granting access. In summary, use DAC when individual ownership and ease of sharing are desired over centralized control (e.g. a collaborative research lab might allow scientists to share files at their discretion). Avoid DAC as the sole model in regulated industries or multi-user applications where you need oversight (it can be combined with other controls though, like an owner granting access but within limits set by admin).
5.2 Mandatory Access Control (MAC):
MAC is ideal for high-security government and military applications. Any environment dealing with classified information, national security, or safety-critical data (e.g. intelligence databases, military command systems) will use MAC or a variant of lattice-based control. Its strength is enforcing system-wide policies consistently (no user, not even an admin, can violate the clearance rules). Outside of those domains, MAC is rarely used because it’s inflexible – it doesn’t cater well to business needs where exceptions or delegated decisions are common. For instance, in commercial enterprises, it would be too rigid to assign every document a classification and never allow exceptions. Some industries with heavy regulations (like certain healthcare or law enforcement systems) might adopt MAC-like controls for very sensitive records (to ensure, say, a police officer can’t see case files without proper clearance). But generally, MAC’s best fit is in closed, highly secure environments with a strict hierarchy of data sensitivity.
5.3 Role-Based Access Control (RBAC):
RBAC is well-suited to organizations of all sizes in virtually any industry – especially where job functions correlate with access needs. It’s the go-to model in corporate IAM (Identity & Access Management) systems and applications like ERP, HR systems, etc. For example, a bank will give tellers one role, loan officers another, etc., and each role carries the appropriate entitlements. RBAC works best when: (a) User roles are relatively static (people don’t change jobs every day), (b) The organization can define a set of roles that cover most access scenarios without needing too many bespoke exceptions, and (c) Compliance and review is a priority – RBAC makes it easier to review “who has what” by role rather than a huge list of individual grants. Industries like finance, healthcare, retail, government agencies, education – basically anywhere with defined job roles – have widely adopted RBAC. There are cases where RBAC is less optimal: if an environment’s access needs are highly dynamic or user-specific, RBAC alone may fail (leading to either too many roles or a lot of out-of-band exceptions). For instance, a social media platform managing millions of user-created groups can’t realistically assign roles for each group to each user – that’s where relationship or attribute models take over. But for internal enterprise systems and even cloud platforms’ high-level access (like AWS IAM initially heavily emphasized roles/groups), RBAC is a proven fit. In cloud infrastructure, RBAC is often the first layer (e.g. cloud roles or Azure AD roles) with finer controls layered on via ABAC conditions.
5.4 Attribute-Based Access Control (ABAC):
ABAC is the model of choice when fine-grained and context-dependent access is required. Environments that benefit from ABAC include:
- Large Enterprises and Cross-Domain Systems: When access decisions must consider multiple attributes (role, department, project, data sensitivity, time, location, device posture, etc.), ABAC shines. For example, a multinational company might use ABAC to allow “Finance analysts can approve transactions up to $100K for accounts in their region during business hours” – a policy that touches user role, amount attribute of transaction, user’s region, and time of day.
- Multi-Tenant Applications and Cloud Services: In modern cloud apps, tenants (customers) and users have attributes like subscription level, feature flags, usage metrics that determine access. ABAC allows policies like “Customer X’s administrators can create up to N resources, unless their plan is trial”. Cloud providers like AWS and Azure have introduced attribute-based policy capabilities (e.g. AWS resource tags combined with conditions, or Azure’s conditional role assignments) because roles were too rigid for the cloud’s scale. According to industry reports, the shift to cloud and multi-cloud is driving adoption of fine-grained ABAC/PBAC approaches [67].
- Healthcare and Education: These sectors often require contextual decisions. For instance, ABAC can enforce that “Doctor can access patient record if doctor is assigned to that patient’s care team and treatment is in progress”, combining a doctor’s role, a relationship attribute (assignment), and context (treatment status). While RBAC could give all doctors access to all records (overly broad), ABAC can narrow it down by patient attributes or relationships. (Healthcare also deals with purpose-based rules – ABAC can include the purpose of access as an attribute to ensure privacy.)
- Government and Inter-Agency Sharing: Government systems, guided by NIST and others, have been exploring ABAC to enable more flexible info sharing without sacrificing control [68]. For example, an ABAC system could allow an intelligence report to be shared with an outside agency if certain attributes match (like “share if agency is in coalition AND data is not SIGINT AND requester has need-to-know for topic”).
- Dynamic Workforce and IoT: ABAC is also useful when users and devices proliferate with different attributes – e.g., an IoT network might grant access based on device type and trust level, or a freelance-heavy workforce might rely on attributes like contract status, project, and skills rather than pre-defined roles.
ABAC’s best fit is any scenario requiring agility and precision that RBAC can’t easily provide. However, ABAC can be overkill for small, simple environments (where a few roles would do the job). It also requires a good handle on identity data – all those attributes must be defined and kept up-to-date, which can be challenging. Thus, ABAC is powerful in theory but demands maturity in identity management and governance to use effectively. Many organizations start with RBAC and then introduce ABAC incrementally (for specific use cases like adding environment conditions to high-risk transactions), which aligns with the idea “RBAC first, then ABAC” if needed [69].
5.5 Policy-Based Access Control (PBAC):
PBAC is essentially an approach to implementing ABAC, so its ideal environment overlaps with ABAC’s, but with an emphasis on policy governance. Organizations that benefit most from PBAC are those that want to centralize and simplify policy management. This often includes:
- Enterprises with strong compliance needs: If an organization has to frequently demonstrate that access rules align with corporate policies or regulations (e.g. GDPR, SOX, HIPAA), PBAC helps by making policies explicit and easier to audit. Instead of checking roles manually, an auditor can examine the policy definitions.
- DevOps and Cloud-Native companies: PBAC fits well in a DevOps culture where “policy as code” is embraced. For example, microservice architectures can externalize authorization decisions to a policy engine (like OPA) and write policies in a high-level language that developers and security teams collaborate on. This ensures consistency across services and speeds up changes (no need to recode logic in multiple apps; just update the central policy).
- Mixed-environment or Multi-cloud setups: PBAC can serve as an abstraction layer – companies can define one set of policies and enforce them across different platforms (on-prem apps, cloud services, etc.) by using adapters. If you have heterogeneous systems, a PBAC approach prevents each system from having siloed role models.
- One concrete example is software-defined networking or Zero Trust Network Access (ZTNA): policies define who can access what application under which conditions. Many ZTNA solutions effectively implement PBAC (with user, device, and environment attributes).
In summary, PBAC is best where an organization seeks strategic, centralized control over authorization logic, often spanning multiple applications. It might be less beneficial in a very small company or a single application scenario (where coding the checks directly might be simpler). But as soon as you have a growing number of services and compliance requirements, PBAC pays off. Note that PBAC is not really industry-specific – it’s more about the architecture of your systems. However, industries like banking or government, which have complex rules and need transparency, are naturally drawn to policy-based approaches (often adopting ABAC/PBAC solutions such as Axiomatics or NextLabs for fine-grained authorization).
5.6 Relationship-Based Access Control (ReBAC):
ReBAC is optimal in scenarios where access is naturally determined by relationships or graph structures. Key environments include:
- Social Networks and Collaboration Platforms: This is the classic case – on platforms like Facebook, Google Drive, or GitHub, access to content is often based on who you are connected to. For example, Google Drive’s sharing model (owner, specific people, members of a domain) and GitHub’s org/team repositories are fundamentally relationship-driven. ReBAC can elegantly handle “Alice shared file with Bob” as a direct relation or “Bob can edit repo X because he’s in Team Y which has maintainership on repo X”. Implementing these with pure RBAC would be extremely clunky (imagine roles for every sharing combo) and with pure ABAC would require per-object attributes that mirror relationships (which doesn’t scale well) [70].
- Enterprise with Hierarchical Data or Teams: Even within a company, ReBAC can be useful. For instance, in a project-based organization, you might give access to resources based on project membership. You could model that with roles (a role per project), but if projects are numerous and short-lived, roles explode. A ReBAC approach of maintaining a project membership graph could be cleaner. Another example: customer support systems where an agent can see tickets if they are assigned to the same account/team as the ticket owner – that’s naturally a relationship rule.
- Content Management Systems and Publish/Subscribe: Where you have nested content (folders, documents, sub-folders), ReBAC’s hierarchy handling is beneficial. Many document management systems use a group/ACL approach that is essentially ReBAC under the hood (with “is member of group that owns folder” relationships).
- Education or Multi-organization platforms: University systems where instructors, students, TAs have access based on class enrolment relationships; or SaaS apps serving many companies where users belong to organizations and those org structures govern access. ReBAC naturally partitions access by organization and role within organization (similar to multi-tenant but focusing on org charts and groupings).
ReBAC might not be necessary for systems that don’t have complex relationships. If all you need is role and a couple of attributes, ABAC can suffice. ReBAC is also relatively new in commercial products, so using it might require adopting newer technologies (like an open-source authorization service) or building custom logic; thus, organizations with less tolerance for novel tech might stick to ABAC/RBAC unless they clearly need ReBAC. In terms of industry, tech companies (especially those building platforms or services used by many users or organizations) are the main adopters so far. We’re seeing the cloud-native authorization trend embracing ReBAC for its efficiency in certain queries (e.g. “list all users who can access this resource” is easy to answer if you store relationship edges). Overall, ReBAC fits best where relationships ARE the policy. If your domain can say sentences like “X can access Y because X is related to Y (directly or via some chain) in this way,” that’s a hint ReBAC is appropriate.
5.7 Risk-Adaptive Access Control (RAdAC):
RAdAC (or generally, risk-based control) is most valuable in highly sensitive and dynamic security environments. Use cases include:
- Military and Emergency Response: Imagine a crisis where an analyst who normally isn’t authorized to see certain intel needs to access it to respond to a threat. A RAdAC system could allow it because the operational need (crisis response) outweighs risk at that moment – and log it for review. Conversely, in normal times that access would be denied to maintain security. Agencies like the DoD envisioned RAdAC to handle such scenarios of “break-glass” access under controlled conditions.
- Financial Fraud Prevention: Financial institutions might employ risk-based rules for transactions – e.g., if a transaction is unusual (high amount, new beneficiary, foreign IP address for the user), the system could require additional authentication or manager approval. This is effectively RAdAC: the access to “transfer money” is conditional on a risk score. Many banks today do this in some form (you see it as “Our system flagged this as high risk, so additional steps are required”).
- Zero Trust Architecture in Corporate IT: Zero Trust principles encourage continuous verification and adaptive trust. Implementations of Zero Trust often use risk/adaptive access – for instance, if a user’s device goes out-of-compliance or their network location changes, the system might downgrade their access or re-prompt for credentials. Products in identity and security (like conditional access in Azure AD, or identity threat detection tools) are effectively using RAdAC logic behind the scenes. They evaluate risk signals (device health, user behaviour anomalies) and adjust what the user can do (maybe block downloading sensitive data if risk is high).
- Healthcare emergency access: In hospitals, there are “break glass” scenarios where a doctor might need to access any patient record in a life-threatening situation, even if normally restricted. RAdAC can allow an override with proper justification when risk to patient life (operational need) is high, while logging and later reviewing it. This is a controlled way to handle exceptions without leaving the system completely open.
Environments that don’t benefit much from RAdAC are those where the access rules are straightforward and the cost of implementing risk engines isn’t justified. It adds complexity – you need to quantify risk and define policies for how to react to different risk levels, which can be non-trivial. Many organizations may find a simpler ABAC policy (like “no access from outside office network”) sufficient, rather than continuously scoring risk. Thus, RAdAC tends to be used in organizations with mature security operations, rich telemetry, and where the balance of sharing vs. security is a constant concern. Government and large enterprises in finance/tech are early adopters of these ideas, often integrating them into an ABAC system (NIST’s vision was that RAdAC builds on ABAC by adding risk attributes [71]). We can expect as threat environments get more complex, more organizations (even medium businesses) will lean on risk-based adjustments as part of a broader Zero Trust strategy.
In practice, many real-world systems combine models to leverage the best fit for different parts of the environment. For example, a cloud service might use RBAC for basic role assignments, ABAC for adding context conditions to certain sensitive actions, ReBAC for handling sharing and collaboration features, and risk-based rules to adjust on anomalies. Each model finds its niche: RBAC for broad strokes, ABAC for detail and context, ReBAC for structure, and RAdAC for adaptivity. Knowing where each fits helps architects design an authorization system that is both secure and aligned with business needs.
6 Support by Standards, Best Practices, and Software Implementations
Over the years, various standards and best practices have emerged to support these models, and software vendors have implemented them to different degrees:
6.1 RBAC Standards and Implementations:
RBAC is one of the best-standardized models. The ANSI INCITS 359-2004 standard (and later ISO/IEC -ratified versions) defined RBAC’s core and hierarchical models [72]. NIST published a unified RBAC model as well, which became a foundation for many implementations. RBAC’s concepts of roles, role hierarchies, constraints (like separation of duty) are well-understood and supported. Best practices for RBAC (per NIST and industry guidance) include role mining (discovering roles from existing permissions), the principle of least privilege, and periodic access reviews by role. Software support: Virtually all enterprise IAM systems and authorization products support RBAC. For example:
- Databases and OS: SQL servers have role-based privileges, Unix/Linux have group IDs (a primitive form of RBAC).
- Directory services: Active Directory and LDAP support roles/groups; AD in particular popularized RBAC in corporate networks (with groups controlling access to resources).
- Applications: ERP systems (like SAP) have extensive role-based authorization concepts; cloud platforms (Azure, AWS, GCP) all have built-in RBAC for controlling cloud resource access (Azure RBAC, etc. where you assign predefined or custom roles to users/service principals) [73].
- IAM products: Almost every vendor (Oracle, IBM, SailPoint, Okta, etc.) provides role management features. There are also open-source projects for RBAC in apps (e.g. Apache Shiro, RBAC frameworks in web programming languages).
- RBAC is considered a mature technology – it’s well supported by standards like NIST RBAC and widespread in practice [74]. Admins are familiar with it, and tools for role engineering exist. One challenge noted in practice is role explosion and maintenance, which is why standards bodies like NIST have also provided guidance on combining roles with attributes.
6.2 ABAC Standards and Implementations:
ABAC, being more recent, had to catch up in standardization. NIST Special Publication 800-162 (2014) provides a formal definition and considerations for ABAC [75]. It describes the architecture (PAP, PDP, PEP, PIP – Policy Administration/Decision/Enforcement/Information Points) [76] which has become a reference model for implementing ABAC systems. The biggest open standard for ABAC is OASIS XACML (eXtensible Access Control Markup Language). XACML (v2 in 2005, v3 in 2013) defines an XML-based policy language and a reference architecture that maps to NIST’s ABAC concepts. It was an attempt to standardize how to write and evaluate attribute-based policies across different systems. However, XACML’s adoption has been mixed – it is powerful but perceived as complex, and as one source notes, it “hasn’t seen widespread adoption” [77] outside certain circles.
- In terms of best practices, organizations implementing ABAC are advised to develop a clear attribute taxonomy (defining what attributes exist and authoritative sources), manage attribute trust (since decisions are only as good as the attribute data), and start with small scoped policies to avoid an unmanageable policy base [78], [79]. Tools and frameworks are crucial for ABAC because writing raw policies can become complicated.
- Software support: A number of commercial products specialize in ABAC/PBAC. Axiomatics, NextLabs, IBM Security Guardium (for data), SailPoint and others offer policy engines or ABAC platforms that integrate with applications. These often support XACML or their own policy languages. On the open-source side, Open Policy Agent (OPA) has gained popularity as a general policy engine for cloud-native environments – OPA’s language (Rego) isn’t XACML, but it serves the same purpose (attribute-based policy decisions) [80]. Another emerging tool is AWS Cedar, an open policy language used by Amazon’s Access Analyzer – it’s a purpose-built ABAC language with a simpler syntax, aiming to be developer-friendly [81]. Standard protocols like OAuth and OIDC also indirectly support ABAC: they carry user attributes (claims) that applications can use in policies (hence “claims-based access control” as a synonym). For example, OIDC ID tokens might include roles or group claims which an app can treat as attributes for decisions. While not a full ABAC solution, this is a standard way to convey attribute information. SAML is another standard that passes attributes about a user upon login, often consumed by ABAC policies in the target app.
- ABAC is increasingly supported in cloud platforms: AWS IAM allows defining conditions in JSON policies (attributes like user tags, resource tags, IP addresses, etc.); Azure AD has Conditional Access policies (attribute/risk-based conditions for granting access to apps). Even Kubernetes supports ABAC mode for API server authorization (though RBAC mode is more commonly used). The support is there, but organizations must design their attribute model. To foster interoperability, there’s interest in standards like ALFA (Abbreviated Language for Authorization) or the OASIS Adaptable Access Control standard efforts, but none have taken off like XACML attempted. In practice, many are turning to “policy-as-code” frameworks (OPA, Cedar, Casbin, etc.), which are not formal standards but open-source implementations that follow best practices.
6.3 ReBAC Standards and Implementations:
ReBAC is still an emerging area, and as such, it lacks a formal standards body specification akin to XACML. Instead, what we have are de-facto standards coming from industry implementations. Google’s Zanzibar paper (2019) essentially set a model for how to do ReBAC at scale, and now we see convergence around similar approaches. The Zanzibar model defines a namespace of object types and relations, and a graph of tuples like (subject, relation, object). Projects like OpenFGA (by Auth0/Microsoft) provide an open API that implements Zanzibar’s approach [82]. There is also SpiceDB (by AuthZed) which is a database implementing Zanzibar-like semantics, and it introduced a schema definition language for relations. Oso, Ory Keto, Warrant, Permify – all are tools that implement relationship checks with slight differences. An early academic formalism for ReBAC exists (Carrie Gates and others proposed models for relationship-based authorization in social networks), but no single standard.
- Best practices: Because ReBAC often involves complex graphs, a best practice is to model your relationships carefully – e.g., avoid overly generic relationships that could become ambiguous, and use hierarchical relations where possible. It’s also important to manage the performance of queries – best practices from graph databases (like indexing certain relations, limiting traversal depth) apply. Another practice is to incorporate caching for frequent authorization checks, given that graph queries can be heavy; Zanzibar, for example, caches computed “authZ decisions” and updates them on relationship changes.
- Software support: As mentioned, open-source and cloud solutions are on the rise. OpenFGA has an API and a modelling language (based on Zanzibar) to define relations and authorization models. Auth0 Fine-Grained Authorization (FGA, now part of Azure AD likely) is a service based on that. There’s also movement in standards: the OpenID Foundation has a working group on Access Control which might result in some standard API for authorization (though it’s early). Traditional IAM vendors are beginning to incorporate ReBAC concepts; for instance, Neo4j (a graph database) collaborated with some IAM projects to demonstrate graph-based access control for enterprises. But we’re in early days – likely, ReBAC will get more standardized as adoption grows. Perhaps an RFC or an OASIS spec could come, but for now companies rely on the open-source projects as the “standard.” Cloud providers have partial ReBAC: e.g., AWS Identity & Access Management is largely role/policy-based, but AWS Resource Access Manager for sharing resources is relationship-based (you create a resource share with specific accounts – essentially that’s a relation). GitHub’s team and repo permissions are a custom ReBAC implementation. As for formal standards, none from ISO/NIST specifically target ReBAC yet, though NIST is certainly aware of the model in research contexts. We might see guidance from NIST in the future as ReBAC becomes more common in federal systems (especially as Zero Trust pushes for attribute and relationship considerations).
6.4 PBAC Standards and Implementations:
Since PBAC is often equated with ABAC, most standards are shared. However, one could say that policy languages are the key here. For example, Rego (OPA’s language) and Cedar and XACML are effectively standards or at least widely-recognized formats for writing policies (Cedar is not an open standard, but AWS has open-sourced its spec).
- Best practices for PBAC involve policy lifecycle management: using version control for policies (treat them like code), testing policies (with unit tests for authorization rules), and separating duties (so that those writing policies can be non-developers, but with governance oversight). The benefit of PBAC is making authorization logic visible and centralized, so practices around change management and review are recommended (e.g., a Policy Review Board in a large enterprise to approve changes).
- Implementations of PBAC are essentially the policy engines that enforce ABAC. So OPA, Axiomatics, etc., all fall here. A specific concept under PBAC is claims-based (popular in Microsoft’s world with Active Directory Federated Services and SharePoint implementing claims authorization). Microsoft’s approach was that after authentication, the user token carries claims (attributes) and then resource systems have authorization rules (written in a simple policy language) evaluating those claims. That’s PBAC in practice and had good adoption in .NET enterprise environments. Another implementation angle is low-code/no-code policy editors – some IAM products provide UI to author policies (especially for business-oriented rules like “Only HR can see personal data” – presented in dropdowns rather than code). These tools aim to implement PBAC such that even non-technical staff can manage access rules in a controlled manner, aligning with business policies.
6.5 RAdAC Standards and Implementations:
RAdAC as a concept appears in some government documents (e.g., CNSSI 4009, and drafts from NIST [83], [84], but it’s not a full standard with protocols – it’s more of a framework idea. NIST’s publications on ABAC acknowledge RAdAC as an extension where risk and need are attributes to consider [85]. Implementing RAdAC typically involves integrating risk engines or scoring systems with your access control.
- Best practices here are still developing, but generally include: defining what risk means for your organization (e.g., a numeric score or levels like low/medium/high), determining thresholds at which to alter access, and ensuring you have telemetry (logging, UEBA – User and Entity Behaviour Analytics – feeds, etc.) to feed into risk determination.
- Implementations often piggyback on existing ABAC/PBAC systems. For example, an ABAC policy might call out to a risk service that returns a score for the current context, and then the policy says “allow if score < 7” etc. Some authentication systems (like Azure Conditional Access, Okta Adaptive MFA) include risk assessment – they might not call it RAdAC but effectively do it for login decisions. For authorization, products are fewer, but we see CASBs (Cloud Access Security Brokers) and Zero Trust Network solutions implement session-level risk assessments (e.g., if a user’s behaviour is risky, the CASB will block downloading a file even if normally allowed). Another example: Google BeyondCorp (their zero-trust model) – it continuously calculates device and user trust and can adjust access to corporate apps accordingly. There isn’t a single off-the-shelf “RAdAC server,” but pieces of the capability exist in SIEMs, IAM, and security policy tools. We might anticipate standards emerging around sharing risk information (for example, CAPEC and ATT&CK share threat intel standards, but for risk-adaptive auth, maybe SCIM could carry risk attributes between systems in the future).
- Overall, RAdAC is supported more by best practice frameworks (like NIST’s Zero Trust guidance advises using dynamic risk-based policies) than by product standards. It’s an evolving area where implementation maturity varies. The concept is certainly being adopted in practice – for instance, many identity providers now have some form of “adaptive access policies,” and the smarter authorization engines allow custom logic where you can plug in risk scores.
In summary, RBAC and DAC/MAC are very well supported by existing standards and products, reflecting decades of use. ABAC/PBAC has standards (NIST, XACML) and growing support, especially aided by modern policy-as-code tools which make it easier to adopt without needing the heavy XML-based stack of old. ReBAC is newer and lacks formal standards, but open-source implementations are effectively setting a standard by usage, and big players (like Google, Auth0, etc.) have provided reference architectures. RAdAC is more conceptual, with guidance from NIST/CNSS but no universal implementation – yet its principles are influencing product features under the umbrella of “adaptive” or “contextual” access control.
Adhering to standards and best practices typically means better interoperability and security assurance. For example, using a standard like XACML or OPA for ABAC ensures you’re not locked to a single vendor and that you follow a vetted model of PDP/PEP separation. Using RBAC standards means you can align with compliance requirements (like using role-based entitlements for SOX compliance reviews). As access control models advance, we’re likely to see convergence in tooling – e.g., one platform that can enforce RBAC + ABAC + ReBAC as needed. In fact, the OASIS XACML standard was touted to support RBAC, ABAC, DAC, MAC, all within its policy framework [86], though in practice organizations often choose simpler subsets or hybrids.
7 Outlook: Are We at the End of the Road, or Are New Developments on the Horizon?
Access control models have continually evolved over the last few decades, and they are still evolving today. The question is whether we have reached a point where no fundamentally new models are expected, or if there are promising developments on the horizon. Here’s the outlook:
7.1 Convergence and Hybrid Models:
Rather than entirely new “XYZAC” models emerging, the trend is toward combining the existing models in intelligent ways. The realization in both academia and industry is that each model (RBAC, ABAC, ReBAC, etc.) is like a tool in a toolbox, and a robust access control system often uses multiple tools. As one blog concluded, sticking to one pure model will “limit expressive power” – the future lies in deciding how much of each model to use to serve our needs [87]. We already see products that allow, say, defining roles (RBAC) but also attaching attribute conditions to those roles (RBAC + ABAC, sometimes called role-centric ABAC [88]). Many IAM systems now support this out of the box (e.g., attribute-driven role assignment or roles with dynamic constraints). We can expect this blending to become more seamless. For example, a policy service might let you use role membership, attributes, and relationships all in one policy language – some newer policy languages (like Cedar) and engines (like SpiceDB + OPA integrations) are heading this way. The outlook is a unified policy model that can express roles, attributes, relationships, and risk in a single coherent framework (sometimes dubbed “Next-Generation Authorization” or simply fine-grained authorization). This isn’t a brand-new model with a new acronym, but a unification and refinement of what we have.
7.2 Increased Emphasis on Context and Continuous Enforcement:
In line with Zero Trust security, “verify every access, every time,” we’ll see more systems doing continuous, context-aware authorization. This means even after a user is initially allowed access, the system might re-evaluate policies when context changes (user moves network, time window expired, anomaly detected, etc.). This outlook extends the RAdAC concept. We might not call it a separate model, since it’s essentially ABAC with time-varying context and risk inputs, but it represents a mode of operation that is becoming standard. NIST’s Zero Trust Architecture (SP 800-207) explicitly calls for policy engines that consider context on a per-request basis. So, the future is not a static one-time check but ongoing authorization decisions. This could give rise to new standards for sharing context info in real-time between systems (for example, protocols that inform an app that a user’s device posture changed and therefore the app should re-check authorization). We can view this as pushing ABAC to its logical extreme – everything is an attribute that can change anytime, and policies must adapt immediately.
7.3 Scalability and Performance Innovations:
As organizations manage ever-more identities (think IoT with millions of devices, or cloud with thousands of services), access control must scale. ReBAC’s popularity in tech is partly because it scales well for certain large-scale patterns, and we see graph-based approaches likely becoming more mainstream. The outlook here includes optimization techniques (caching, indexing, distributed PDPs) and perhaps even specialized hardware or algorithms for policy evaluation. For example, there is research on using logic inference engines or AI techniques to optimize authorization decisions without evaluating every rule every time. While not a new model per se, these improvements will make existing models more viable at extreme scale. We might also see integration of cryptographic approaches for distributed trust – e.g., attribute-based encryption (ABE) or capabilities via blockchain for cross-organization access. Those introduce concepts of keys and cryptographic credentials as part of access control (as a complement to policy models).
7.4 Standardization of Newer Models:
We anticipate that standards bodies will address ReBAC and improved ABAC. For instance, the OpenID Foundation or OASIS may propose a standard API or language for Relationship-based access akin to how XACML did for attributes. This could greatly boost multi-vendor support. Similarly, as PBAC (policy-as-code) becomes common, there may be standards for policy interoperability – so you could export a policy from one engine and import to another. Efforts like the Google Zanzibar schema being open-sourced might evolve into a standard. The industry is rallying around some common paradigms (the Zanzibar model for ReBAC, the OPA/Cedar approach for ABAC), which is promising for eventual consensus.
7.5 Theoretical Developments:
On the academic front, researchers continue to analyse and extend models. The “From ABAC to ZBAC” report by HP Labs hinted at a model named ZBAC [89] – the last letter of the alphabet implying the furthest evolution. While ZBAC is not a defined model in practice, the term has been used informally to suggest the ultimate access control model that might incorporate all dimensions (attributes, relationships, contexts) and perhaps new ones. One could speculate that future models might integrate user behaviour or intent more directly (e.g., authorizations that depend on what the user is trying to achieve – a very high-level concept). Another area is automated policy learning: could machine learning suggest or adjust access policies based on patterns (creating a sort of adaptive model that isn’t explicitly coded by humans)? This is experimental, but as AI advances, it might assist rather than fully replace models – e.g., suggest ABAC rules by analysing access logs.
7.6 Not End of the Road:
Far from being at the end of the road, access control is becoming even more critical with trends like cloud, IoT, and remote work. Each of those trends introduces new challenges: e.g., IoT devices might need capability-like models for constrained environments; remote work in zero trust requires constant policy evaluation; data sharing across organizations needs federated access control (where policies span multiple domains). We’re likely to see refinements of models to handle federation (how do you enforce policies consistently when User A from Company X accesses data at Company Y? – possibly by standardizing attribute and relationship assertions across domains). Initiatives like User-Managed Access (UMA) from OAuth, or cross-cloud access standards, touch on this but there’s room for growth.
7.7 In conclusion, …
We are not at a dead end with access models. Instead, the field is moving toward more dynamic, fine-grained, and intelligent access control. The core theoretical building blocks (roles, attributes, relationships, risk) are well-established – it’s unlikely a completely unheard-of factor will come (like some new fundamental unit of policy). What’s promising is how these concepts are being recombined and applied: graph-based implementations, policy-as-code, continuous authorization, and AI assistance all point to a future where access control is more adaptive and easier to manage at scale. The outlook is that in a few years, organizations won’t talk about choosing RBAC or ABAC or ReBAC – they’ll leverage “policy-based access control” in the broadest sense, using roles, attributes, relationships, and risk as needed under one roof.
The evolution of access control is therefore ongoing. Just as we went from MAC & DAC to RBAC to ABAC, now to ReBAC and adaptive policies, the next phase will likely be platforms that seamlessly integrate these models and perhaps new approaches to handle emerging needs (like privacy-preserving access control, where even the act of authorization doesn’t reveal unnecessary info). By adhering to open standards and contributing to these evolving frameworks, industries are shaping a future where access control is both highly secure and business-flexible – truly achieving the “best of all worlds” that early visionaries hoped for [90].
