Role-based access control (RBAC): a guide for IT teams

TL;DR: Role-based access control gives permissions to roles, not to individual people. Put someone in a role and they get everything that role can do. It cuts admin, makes audits straightforward, and limits the damage when an account gets stolen. Start with the simplest model, design your conflicting-role rules before you automate anything, and review assignments every quarter.

Role-based access control (RBAC) gives permissions to roles, not to people. You put a person in a role, and they get everything that role can do. Move them to another role and their access moves with them.

NIST defines RBAC as access control based on user roles, where a role carries the permissions needed to do a defined job.

Here's the thing. Most access problems are not technical. They start when permissions get handed out one person at a time. Someone changes teams, keeps their old access, and nobody notices for two years.

RBAC fixes that by making the job the unit of access, not the person.

This guide covers how it works, the four models, how it compares to ABAC, what to build first, and the Australian rules that apply.

What is RBAC and how does it work?

RBAC puts a layer between users and permissions. That layer is the role.

The pieces:

• Users. People or service accounts that need access.
• Roles. Named jobs like `Finance Analyst`, `Support Agent` or `Platform Admin`.
• Permissions. What a role may do. Read, write, delete, approve.
• Sessions. The live context where a user switches on some of their roles.
• Scopes. What the permission applies to. A database, an API, a tenant workspace.

A support agent logs in. The system checks their roles, finds `Support Agent` and `Read-Only Billing`, and switches both on for that session. They can read a billing record. They cannot issue a refund, because `Refund Approver` was never assigned.

Membership and activation are different things. You can belong to a role all year and only switch it on for ten minutes. That split is what makes dynamic separation-of-duty rules work. A user holds two conflicting roles but can never run both at once.

The four RBAC models

NIST IR 6192 sets out four levels. Each one builds on the last.

Two extras worth knowing. Cardinality caps how many people can hold a role, which is handy for something like `Database Admin`. Scoped roles lock a role to one boundary, such as a single tenant.

Why teams use RBAC

Change the role once and every member gets the change. That is the whole pitch.

Sounds small. It isn't. It is the difference between an access review that takes an afternoon and one that takes three weeks and still misses people.

• Less admin. You update one role, not forty user records. NIST's RBAC project calls this the model's main advantage.
• Easier audits. Roles match job functions, so you can show an auditor why someone has access.
• Least privilege. A role carries only what its job needs. A stolen account does less damage.
• It scales. A new hire gets existing roles. You are not designing a fresh permission set every time.

The WA Auditor General's better-practice guide backs the same three habits: pre-defined roles, least-privilege assignment, and a record of who holds privileged access.

RBAC vs ABAC, ACL and MAC/DAC

RBAC is not the only model. It is just the right default for most teams.

Start with RBAC. If roles alone cannot express the rule you need, add ABAC conditions on top. Do not throw out the role model to get there.

One point of confusion worth clearing up. Rule-based access control uses if/then conditions like time of day or IP address. That is a different thing to role-based, even though both get shortened to RBAC in conversation. Plenty of systems run both.

A worked example: a support portal

Three roles:

• `Support Agent`. View tickets, add notes, escalate, read the customer profile.
• `Support Lead`. Everything above, plus close tickets, reassign them, and see team reports.
• `Billing Admin`. View invoices, issue refunds, update payment methods. No ticket access at all.

A new hire joins support. They get `Support Agent` and start work. Six months later they get promoted, so they move to `Support Lead`. Nobody touches a single permission. If they later move to billing, they get `Billing Admin` and lose `Support Lead`.

Access follows the role. It does not follow the person.

How to implement RBAC

Work through this in order. Step 4 is the one teams skip, and it is the one that costs money later.

