What Are the Different Types of Access Control?

Written by Kate Lake on February 17, 2022

Share This Article

While access control via physical barriers, like locked doors, may still have a place in the workplace, the rise of remote and hybrid work revealed the criticality of access control for protecting digital and cloud-based assets. Strong digital access controls are now vital to ensuring security in a work-from-anywhere environment. 

However, access control is not one-size-fits-all; company size, function, existing infrastructure, and other factors influence how businesses should control resource access. In this article, we’ll outline the most common access control methodologies and explore the advantages and drawbacks of each. Check out this access control case study for even more information.

Quick Definitions

Before diving into different types of access control, let’s define a few terms and acronyms you’ll see throughout this article.

  • Access control: Access control defines the schemas that prescribe how subjects can interact with objects in your IT architecture. Organizations can — and often do — use different types of access control in different environments.
  • Subjects are the entities that do the accessing — like users and applications.
  • Objects are the entities that receive access — like networks and files.
  • DAC: Discretionary access control 
  • MAC: Mandatory access control
  • RuBAC: Rule-based access control
  • RBAC: Role-based access control
  • ABAC: Attribute-based access control 

Discretionary Access Control 

People working on individual laptops.

Discretionary access control (DAC) assigns privileges based on rules specified by users. Most file systems default to DAC by assigning access control to file creators, who can then assign access parameters to others. Typically, they maintain full control over these settings and can change them at any time. Note that DAC systems usually have a super admin role that can supersede a user’s ownership.

Discretionary Access Control Example

Windows and macOS file systems default to DAC: the user is automatically assigned ownership when they create a file, allowing them to view, edit, and share the file at their discretion.

Discretionary Access Control Benefits 

  • Flexibility. DAC is flexible, as it allows users to set access parameters for each resource. Resource-by-resource access assignment leaves room for flexible roles or a lack of formal roles. This makes DAC well-suited to small companies without consistent, established processes and where users wear many hats. 
  • Decreased IT burden. Allowing users to set access parameters for resources removes the burden of doing so from IT. With IT teams often stretched thin, DAC can be a welcome supplement, especially for low-risk resources (like user-generated text documents) that don’t require high-security controls. 

Discretionary Access Control Drawbacks

While taking the burden off of IT can be helpful to IT teams in the short-run, this lack of centralized management can generate problems down the road. If IT ever does decide to change access control approach or needs to centralize resources, they will likely have a hard time doing so when users have generated and assigned access ad hoc.

  • Increased user burden. Because DAC places access control assignment on the user, they experience additional friction when creating and sharing resources. 
  • Poor resource management. DAC’s lack of consistency also complicates resource management, as it doesn’t work with a central source of truth that tracks all resources (like a cloud directory platform does). This makes onboarding and offboarding difficult, as access would need to be given and revoked manually, per resource. This can become a security problem if employees are accidentally allowed to keep access to resources after leaving the organization. It also allows for the possibility that an employee may be the sole owner of a resource and its access rights, rendering it inaccessible if they are absent or leave the organization. 
  • Inability to scale. Because DAC requires users to manually apply controls per individual resource, it is not suited to high-volume resource creation. This can be a hindrance to users upon project creation, for example. Further, adding or removing users from the environment can complicate assigned access. Granting one new employee access to all the resources they need (which might be owned by different people) could be a time-consuming and convoluted process from the start; doing so for an entire new team could present significant challenges.
  • Lack of security. DAC doesn’t enforce access control standards, and it allows users to change access parameters on a per-resource basis — both of which almost guarantee inconsistency, and, subsequently, insecurity. Placing access control in users’ hands implicitly trusts every user, which can create vulnerabilities. 

Environments where users can share data at will, without supervision, are particularly susceptible to ransomware. Further, user-driven access also obscures central visibility and control, which prevents IT administrators from managing all of the organization’s resources and poses additional security risks, as IT admins cannot mitigate threats to resources they don’t know about or can’t access.  

Mandatory Access Control 

Mandatory access control is common in government and military organizations.

With mandatory access control (MAC), the operating system enforces access permissions and restrictions, which are created by a system administrator and based on hierarchical security levels. System administrators configure access rules by assigning security levels to both subjects and objects, and subjects can access anything equal to or lower than their assigned security level in accordance with the prescribed hierarchy. 

Mandatory Access Control Example

MAC’s format is well-suited to environments with global levels of security, like government organizations, where restrictions are based on clearance level. In such instances, a document could be assigned a “top secret” security level, and only users with top secret clearance levels would be able to access that document. 

Mandatory Access Control Benefits

  • High security and consistency. MAC restricts the user’s ability to control access policies, even for resources they create; instead, MAC keeps this capability with a centralized security or IT admin team to be enforced by the systems themselves. This keeps security and consistency high. 
  • Principle of least privilege. MAC strictly enforces the principle of least privilege (PLP), a cornerstone of Zero Trust security. In government organizations, this is often referred to as “need to know” — information is only shared with those who need to know it to complete their work. 

