RBAC (role-based access control) is an authorization model that assigns permissions to roles rather than to individual users, so people get access based on the job they do, not who they are personally.
RBAC stands for role-based access control. Instead of handing permissions to each person one by one, you build roles (like "Nurse," "Accountant," or "Help Desk") and attach permissions to those roles. Then you drop users into the right role. A new accountant inherits every "Accountant" permission the moment you assign them that role.
This is an authorization model, which is the step that comes right after authentication. Authentication (Topic 4.2) proves you are who you say you are. Authorization decides what you're allowed to touch once you're in. RBAC answers the authorization question by checking your role, not your name. That's why it scales so well in big organizations: you manage a handful of roles instead of thousands of individual accounts.
RBAC lives in Unit 4: Securing Devices, anchored to Topic 4.2 Authentication and the broader access-control conversation around it. It builds directly on the authentication mechanisms in [AP Cybersecurity 4.2.C], which cover how a system verifies a user's identity through factors. Once a user is authenticated, RBAC is one of the models that decides what they can do. It supports the core security idea behind [AP Cybersecurity 4.2.B], where compromising a single account hands an adversary all the access and rights that account has. RBAC limits the blast radius by tying access to a role's actual needs, so a stolen low-privilege account can't reach high-privilege resources.
Keep studying AP Cybersecurity Unit 4
Visual cheatsheet
view galleryDAC — Discretionary Access Control (Unit 4)
DAC lets the resource owner personally decide who gets access, which is flexible but messy at scale. RBAC takes that decision out of one owner's hands and standardizes it around job roles, so access stays consistent across the whole organization.
MAC — Mandatory Access Control (Unit 4)
MAC enforces access through system-wide security labels (like classification levels) that users can't override. RBAC is the middle ground: more structured than DAC, but tied to job function rather than rigid security clearances.
Authentication vs. Authorization (Topic 4.2)
Authentication checks identity; authorization checks permission. RBAC is purely an authorization tool, so it only kicks in after a user has already proven who they are.
ACL — Access Control List (Unit 4)
An ACL spells out which specific users or groups can do what to a specific resource. RBAC layers on top of that idea by mapping permissions to roles instead of forcing you to edit long lists for every individual.
Expect RBAC in multiple-choice stems that hand you a scenario and ask which access-control model fits. Watch for the giveaway language: "permissions assigned by job function," "a new employee inherits access by their role," or "managing access without editing each user." That's RBAC. You'll need to tell it apart from DAC, MAC, and RuBAC, since the exam loves testing whether you can match the model to the situation. No released FRQ has used RBAC verbatim, but it supports exactly the kind of "least privilege" and access-limiting reasoning that authorization questions in Unit 4 reward.
RBAC and RuBAC look almost identical as acronyms, but they're different. RBAC grants access based on a user's role or job function. RuBAC grants access based on rules and conditions the system checks (like time of day, IP address, or location) regardless of who you are. If the deciding factor is "what's your job," it's RBAC; if it's "does this request meet the rule," it's RuBAC.
RBAC stands for role-based access control, and it assigns permissions to roles rather than to individual users.
RBAC is an authorization model, meaning it controls what you can do after authentication has already confirmed who you are.
RBAC scales well because you manage a small number of roles instead of thousands of individual user permissions.
On the exam, scenario clues like "access based on job function" or "a new hire inherits permissions by role" point to RBAC.
Don't confuse RBAC (role-based) with RuBAC (rule-based), which grants access based on conditions like time or location instead of job role.
RBAC is role-based access control, an authorization model where permissions attach to roles (like "Manager" or "Technician") and users get access by being assigned a role. It shows up in Unit 4 around Topic 4.2 as one way to control what an authenticated user is allowed to do.
No. RBAC grants access based on a user's role or job function, while RuBAC (rule-based access control) grants access based on rules and conditions like time of day or location. They sound alike because of the acronyms, but the deciding factor is different.
DAC (discretionary access control) lets the resource owner personally decide who gets access, while RBAC standardizes access around defined roles so it's consistent across the whole organization. RBAC is harder to misconfigure at scale than DAC.
Authorization. Authentication (Topic 4.2) proves your identity, and RBAC only kicks in afterward to decide what your role is allowed to access.
Because it scales. Instead of editing permissions for each of thousands of users, you manage a handful of roles, which also supports least privilege by giving each role only the access its job actually needs and limiting the damage from a compromised account.
Connect this key term to the AP exam workflow: review the course, practice questions, and check related study tools.