Role-based access control (RBAC) promises a clean, auditable way to grant access: define roles, map people to roles, and let entitlements follow. In practice, most RBAC models start tidy and then rot — because they were built around the org chart, and org charts change constantly. Here is how to design roles that last.
Why most RBAC models fail
The common failure mode is modeling roles after departments or reporting lines: "Marketing East," "Finance Team B," "Sales Region 3." This feels intuitive, but it breaks the moment the business reorganizes, acquires a company, or renames a division — which is to say, constantly. You end up with hundreds of stale roles, exceptions piled on exceptions, and an access model no one trusts.
Design around job functions, not org structure
A durable role describes what a person does, not where they sit. A "Accounts Payable Clerk" performs the same functions whether they report to Finance East or Finance West, before or after a reorg. Anchor roles to those stable job functions and the model survives organizational churn.
A useful mental model has three layers:
- Birthright access — what everyone gets on day one (email, intranet, baseline collaboration tools). Granted automatically to all employees.
- Functional roles — access tied to a specific job function (e.g., "AP Clerk," "Field Technician," "Backend Engineer"). This is the heart of your RBAC.
- Requestable add-ons — access that some people in a role occasionally need, granted on request with approval and an expiry. This keeps the base roles lean.
Keep base roles small; make exceptions requestable
The temptation is to stuff everything a role might need into the role itself. Resist it. Over-broad roles are how least privilege dies. Instead:
- Put only the access the function always needs into the role.
- Move "sometimes" access into requestable packages with approval and time limits.
- Treat any standing exception as a smell — if many people in a role need an add-on, promote it into the role deliberately; if few do, keep it requestable.
A role that grants more than its function strictly requires is not a role — it is a standing risk you have not noticed yet.
Wire roles to the identity lifecycle
RBAC only delivers if assignment and removal are automatic. Connect roles to your authoritative source (usually the HR system) so that:
- Joiners receive birthright access plus the functional role for their position on day one.
- Movers lose the access of their old function and gain their new one when their role changes — this is where standing access usually accumulates if done manually.
- Leavers are deprovisioned automatically on termination.
In Microsoft Entra ID, this maps cleanly onto Entitlement Management (access packages for functional roles and add-ons) and lifecycle workflows (automated joiner/mover/leaver actions).
Govern it continuously
Even a good model drifts. Keep it honest with:
- Scheduled access reviews so role membership and add-ons are re-certified by owners.
- Segregation-of-duties policies that flag toxic combinations (e.g., the same person who creates vendors can also approve payments).
- A periodic role-catalog review to retire roles that no longer map to a real function.
The payoff
Build roles around durable job functions, keep them lean, automate assignment through the lifecycle, and review continuously — and your RBAC model stops being a quarterly cleanup project. It becomes infrastructure that quietly enforces least privilege through every reorg, acquisition, and growth spurt.
Untangling an RBAC model that no longer reflects reality? Let's talk — redesigning roles around job functions is one of the highest-leverage governance moves available.