Mandatory Access Control Drawbacks

  • Rigid format. In fluid or frequently changing organizations that don’t have a finite number of global, static security levels, MAC can be too rigid.
  • Manual burden. With MAC, system administrators have to assign attributes to all resources and users manually. System administrators are also the only ones who can change access control settings, so they’re tasked with manually fulfilling all access requests.
  • Difficult scaling and maintenance. Because system administrators are responsible for making all access control changes, organizational changes, new hires, new projects that generate many documents, and other large-scale events put a significant burden on the IT team. To minimize this maintenance, system administrators need to keep a thorough, updated record of all resources and their permissions.

Rule-Based Access Control

Networking equipment with cables neatly tied together.
Rule-based access control is commonly used with networking equipment.

Rule-based access control (RuBAC) uses rule lists that define access parameters. RuBAC rules are global: they apply to all subjects equally. This makes them well-suited to networking equipment like firewalls and routers as well as environments that require strict global policies, like content filtering. Typically, RuBAC policies don’t allow for implicit access; instead, they usually function on an implicit deny basis, only making allowances where rules explicitly say to do so. (Note that some systems can modify these rules.) 

Rule-Based Access Control Example

A firewall might be given a list of white-listed IP addresses and only grant access to those addresses.

Rule-Based Access Control Benefits

  • Centralized security. Only system administrators can create and set rules, which helps keep the IT environment consistent and secure. 
  • Flexibility. The if-then structure of RuBAC policies makes them fairly open-ended, allowing IT administrators the flexibility to create customized and granular rules. 
  • Scope. Rules can be created around events and other criteria that extend beyond roles and attributes.

Rule-Based Access Control Drawbacks

  • Rigidity. While RuBAC policies are open-ended and wide in scope, their strict adherence to rule lists fails to account for business logic and nuance. This makes RuBAC environments less dynamic than attribute-based access control (ABAC) environments.
  • Lack of security. This lack of dynamic policies can create security gaps. For reliable security, systems need the intelligence to detect abnormal activity based on more than a list of rules. While RuBAC can be an advantageous security supplement, the nuances of role-based and attribute-based access control provide more complete security against modern, intelligent threats. 

Role-Based Access Control

Role-based access control schemas are often similar to organizational hierarchies.

Role-based access control (RBAC) uses roles and user groups to determine access privileges. With RBAC, system administrators assign roles to subjects and configure access permissions to apply at the role level. From there, systems can automatically grant or deny access to objects based on the subject’s role. 

With RBAC, privileges mapped to roles tend to remain static, and roles assigned to subjects tend to change more frequently. For example, people may move in and out of a managerial role, but the access privileges granted to managers tend to stay the same. In an environment without much change, this can create a successful set-it-and-forget-it access control process; in an environment where people and roles change frequently, RBAC can quickly become a headache.

Role-Based Access Control Example

A system administrator could restrict financial data access to only C-suite users and the finance team. If someone transferred from the sales department to the finance department, their role change might revoke their CRM access while granting them access to financial data.

Role-Based Access Control Benefits

  • Centralized management. Role-based security keeps access management in IT’s hands, which helps maintain consistency, security, and compliance. 
  • Intuitive policies. Although policies can become convoluted in complex environments, RBAC policies are typically derived from tangible user parameters, like a department, leadership level, or branch. This makes policy creation more intuitive.
  • Automation. Role-based access control rules can be applied automatically. This streamlines scaling and management when compared to manual methods like MAC and DAC. Further, changing access configurations can be done en masse by changing the permissions of a role, reducing policy configuration time.
  • Easy maintenance in static environments. In static environments without much personnel movement or scaling, RBAC can form a reliable foundation that automatically assigns and applies the right permissions to subjects.

Role-Based Access Control Drawbacks

  • Not suited to granular policies. Because new policies often necessitate role creation, RBAC doesn’t lend itself to granular policies. This can decrease security and process efficiency; for example, an enterprise resource planning (ERP) system might not be able to implement efficient processes without granular roles. By contrast, ABAC’s application of business logic allows for granular specificity without implications on the core identity management structure. 
  • Affects identity management structures. RBAC’s dependency on user roles means IT admins often must create or alter roles to implement access policies. This can quickly lead to a sprawling core identity management structure. The ability to nest roles further complicates this dependency and can lead to unmanaged roles and security blind spots if not properly managed. 
  • High management overhead. RBAC’s tendency to complicate identity management environments necessitates close management, especially in dynamic environments. This means IT will have to be involved with role creation and changes (which could have otherwise been left up to HR and individual departments) as well as close ongoing maintenance of roles and policies in place.   
  • Security risk. Failing to manage a role-dependent access environment can lead to decreased visibility, overallocated permissions, and a weak identity management posture — all of which generate significant risk.
  • Limited scope. As its name suggests, role-based access control is based wholly on roles. This can be limiting, as not every policy intuitively aligns with role. For instance, policies around which Wi-Fi networks users can access may not naturally align with their role in their organization. Creating new roles to account for this factor is an example of how RBAC can lead to role sprawl.