1. Inventory what you have. Every system, app and data store. Every current user, group and permission.
2. Design roles from job functions. Talk to the people who own the work. Aim for the fewest roles that cover real access needs. Never one role per person.
3. Model permissions. List what each role does to each resource. If a role does not need write access, it does not get write access.
4. Design separation of duty first. Find the conflicting pairs before you automate anything. `Requester` and `Approver` in the same workflow is the classic one.
5. Map users to roles. Use the new design as the source of truth. Do not copy the old permission sets across.
6. Automate provisioning. Wire your identity provider into your apps so a role change grants and revokes access on its own.
7. Test in staging. Check each role grants exactly what it should. Check the conflict rules actually block.
8. Ship with logging on. Capture every role activation, permission check and denial.
9. Review every quarter. Compare assignments against current jobs. Pull stale access straight away.

On Azure. Roles get assigned at a scope: management group, subscription, resource group or single resource. A `Reader` role at subscription scope reads everything in that subscription. The same role at resource group scope only reads that group. Pick the scope carefully, because it does more work than the role name does.

Where RBAC goes wrong

Roles that are too broad, and access nobody cleans up. Those two cause most of the trouble.

• Roles that grant too much. Usually inherited from old group structures. Check each role against real usage logs before you sign it off.
• Role explosion. A new role for every edge case until nobody can read the list. Make new roles need sign-off from a named owner.
• Stale assignments. People collect roles as they move teams. The WA Auditor General's guide flags this as a common gap in Australian organisations.
• Forgetting the robots. Service accounts, API keys and CI/CD pipelines all need roles too. Leaving them on broad permissions is a well-worn way in, and API key handling is where plenty of teams get sloppy.
• Shared logins. One account, several people, no way to tell who did what. It also makes account takeover much worse. This account drained in an hour is a fair reminder of the cost.
• No break-glass plan. You need a documented emergency access path, with logging and a review afterwards.

Pro tip. Version-control your role catalogue next to your infrastructure code. Then every role change is a diff someone can read, approve and roll back.

RBAC in multi-tenant platforms

This is where the stakes change.

In a single-company app, a bad role means someone sees too much of their own company's data. In a multi-tenant platform, a bad role can leak data between customers. That is a different class of problem. It is why we treat the role model as an architecture decision, not a feature.

The rule we work to: every role carries a tenant scope, and the app checks that scope on every request. Not just at login.

Our white-label AI SaaS build is a good example. Clerk handles sign-up, sessions and role-based access, so we never write our own auth. Postgres row-level security keeps every workspace isolated. Tenant-level member roles let partners run their own version with no data crossing between them.

CARED, the national NDIS allied health platform we built, splits access by surface as well as by role. Participants, therapists and admin staff each get their own app, running on Azure with Microsoft Entra B2B handling identity. Separating the surfaces makes the role boundaries much harder to get wrong.

For the groundwork underneath all this, our guide to multi-tenant SaaS basics covers the data model side.

The Australian rules that apply

RBAC is not just good practice here. It maps onto legal duties. Worth knowing before an auditor asks, not after.

The Privacy Act 1988. APP 11 says you must take reasonable steps to protect personal information from misuse and unauthorised access. Roles are one of the most direct ways to show you did. Design them so personal data only reaches people whose job needs it, and keep the access logs.

Notifiable Data Breaches. A tight role model shrinks the blast radius. If a stolen account only held `Read-Only Analyst`, the breach is far smaller than if it held admin.

The ACSC Information Security Manual. The ISM sets out identity and access requirements for government and critical infrastructure. Privileged access gets logged. Third-party access gets controlled and audited. Access reviews happen on a schedule.

Health data. The My Health Records Act 2012 and the Australian Digital Health Agency put specific controls on clinical data. Role definitions in health systems have to match clinical job functions, not just internal IT policy.

More on how this plays out in a build in our guide to AI software compliance.

Working with legacy systems

Almost nobody starts clean. You start with Active Directory groups, old application ACLs, and systems that predate modern identity providers.

Treat the existing groups as raw material, not the answer. Audit what each group actually grants. Map that to candidate roles in your new design. Then cut permissions back step by step, watching the app the whole time so you do not break a workflow. NIST recommends exactly this kind of iterative reduction when you move off per-user or ACL-based access.

