Role-based access control (RBAC) is an access control model that assigns permissions to roles (like "nurse" or "accountant") rather than to individual users, so a person gets access based on the job they hold inside an organization.
Role-based access control (RBAC) decides what you're allowed to do based on your role, not your name. Instead of handing permissions to each person one at a time, an admin builds roles like "HR manager" or "help desk technician" and attaches permissions to those roles. When someone joins the team, you drop them into a role and they instantly inherit everything that role can do. When they switch jobs, you swap the role.
This is the authorization half of access control. Authentication (CED Topic 4.2) proves who you are, using factors like something you know, have, or are. Authorization decides what you can touch once you're verified. RBAC is one of the major models for handling that second step. The big win is scalability and consistency: ten thousand employees become a few dozen roles, and everyone in the same role gets the same access, which kills the random one-off permissions that create security holes.
RBAC lives in Unit 4: Securing Devices, anchored to Topic 4.2 Authentication. It builds directly on the authentication objectives there. Once a system verifies identity (CED 4.2.C, determining the authentication factor used) it still has to decide what that verified user can access, and RBAC is how organizations answer that at scale. It connects to the core security goal behind EK 4.2.C.1: making sure only authorized users reach a system. RBAC enforces the principle of least privilege, giving each role only the access its job actually needs, which shrinks the damage an attacker can do if they crack one account.
Keep studying AP Cybersecurity Unit 4
Visual cheatsheet
view galleryAuthentication factors (Unit 4)
Authentication checks your identity; RBAC checks your permissions. They run back to back. You log in with a password or biometric (CED 4.2.C), then RBAC looks at your role to decide what you can open. One without the other is useless.
DAC and MAC access control models (Unit 4)
RBAC is one of a family of access control models. DAC lets the resource owner hand out permissions, MAC enforces system-wide security labels, and RBAC ties permissions to job roles. Knowing how they differ is the whole point of this corner of Unit 4.
Password attacks and least privilege (Unit 4)
EK 4.2.B.1 says a cracked password gives an attacker everything that user could access. RBAC limits that blast radius. If a compromised account only holds a low-privilege role, the attacker is boxed in instead of roaming free.
Access control lists and ACLs (Unit 4)
An ACL spells out which specific users or groups can touch a specific resource. RBAC is the cleaner, scalable cousin: instead of editing long per-resource lists, you manage a handful of roles, and the permissions flow from there.
Expect RBAC in multiple-choice stems that describe a workplace scenario and ask which access control model fits, or that contrast it with DAC, MAC, and RuBAC. A typical stem gives you a setup like "a hospital wants every nurse to have identical record access" and asks you to name the model. You should be able to define RBAC in one sentence, explain that permissions attach to roles instead of individuals, and tie it to least privilege and the authorization step that follows authentication in Topic 4.2. No released FRQ uses the exact phrase, but RBAC supports the kind of secure-configuration reasoning Unit 4 questions reward.
RBAC ties access to your job role, set centrally by an admin. DAC lets the owner of a file or resource decide who gets in, at their own discretion. RBAC is consistent and scalable; DAC is flexible but easy to misconfigure because individual owners make the calls.
Role-based access control (RBAC) assigns permissions to roles, and users get access by being placed into a role rather than by being granted permissions one at a time.
RBAC is the authorization step that follows authentication: first a system verifies who you are, then RBAC decides what you can access.
RBAC enforces least privilege, so a compromised account only exposes whatever its role could already reach.
On the exam, you'll usually distinguish RBAC from DAC, MAC, and RuBAC by matching each to a workplace scenario.
RBAC lives in Unit 4, Topic 4.2, and ties into the goal of making sure only authorized users access a system (EK 4.2.C.1).
It's an access control model where permissions are attached to job roles, like "nurse" or "accountant," and users inherit those permissions by being assigned to a role. It shows up in Unit 4, Topic 4.2, as part of how systems handle authorization.
No. Authentication proves who you are using a factor like a password or biometric. RBAC is authorization, deciding what a verified user can access. RBAC kicks in after authentication succeeds.
RBAC assigns access based on your role and is managed centrally by an admin, while DAC lets the owner of a resource decide who can access it. RBAC scales better and stays consistent; DAC is more flexible but easier to misconfigure.
Managing thousands of individual users is error-prone and creates random permissions that become security holes. RBAC collapses that into a few roles, so onboarding, role changes, and offboarding are clean and consistent.
EK 4.2.B.1 notes that a cracked password gives an attacker everything that user could access. If RBAC keeps that account in a low-privilege role, the attacker is confined to that role's narrow permissions instead of the whole system.
Connect this key term to the AP exam workflow: review the course, practice questions, and check related study tools.