Access control sounds simple until you have a hundred users, a dozen tenants, and a security platform that touches assets, findings, scans, reports, and integrations. At that point, granting permissions one user at a time becomes unmanageable, and it becomes unsafe. Role-based access control, almost always shortened to RBAC, exists to solve exactly this problem.
This article is a plain-language definition of RBAC for anyone evaluating or operating a security platform. It explains what RBAC is, the pieces it is built from, how permissions are modeled, and how RBAC differs from attribute-based access control (ABAC). It is a definition piece, not a configuration guide. Where the mechanics of a specific permission matrix go deeper, we link out to a dedicated walkthrough rather than repeat the detail here.
What Is Role-Based Access Control?
Role-based access control is an authorization model where permissions are assigned to roles, and users receive those permissions by being placed into a role. The user is never granted a permission directly. Instead, a user holds one or more roles, and each role carries a defined set of permissions. Change the role, and every user in that role changes with it.
This indirection is the entire point. Without RBAC, access is a sprawling list of user-to-permission pairs. Every new hire, every role change, and every offboarding becomes a manual edit across that list, and mistakes accumulate. With RBAC, the question shifts from “what can this person do” to “what does this job need to do.” You define the job once as a role, then assign people to it.
The model was formalized in the NIST RBAC standard, published as INCITS 359. That standard describes the core relationships that every RBAC implementation shares: users, roles, permissions, and the assignments that connect them. The terminology in commercial products varies, but the underlying structure is consistent. If a system grants access through named roles rather than through individual user entitlements, it is doing RBAC.
For security platforms specifically, RBAC matters more than it does for a simple application. A vulnerability management platform holds sensitive data about where an organization is weak. Who can view findings, who can export a report, who can approve a risk acceptance, and who can change a scanner integration are not trivial questions. RBAC gives you a structured, auditable way to answer them.
The Core Pieces: Users, Roles and Permissions
Every RBAC system is built from three primitives and the links between them.
A user is an authenticated identity. It is the person or service account that logs in and acts on the platform.
A permission is a single allowed operation. It answers one narrow question, such as “may this hold view findings” or “may this hold export reports.” A permission is intentionally small so that it can be combined precisely.
A role is a named bundle of permissions. It represents a job or a responsibility, such as analyst, auditor, or administrator. The role is where permissions are actually attached.
The links matter as much as the primitives. A user is assigned to a role. A role is granted a set of permissions. When the platform needs to decide whether a user may do something, it walks this chain. It looks up the user’s roles, gathers the permissions those roles carry, and checks whether the requested operation is allowed.
In a well-designed platform, roles are not hardcoded. Administrators can define custom roles tailored to their organization, choosing exactly which permissions each role carries. A security platform that uses RBAC at this level lets you build a role for, say, a read-only auditor who can view and export but cannot change anything, alongside a remediation owner who can update findings but cannot touch integrations. The role catalog becomes a direct expression of how your team actually divides work.
This design also explains why RBAC scales. When a tenth analyst joins, you assign them the analyst role and you are done. When the analyst job changes to allow report export, you edit the role once, and every analyst inherits the change. The cost of access management stops growing linearly with the number of users.
How a Permission Matrix Works
The practical question is how permissions are described. The most common and most readable answer is a permission matrix.
A permission matrix expresses a role’s authority as a grid of two dimensions. One axis lists the things the platform manages, often called entities or resources. The other axis lists the operations that can be performed on those things, often called actions. Each cell in the grid is a yes or no: does this role permit this action on this entity type.
In a security platform, the entity axis covers the objects the platform actually works with. A representative set is companies, assets, projects, findings, reports, runbooks, rules, integrations, scans, and users. The action axis covers the operations that apply across those entities, such as view, create, update, delete, approve, and export. A matrix built from those two axes describes a role’s authority cell by cell. A role with finding: view and report: export can read findings and export reports, and nothing more.
This entity-by-action structure is what makes RBAC both precise and explainable. You can hand the matrix to an auditor and they can read off exactly what a role can do without parsing code. You can compare two roles by laying their matrices side by side. And because each cell is independent, you can assign any combination of entity and action that a job genuinely needs.
The full mechanics of a real-world matrix, including how the cells map to platform behavior and how to design a clean matrix for each role, go deeper than a definition piece should. For the cell-by-cell anatomy of a permission matrix, see our companion guide on the RBAC permission matrix explained. Here we keep to the model: roles carry an entity-by-action grid, and that grid is the source of truth for what the role allows.
Least Privilege and Why It Matters
The permission matrix is only as good as the discipline behind it. The principle that should govern every role is least privilege: grant the smallest set of permissions that the job actually requires, and nothing extra.
Least privilege matters because every unnecessary permission is a standing risk. If a role can export reports but never needs to, that export capability is an open door. If an account in that role is compromised, the attacker inherits the door. Over-provisioning is the quiet failure mode of access control. It rarely causes a problem on a normal day, and it dramatically widens the blast radius on a bad one.
RBAC makes least privilege achievable because the unit of design is the role, not the individual. You think carefully about a role once, model it tightly, and every user inherits that careful thinking. The OWASP guidance on access control treats deny-by-default and least privilege as foundational, and a clean RBAC matrix is the most direct way to put those principles into practice. The goal is a matrix where you can justify every cell that is switched on.
Scope: Global, Company and Project Access
A permission alone is not the whole story. RBAC in a multi-tenant security platform has a second dimension that simple RBAC tutorials often skip: scope.
Scope answers the question “on which slice of data does this permission apply.” A user might hold a role that allows viewing findings, but viewing findings for whom. For every tenant on the platform, or only for one company, or only for a single project? Scope binds the role to a boundary.
A common and practical set of scope levels is global, company, and project. A global grant is unrestricted, letting the user act across all tenants. A company grant limits the user to a specific company and the projects beneath it. A project grant limits the user to a single project.
The project scope carries an important subtlety. A project-scoped grant should not silently open up the company that owns the project. If it did, a consultant brought in for one engagement could see every sibling project at the same company, which is a cross-engagement data leak. Correct RBAC keeps project scope narrow on purpose. The project consultant sees their project and nothing adjacent to it.
Scope is where RBAC and multi-tenancy meet. The role decides what a user can do, and the scope decides where they can do it. Both have to resolve correctly before a single record is returned. For the broader picture of how isolation works across tenants, see the pillar on multi-tenant vulnerability management, which covers tenant boundaries in depth.
System Roles vs Custom Roles
Not all roles are created equal, and a mature RBAC implementation distinguishes between two kinds.
System roles are built into the platform and managed by the platform itself, not by administrators. They are seeded during installation and protected from modification or deletion through the normal interface. A typical example is a platform administrator role that carries wildcard authority, meaning it implicitly allows every action on every entity without an explicit matrix. System roles exist so that the platform always has a stable, trustworthy foundation that an operator cannot accidentally break.
Custom roles are the ones administrators create. They are where the organization’s real structure gets encoded. A custom role can be named anything and can carry any combination of entity and action permissions. This is where you build your auditor, your remediation owner, your read-only stakeholder, and any other role your operating model needs.
The distinction protects against two failure modes. First, it prevents anyone from accidentally deleting or weakening the role that keeps the platform administrable. Second, it prevents privilege escalation by naming. A custom role that an administrator names “platform admin” must not inherit the real platform administrator’s wildcard authority. A safe implementation checks both the protected flag and the role identity before granting that elevated authority, so a lookalike name buys nothing. The result is a clear line between the immutable foundation and the flexible roles you design on top of it.
Time-Bound Access Grants
Access is often temporary. A contractor needs the analyst role for the length of an engagement. An on-call engineer needs elevated access for a shift. An auditor needs read access for the duration of a review. Granting that access permanently and remembering to revoke it later is exactly the kind of manual step that gets forgotten.
Time-bound access grants solve this directly. When you assign a role to a user, you can attach an expiry. The grant is valid until that timestamp and then it lapses on its own. Nobody has to remember to revoke it, and the standing risk of a forgotten grant disappears.
The detail that separates a good implementation from a fragile one is how quickly the expiry takes effect. If a platform caches access decisions for performance, an expired grant could linger in the cache past its expiry. A careful design caps the cache lifetime to the soonest upcoming expiry across a user’s grants, so the moment a grant lapses, the cached decision is no longer trusted and access ends within seconds rather than at some later cache boundary. Mature systems also record an audit event when a grant expires, so the access lifecycle stays fully traceable.
Time-bound grants embody least privilege in the time dimension. Least privilege is usually framed as the smallest set of permissions. Expiry adds the shortest necessary duration. Together they keep access narrow in both what it allows and how long it lasts.
RBAC vs ABAC: A Quick Comparison
RBAC is not the only access control model, and the question it is most often compared against is attribute-based access control, or ABAC.
The difference is where the access decision draws its inputs. RBAC decides based on the role a user holds. The question is “what role is this user in, and does that role allow this action.” ABAC, described in NIST SP 800-162, decides based on attributes evaluated at the moment of the request. Those attributes can describe the user, the resource, the action, and the surrounding context, such as the user’s department, the data classification of the resource, the time of day, or the network the request came from.
RBAC’s strength is clarity. Roles are human-readable, auditable, and stable. An administrator can look at the role catalog and understand the access model. RBAC’s limit is that very rigidity. If access needs to depend on conditions that are not captured by a role, pure RBAC cannot express them.
ABAC’s strength is exactly that flexibility. It can encode policies like “allow access only during business hours from a corporate network to data below a certain classification.” Its cost is complexity. Attribute policies are harder to read, harder to audit, and harder to reason about when something goes wrong.
In practice, the two are not strictly opposed. Many security platforms use RBAC as the backbone for its clarity, then layer scope, which is itself an attribute of the grant, to add the contextual boundary that pure RBAC lacks. For most security platform needs, RBAC with scope is the pragmatic choice: it keeps the model explainable while still respecting tenant and project boundaries. Reach for fuller ABAC only when access genuinely has to turn on runtime conditions that no role can capture.
Why RBAC Fits Security Platforms
A vulnerability management platform is a high-trust environment. It knows where an organization is exposed, it holds remediation evidence, and it can change scanner integrations and risk decisions. That makes precise, auditable access control a requirement, not a nice-to-have.
RBAC fits this setting because it gives you four things at once. It gives you precision, through an entity-by-action matrix that says exactly what each role can touch. It gives you scale, because access is managed at the role level rather than per user. It gives you boundaries, through scope that confines a role to the right tenant or project. And it gives you accountability, because roles and grants are explicit records that an auditor can review.
The model also composes cleanly with the other controls a security platform needs. Scope ties RBAC to multi-tenancy. Time-bound grants tie it to least privilege over time. Approval permissions tie it to four-eyes change control. None of these need a different access model bolted on. They are all expressed through the same RBAC primitives of users, roles, permissions, and scope.
Conclusion
Role-based access control grants access by role rather than by individual user, which is what makes access manageable, auditable, and safe as a platform grows. Its core pieces are users, roles, and permissions, and its most readable expression is a permission matrix built from entity types and actions. Scope confines a role to the right tenant or project, system roles keep the foundation stable, and time-bound grants keep access from outliving its purpose. Compared with ABAC, RBAC trades some runtime flexibility for clarity that holds up under audit, and for most security platforms that trade is the right one.
If you want the next level of detail, the RBAC permission matrix explained walks through the matrix cell by cell, and the multi-tenant vulnerability management pillar shows how scope and isolation fit the bigger picture. See how PMAP builds custom roles, scoped grants, and time-bound access in the identity and RBAC datasheet.
Frequently Asked Questions
What does RBAC stand for?
RBAC stands for role-based access control. It is an authorization model where permissions are attached to named roles, and users gain those permissions by being assigned to a role rather than by being granted permissions directly.
What is the difference between a role and a permission?
A permission is a single allowed operation, such as viewing findings or exporting a report. A role is a named bundle of permissions that represents a job, such as analyst or auditor. Users are assigned to roles, and roles carry the permissions.
What is a permission matrix in RBAC?
A permission matrix expresses a role’s authority as a grid of entity types against actions. Each cell answers whether the role allows a given action, such as view or export, on a given entity, such as findings or reports. It is a readable way to describe and audit exactly what a role can do.
What is the difference between RBAC and ABAC?
RBAC decides access based on the role a user holds. ABAC, or attribute-based access control, decides based on attributes evaluated at request time, such as user department, resource classification, or time of day. RBAC is clearer and easier to audit, while ABAC is more flexible for context-dependent policies.
What does least privilege mean in RBAC?
Least privilege means granting a role only the permissions the job genuinely requires and nothing more. In RBAC you apply it by designing each role’s permission matrix tightly, so every user in that role inherits a minimal, justifiable set of permissions.
What is scope in role-based access control?
Scope defines the boundary on which a role’s permissions apply, such as global, a single company, or a single project. The role decides what a user can do, and the scope decides where. A project-scoped grant should stay narrow and not silently open the owning company.
What are time-bound access grants?
Time-bound grants attach an expiry to a role assignment so access ends automatically at a set time. They remove the risk of forgotten access for contractors, on-call shifts, and audits, applying least privilege to the time dimension as well as the permission set.
