Access Control Models

Access control models form the foundation of information security, defining how organizations protect their resources. While access control might seem straightforward — determining who can access what — there are many ways to solve the same problem. Each access control model offers different approaches to these challenges.

This guide explains the core models and provides real world examples — to help you whether you're studying for security certifications, designing an access control system, or trying to understand your organization's security architecture. Rather than advocating for any particular approach, this guide aims to help you understand the options available and their tradeoffs.

Core access control models

In more complex organizations, a single access control model often won't cut it — you have different needs for how you protect different kinds of resources, and so you'll mix and match models. Instead of thinking of the tradeoffs between one model and another, it can instead be helpful to understand how they relate to each other, including how they can complement one another. The core models of discretionary, mandatory, role-based, and attribute-based access controls cover the more traditional methods for handling permissions.

Discretionary Access Control (DAC)

With discretionary access control, every resource needs an owner, and that resource owner decides who gets access to a resource, and with what permissions. This puts control in the hands of resource owners rather than centralizing access controls. This model makes sense where permissions are easy for resource owners to understand and manage, and there is no better authority — such as if resources don't all belong to the same organization. For example, it may make sense for a resource owner to control access to documents they create, but it may not make sense for an individual to control permissions for more widely used resources with stricter availability and security requirements. However, as an organization grows, permissions tend to become fragmented, with no centralized visibility into who has access to what, and inconsistent permissions across similar resources. In addition to handling frequent access changes for when individuals join or leave an organization, when a resource owner leaves, the management of their resources needs to be handed over to someone else.

Examples

• Unix files where file owners can set read, write, and execute permissions
• Shared document folders like Google Docs, where document owners manage access, such as adding editors and viewers
• Source code repositories like GitHub, where maintainers manage contributor access
• Social media like Instagram, where creators can decide to allow only their friends or everyone to view their content

Mandatory Access Control (MAC)

With mandatory access control, the system makes access control decisions based on centrally managed labels which are applied to both users and resources. For example, only users that have the Top Secret clearance can access resources classified as Top Secret. Labels can be in a hierarchical structure, known as a lattice, and shared upwards or downwards that hierarchy. For example, if a "read down" model is used, a user with the Top Secret clearance can see any resources that are less sensitive, such as those marked Secret.

A data classification authority decides how to label resources, so that newly added resources need to follow the appropriate classification policy.

The primary downsides of MAC are the administrative overhead of accurately classifying resources and maintaining labels.

Examples

• Government or military systems handling information with different levels of classification, such as the US government's Confidential, Secret, and Top Secret classifications

Role-Based Access Control (RBAC)

With role-based access control, organizations create roles that are granted permissions, and users inherit the permissions of roles they have. Typically, this is tied to a department (e.g., Legal) or position (e.g., Manager). Pain points with RBAC occur with maintaining roles and role membership. It becomes difficult to express a cross-product of attributes, for example all employees in the United States rather than all employees globally, or all full time employees rather than all employees including part time employees and interns. It's also difficult to express permissions for cross-functional roles, but if there are too many specialized roles, then they become hard to maintain, as groups explode exponentially.

Examples

• App assignments in an identity provider, where Sales Account Executives have access to Salesforce, but Software Engineers do not
• Auditor roles in cloud configuration tools, where auditors have read-only permissions to perform an audit, whereas DevOps engineers have read-write permissions

Attribute-Based Access Control (ABAC)

In attribute-based access control, access control decisions are based on one or multiple attributes of the user, resource, or environment. ABAC extends beyond RBAC by considering multiple attributes for access decisions, instead of a single attribute of role.

Complex attribute combinations can be difficult to understand, leading to unintended access; and can also be expensive to compute, leading to potential performance impact.

Examples

• Office buildings, accessible based on desk assignment
• Purchasing restricted items like alcohol or cigarettes, allowed based on age

Differences in RBAC and ABAC

RBAC and ABAC are two of the most widely used access models, so it's worth considering how they compare and when to use each model.

Many organizations implement RBAC as a foundation for basic access control, then add ABAC capabilities for specific use cases requiring more dynamic or granular control. This hybrid approach combines RBAC's simplicity for common scenarios with ABAC's flexibility for complex requirements.