Attribute-Based Access Control

Illustration of many users and attached message bubbles.
Attribute-based access control allows for flexible and granular policy creation.

Attribute-based access control (ABAC), also known as policy-based access control, is similar to role-based access control, except that it uses the more broad and flexible attribute rather than role to form policy rules. While a user may be assigned one or two roles — like remote worker and admin in a typical role-driven identity management structure, they could be assigned essentially limitless attributes to define and qualify their access parameters. These attributes would not have to influence their position in the organization’s identity management structure.

ABAC evaluates attributes at the time of the attempted login. Because attributes can span a wide array of information, this allows ABAC policies to account for context and real-time information, like the user’s location at the time of login. 

Overall, ABAC facilitates complex rules that allow IT admins to create contextual and strategic policies. This makes it a great candidate for disparate and highly variable cloud environments. 

Attribute-Based Access Control Example

Attributes can be created to define the scope of someone’s access, like office branch to inform someone’s badge access and Wi-Fi permissions. Attributes could also be created to carry over integration information — e.g., JumpCloud makes users’ AWS role names an attribute as part of its SSO integration with AWS to carry this information over.

In addition, conditional access policies are often attribute based: e.g., if a user logs in from a trusted device and from a trusted geographical location, then the user may be granted access. 

Attribute-Based Access Control Benefits

  • Flexibility. ABAC allows IT admins to choose from a wide range of attributes, facilitating flexible policy creation. Attributes can also be created to indicate roles and groups in third-party software, making this access control method friendly to integrations with other identity management solutions.
  • Context. This wide range of attributes allows IT admins to account for context and nuance in policy creation, facilitating more intelligent rules driven by business logic. 
  • Easy granularity. ABAC allows IT admins to create policies independently of roles, which makes it easy to create highly specific and granular policies. Attributes don’t have to affect roles or identity management structures, which allows IT admins to create attributes with as much specificity as they need without creating contingencies or altering the identity management structure.
  • Easy management and maintenance. Because attributes can exist without larger implications on the organization’s identity management structure, they require less maintenance and upkeep. Where allowing a role to go unmonitored could lead to obscurity in the environment and overallocated access privileges, allowing an attribute to fall out of use doesn’t necessarily have strong implications on the identity management structure.
  • Efficiency. ABAC automatically applies attributes to policies using business logic, facilitating intelligent policies while still removing the burden of close manual management.
  • Security. The ability to create many custom, intelligent policies that account for people, networks, devices, and environment helps IT admins secure their organization holistically. Further, ABAC’s automatic and intelligent implementation ensures accuracy and reduces the risk of human error.
  • Well-suited to cloud and remote environments. ABAC’s ability to account for devices, networks, and environment make it an ideal choice for remote, hybrid-remote, and cloud-first environments. These environments vary widely; ABAC provides a wide range of attributes and customizability that can adequately protect them. 

Attribute-Based Access Control Drawbacks

  • Requires a strong foundation. Without a strong, centralized foundation, ABAC can be difficult to implement and control. Organizations should have a cloud directory or similar platform that manages the attributes that will drive policies (users, devices, networks, and environmental factors) to successfully implement ABAC.

Which Access Control Model Is Right for My Environment?

Businesses should look for solutions that uphold Zero Trust by applying the principle of least privilege (PLP) at every access point. This requires an access control strategy that can associate users with permission levels, which includes MAC, RuBAC, RBAC, and ABAC. 

MAC is a highly specialized strategy that applies well to government and military structures, but falls short elsewhere. RuBAC can apply PLP to an extent, but its rigid format makes it a bit less dynamic than RBAC and ABAC, and therefore less able to intelligently apply PLP. RuBAC may be sufficient for certain parts of your environment, like firewalls and email content filtering.

RBAC is common in popular market solutions. However, as the world becomes more remote and cloud-first, ABAC’s intuitive policy creation and maintenance are making it the more secure and efficient choice. ABAC’s flexibility also allows it to integrate easily with third-party platforms that use RBAC by associating roles with attributes.

To learn more about why ABAC wins out against other access control methods, check out our blog, The Immediate Benefits of Attribute-Based Access Control. 

Kate Lake

Kate Lake is a Senior Content Writer at JumpCloud, where she writes about JumpCloud’s cloud directory platform and trends in IT, technology, and security. She holds a Bachelors in Linguistics from the University of Virginia and is driven by a lifelong passion for writing and learning. When she isn't writing for JumpCloud, Kate can be found traveling, exploring the outdoors, or quoting a sci-fi movie (often all at once).

Continue Learning with our Newsletter