For hybrid setups, Microsoft Entra ID, Okta or SailPoint can apply one role model across on-premises and cloud systems. That matters for Australian agencies running workloads across their own data centres and sovereign cloud regions.

Some old apps cannot read a modern identity token at all. Those need a middleware layer to translate role assertions into whatever format the app expects. It is a common pattern in financial services and health, where core systems can be decades old.

Tools people actually use

RBAC is turning up inside the AI tools now as well. Claude Cowork shipped it as part of going enterprise-ready, which tells you where the bar sits for buying AI into a regulated business.

How to measure whether it's working

An RBAC model rots if nobody watches it. Four numbers tell you whether yours is holding up.

• Role coverage. What share of users are fully governed by roles, with no leftover direct permissions.
• Stale assignment rate. How many assignments have not been reviewed inside your review cycle.
• SoD violations. How many people hold conflicting roles, whether by design gap or provisioning error.
• Privileged audit completeness. Can you reconstruct what a privileged user did from the logs alone?

Your logs need the user, the role activated, the resource, the action and the timestamp. That set feeds straight into Privacy Act reporting.

Access certification is the practical fix for stale access. Managers formally confirm their team's roles on a schedule. SailPoint and Saviynt automate it. For a smaller team, a quarterly review with a documented sign-off is a defensible minimum.

One thing people miss: audit the non-human identities too. AI model access, data pipeline permissions and automated agents all hold credentials, and they almost never show up in an access review. The same thinking applies to how you handle customer data in AI systems.

The hard part isn't the tooling

The gap between a good role model on paper and one that still works in two years is a governance problem, not a technical one.

Roles drift. People collect access. Reviews get skipped.

The teams that get this right treat the role catalogue the way they treat code. Versioned. Reviewed. Auditable.

When we work with founders and CTOs on a platform build, the RBAC conversation starts with who needs to see what. It ends with a much harder question: who owns keeping that answer true next year? The tooling is the easy half.

Get the role model right before you build

Designing RBAC properly at the start is one of the highest-value calls you can make on a platform build. Get it wrong and you pay twice. Once in remediation, and once in the incident that surfaces at the worst possible moment.

Devwiz builds secure multi-tenant AI platforms with RBAC and identity management in the architecture, not bolted on later. That covers role design, identity provider integration, Azure RBAC mapping, tenant-scoped permissions and access review tooling. We have shipped 200+ apps since 2015, including work for the NSW Government, Briometrix, Vivid and Huskee.

If you are building something that has to handle multiple organisations, several user types or regulated data, sort the role model before the first line of application code. Have a look at how we approach AI app development, or how we work with CTOs, then get in touch for a scoping conversation.

Frequently asked questions

What is a simple example of role-based access control?

A support portal where a Support Agent can view and update tickets but cannot issue refunds, while a Billing Admin can process refunds but has no ticket access. Each person's access comes entirely from the role they hold, not from permissions set for them individually.

What are the four main types of access control?

RBAC (role-based), ABAC (attribute-based), ACL (access control lists), and MAC/DAC (mandatory and discretionary). RBAC suits stable job functions. ABAC handles runtime context. ACLs work for small systems. MAC and DAC sit at opposite ends: one central and rigid, the other owner-controlled and flexible.

Is RBAC or ABAC the better choice?

RBAC is the better default for most teams because it is simpler to design, audit and maintain. ABAC is worth the extra complexity only when access decisions depend on live attributes like device trust or data classification that a role cannot capture. If you need both, layer ABAC conditions on top of RBAC rather than replacing it.

What is rule-based access control, and how does it differ from RBAC?

Rule-based access control grants or denies access using if/then conditions, such as time of day or IP address. Role-based access control uses role membership instead. They get confused because both shorten to RBAC. Many systems run rule-based conditions on top of a role-based foundation.

Does RBAC satisfy Australian Privacy Act requirements?

RBAC supports APP 11 (security of personal information) by keeping personal data reachable only by people whose role requires it. On its own it is not enough. You also need access logging, periodic reviews and documented procedures to meet the full requirements of the Privacy Act and the ACSC Information Security Manual.