RBAC is simple to design and difficult to keep. Roles are easy to create, permissions are easy to add, and almost nothing in a growing company ever takes either of them away.
The short answer
RBAC stands for role-based access control. Instead of granting permissions to individual people, you attach permissions to roles and assign people to roles. Access is then decided by what someone does rather than who they are, which makes joining, moving and leaving an administrative action rather than a series of individual decisions.
It is the default access model in almost every system you already run, and the reason most access review findings look the way they do.
On this page
The four building blocks
| Block | What it is |
|---|---|
| Person | An employee, contractor or service account that needs to do something |
| Role | A named job function, defined once and reused, such as support agent or billing admin |
| Permission | A specific allowed action on a specific resource, attached to the role rather than the person |
| Assignment | The link between a person and a role, which is where most access problems actually live |
Where RBAC breaks
RBAC rarely fails at design time. It fails quietly, over about eighteen months.
| Failure | How it happens |
|---|---|
| Role explosion | Every exception becomes a new role. You end up with more roles than people, and nobody can say what any of them grant |
| Role creep | A role gains a permission to unblock one urgent task and never gives it back, so everyone holding that role silently gains it too |
| Stacked roles on movers | Someone changes team, gets the new role and keeps the old one. After two moves they can see more than their manager |
| Shared accounts | One login used by several people breaks the model entirely, because there is no person to assign a role to |
| Orphaned roles | A role with no members and no owner, still live, still granting access the day somebody is added to it |
| Everything in admin | The fastest way to ship becomes the permanent arrangement, and admin becomes the effective default role |
Movers are the gap, not leavers
Most companies handle leavers reasonably well, because offboarding is a visible event with a checklist attached. Internal moves have no such trigger. Someone shifts from support to finance, receives the finance role on day one and keeps support access indefinitely, because nobody owns the removal. The result is an accumulation that no single decision created and no single person can explain, which is exactly what an access review is designed to surface.
RBAC and ABAC
Attribute-based access control decides using context rather than job title: who, what, where, when and on which record.
| RBAC | ABAC | |
|---|---|---|
| Decision basis | The role a person holds | Attributes of the user, resource and context |
| Example rule | Support agents can read tickets | Support agents can read tickets assigned to their own region, during their shift |
| Strength | Easy to explain, easy to audit, easy to grant | Precise, and handles cases roles cannot express |
| Weakness | Coarse. Exceptions turn into new roles | Complex. Hard to reason about and harder to evidence |
| Best for | Most companies, most of the time | Specific high-sensitivity decisions inside an RBAC model |
They are not competing models in practice. A workable pattern is RBAC as the structure, with attribute conditions applied to the handful of decisions where a role is too blunt an instrument.
What auditors check
| What they ask for | Why it fails |
|---|---|
| A list of roles and what each grants | Roles exist but nobody documented the permissions behind them |
| Who holds each role | The list includes people who moved teams or left months ago |
| Evidence of a completed access review | The review happened but produced no record of who approved what |
| Removals actually performed | The review flagged excess access and nothing was revoked afterwards |
| Separation of duties | One role can both raise and approve the same transaction |
| Privileged role handling | Administrative roles held permanently rather than elevated through PAM when needed |
The consistent theme is that a review without removals is not evidence of control. SOC 2, ISO 27001, PCI DSS and the RBI and SEBI frameworks all sample the same thing: the decision, the date and what changed as a result.
How Osto handles RBAC
Role-based access control sits inside the identity and access management module rather than as a separate product, alongside single sign-on, MFA and private access. Roles, assignments and the access decisions made against them are recorded in one place, which is what makes the review a report rather than an exercise in collecting spreadsheets from system owners.
The part a single stack changes is the mover problem. When identity, endpoint and application events land in the same SIEM, someone holding two roles across two functions is visible as a pattern rather than as two unrelated entries in two systems. That record also answers the access control questions in SOC 2, ISO 27001 Annex A and the Protect function of NIST CSF from one control set.
Platform walkthrough
A review that produces removals
Roles, assignments and access decisions in one place, with identity events correlated against endpoint and application activity. One owner, one dashboard.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is RBAC?
Role-based access control. Permissions are attached to named roles, and people are assigned to roles rather than granted permissions individually. Access follows job function, which makes joining, moving and leaving manageable at scale.
What is the difference between RBAC and ABAC?
RBAC decides based on the role someone holds. ABAC decides based on attributes such as location, time, device or which specific record is being accessed. RBAC is easier to explain and audit. ABAC is more precise and harder to evidence. Most organisations use RBAC with a few attribute conditions layered on.
What is role explosion?
The state where every exception has been handled by creating a new role, so the organisation ends up with more roles than people and no one can say what any of them grant. It is the most common way an RBAC model becomes unmanageable.
How is RBAC different from PAM?
RBAC governs ordinary access across the organisation. PAM governs privileged access specifically, adding vaulting, approval, time-limited elevation and session recording. Administrative roles should generally be elevated through PAM rather than held permanently under RBAC.
How often should access be reviewed?
Quarterly is the common expectation, with privileged roles reviewed more frequently. What matters more than the interval is that the review produces recorded decisions and actual removals. A review with no removals reads to an auditor as a review that did not happen.