What is RBAC?
RBAC, role-based access control, is a permissions model that ties access rights to roles instead of to individual people. A role bundles the rights needed for a task, for example first-level support or security analyst; users get their rights only through being assigned such roles. That keeps permissions consistent, traceable and easy to maintain: when someone changes tasks, they change role instead of accumulating individual rights. RBAC is therefore the most practical tool for enforcing least privilege, giving every person and every service only the rights they actually need.
RBAC in detail
An RBAC model has three building blocks: users, roles and permissions. Permissions attach to roles, users attach to role assignments; direct individual rights for people are off the table. On top of that, domain scoping has become established practice: it further limits which slice of the data a role affects, for example just one site, one department or one tenant. Rights then answer two questions: what is the role allowed to do, and where does that apply?
RBAC should be distinguished from ABAC (attribute-based access control), which decides access through attributes and conditions such as device state or location. In practice, the two complement each other: RBAC provides the stable underlying structure, and attribute-based conditions refine it case by case. The role model is formally described, among other places, in NIST's work on RBAC.
Why RBAC matters in Zscaler operations
Zscaler admin consoles are powerful: anyone with access there can change policy for the entire organisation. In many organisations, helpdesk teams therefore end up with either no visibility at all, so every ticket gets escalated, or far too much access, so risk grows. RBAC resolves that dilemma: read-only insight for case handling is one role, administrative changes are another. That way, first-line support sees what it needs for the case without being able to change anything.
The model also matters for evidence: NIS2 requires concepts for access control, and DORA requires controlled rights management in the financial sector. A clean role model with domain scoping answers the auditor's question, who can access what and why, directly from the structure itself, instead of having to be reconstructed from individual rights that grew organically over time.
Common sources of error
- Role sprawl: once there is effectively one role per person, the model is just individual rights under a different name.
- Permanent rights for one-off cases: broad roles granted for a single task often stay in place permanently.
- Shared accounts: shared logins destroy the link between actions and individual people, and with it any audit trail.
- No recertification: role assignments need regular review, or long-tenured staff quietly accumulate rights over the years.
RBAC in practice: what CentaurNexus contributes
CentaurNexus applies RBAC with domain scoping consistently across Zscaler operations: through User Support Center, helpdesk roles get a read-only 360-degree view of users across ZIA, ZPA and ZDX without needing Zscaler admin rights, and only ever see the area they are responsible for. Write actions stay reserved for dedicated roles, can be approved under a four-eyes principle, and land in the append-only audit trail. For MSPs, cross-tenant scoping is added on top: many customer tenants in one interface, kept strictly apart. For how support without admin rights works in practice, see the guide Zscaler support without admin rights.
RBAC in operation: how to spot it
RBAC tickets all sound the same: “I don't have permission.” The cause is almost never the role alone, though. It usually comes down to one of three places.
“We have the same role, but he sees more than I do.”
What it usually is: In that case, it is not the role that differs but its scope. The same role can point at different tenants, sites or object groups.
How to tell them apart: Look at role and scope separately. If you only compare the role, you will not find a difference and keep searching in the wrong place.
“The role is right, but the action still gets denied.”
What it usually is: Usually a second condition kicks in: a four-eyes requirement, a write permission that is switched off for this tenant, or an action that is only ever meant to be read-only.
How to tell them apart: The question is not “is this role allowed to do that”, but “is this action meant to be a write action for this tenant at all”.
“After the reorg, permissions suddenly went missing.”
What it usually is: The classic case. Permissions hang off groups, and groups hang off the organisation. Change the group assignment, and permissions change with it, without anyone having touched a role.
How to tell them apart: Do not check the role assignment; check group membership instead. That is where the change happened.
“Nobody remembers why this role is allowed to do that.”
What it usually is: A sign of permissions that grew over time. Individual exceptions stay in place long after their original reason is gone.
How to tell them apart: That is a cleanup task, not an incident. It belongs on a plan, not inside a ticket.
Role, scope and group membership are three different things. Mix them up in a ticket, and every permission case costs extra rounds of back-and-forth.
Related terms
Frequently asked questions about RBAC
RBAC stands for role-based access control. Access rights are not assigned to individual people but tied to roles such as helpdesk or administrator; users get their rights by being assigned these roles. That keeps permissions consistent and auditable, and makes onboarding, role changes and offboarding considerably easier.
RBAC decides through roles: whoever holds the role gets the rights that come with it. ABAC decides through attributes and conditions, such as device state, location or time of day, which allows finer but also more complex control. In practice, combining the two works well: RBAC as the stable underlying structure, attribute-based conditions as situational refinement.
Because Zscaler policies affect the entire organisation, as few people as possible should hold full admin rights. RBAC allows read-only insight and administrative changes to be split apart: the helpdesk gets a view of user and policy status for case handling, while changes stay reserved for a small number of authorised people. That lowers both risk and escalations at the same time.
As few as possible, as many as necessary. A small set of standard roles built around tasks works well in practice, for example first-level, second-level, administration and audit, topped up with a handful of well-justified special roles. Once there is effectively one role per person, the model has failed and needs to be consolidated.
NIS2 does not mandate a specific model, but it does require concepts for access control and controlled risk management; the relevant national transposition governs the details. RBAC is the established way to implement and evidence these requirements, because roles and assignments let you work out, at any time, who can access what and why.
- NIST Computer Security Resource Center: Role Based Access Control (project page) - csrc.nist.gov
- Directive (EU) 2022/2555 (NIS2), requirements for access control and risk management - eur-lex.europa.eu
- Zscaler Help Portal: official documentation on role-based administration - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.