Additional access control models

Rule-Based Access Control (RuBAC)

Rule-based access control determines access based on predefined rules, often taking into account environmental conditions like time or location.

RBAC and ABAC are also examples of RuBAC: RBAC has a rule that access is allowed based on a user's role, and ABAC has a rule that access is allowed based on one or more attributes.

Examples

• Trading systems, that only allow trades during market hours from 9:30 a.m. to 4:00 p.m. ET on weekdays
• Firewall rules, that only allow explicitly allowlisted IP ranges

Risk-Based Access Control

Risk-based access control determines access based on dynamic attributes, which reflect changes to the risk profile of the access. Risk-based access control is focused on environment attributes like device trust level, user location, and time — this is the foundation of zero trust security models. This may also be called context-based access control (CBAC) or risk-adaptive access control (RAdAC).

Examples

• Corporate email, which requires stronger authentication when accessed from a non-corporate device, or from a different country
• Your bank, which requires a text or phone call for authorization before submitting a high-value transaction like a wire transfer

Note

The distinction between attribute-based and risk-based access control has become increasingly blurred as modern ABAC implementations routinely include contextual factors. You might see risk-based access discussed as:

• A standalone model in older systems
• A specific implementation of ABAC principles
• A complementary system focusing on environmental risk

Many examples of risk-based access control are based on environment risk, such as device attributes. This makes access control models even harder to reason about, since a device is not always explicitly tied to an individual.

Content-Based Access Control

Content-based access control determines access based on resource content. This is often implemented using Data Loss Prevention (DLP), to identify and apply controls based on the type of data in a resource.

Examples

• Email systems blocking outgoing messages containing sensitive data such as credit card numbers
• Source code management systems like GitHub blocking commits that contain secrets like API keys

Task-Based Access Control

Task-based access control grants temporary access based on the requirements of the specific task being performed. This is often self-serve, so that a user can invoke the access they require based on their workflow. This might be implemented with privileged access management (PAM), which temporarily grants a user more powerful permissions; or with just-in-time (JIT) access, which both provisions and grants the more powerful permissions to the user.

Examples

• Engineers getting access to sensitive monitoring and debugging tools only when they are on call
• Support tickets granting agents access to customer data only while the ticket is open

Even more access control models

These more modern models have emerged in the last few years. They're not part of CISSP material.

Policy-Based Access Control (RuBAC)

Policy-based access control enforces access through centrally managed policies that can combine multiple factors, including roles, attributes, and context. Unlike ABAC, which makes access decisions at a resource level, PBAC evaluates combinations of conditions, typically using a policy language, to make access decisions across multiple systems. This typically requires a dedicated policy engine.

PBAC focuses on expressing complex policies in a standardized, manageable way. These can support complex conditional logic, and since these policies are centralized, allow for policy reuse that might otherwise have been difficult to manage in a disjoint way.

Like with ABAC, PBAC can be difficult to manage at scale if there is a sprawl of policies, making access difficult to understand and expensive to compute.

Examples

• Cloud platforms where policies define allowed actions across multiple services

Relationship-Based Access Control (ReBAC)

In relationship-based access control, access is granted based on the relationships between users or between users and resources. This model is particularly relevant for social networks and collaborative systems. The complexity of relationship data may be difficult to maintain, and make it hard to audit access via indirect paths.

Examples

• Social network allowing access to content based on friendship distance, such as sharing with friends of friends

Takeaways

Access control isn't about choosing the "right" model — it's about understanding a set of different approaches you might use and the tradeoffs each model presents in order to meet the requirements of your environment. These models offer a shared language to help you discuss and define what you're trying to implement.

While RBAC remains the foundation for many organizations due to its balance of usability and security, the trend toward dynamic, context-aware access controls reflects organizations' increasingly complex security requirements. Most organizations need a combination of access control models — there's not a single perfect model that fits all requirements. Start simple, then add sophistication as your needs evolve and capabilities mature.

As you evaluate these models, focus on finding the right balance between security, usability, and administrative overhead for your specific needs.