Designing Role-Based Access That Doesn't Rot Within a Year
Most role-based access control systems start clean: a handful of roles, clear boundaries, easy to reason about. A year later, they're a pile of one-off exceptions: "give Sarah admin on this one project because she needed it for a week," never revoked, plus three roles that are functionally identical but were created by different people who didn't know the other existed.
The fix isn't a better initial design, it's a framework for how roles get created, reviewed and retired, since that's the part most teams skip.
Vendors Covered in this Article
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Should RBAC roles follow job titles or actions?
The most common RBAC mistake is designing roles around org chart titles ("Engineer," "Manager," "Admin") instead of the specific actions a person actually needs to perform. Titles change and don't map cleanly to permissions; actions are concrete and auditable. List out the specific things someone needs to do (deploy to production, view customer PII, modify billing) and build roles as bundles of those actions, not as a stand-in for a job description.
This also makes onboarding and offboarding far simpler to reason about. When someone changes teams, a title-based role forces you to figure out which of their old permissions should carry over and which shouldn't, usually by guesswork. An action-based role just gets swapped for the new one, and the old bundle of permissions goes away cleanly with it.
Decide who can grant access before you decide who has it
A role system is only as good as its approval path. If any admin can grant any role to anyone with no review, the roles themselves barely matter, because the real access boundary is "whoever has admin," which tends to be a bigger group than anyone intended. Require a second person to approve any grant of a high-privilege role, and log every grant with who approved it and why, so a future audit doesn't have to reconstruct the reasoning from memory.
Build in expiration by default for anything temporary
The single biggest source of RBAC rot is access that was meant to be temporary and never got revoked: the contractor who finished their engagement six months ago, the engineer who needed elevated access for one incident and kept it out of convenience. Any grant tied to a specific project, incident, or time-boxed need should expire automatically rather than relying on someone remembering to remove it. A standing role should require an active justification, not the absence of someone getting around to cleaning it up.
For example, an engineer is given elevated production access to handle one incident. The grant is created with an expiry tied to the incident, a short reason, and a named approver. When the window closes, access drops automatically and nobody has to remember to clean it up. A useful decision rule: if you cannot say when a grant should end, it is not a temporary grant, and it needs the same approval and quarterly re-approval as any standing role.
How do you run an access review that actually removes access?
A review that produces a spreadsheet nobody acts on isn't a review, it's documentation of a problem you're choosing not to fix. Structure the review so each role owner has to affirmatively re-approve every person on that role, not just glance at a list. Anything not re-approved gets removed automatically at the end of the review window. This flips the default from "access persists unless someone objects" to "access requires active confirmation," which is the difference between a review that shrinks your access surface and one that just documents how large it's gotten.
- List every role and its current members before the review starts
- Have each role's owner explicitly re-approve, not just skim, every member
- Remove anything not re-approved by the review deadline, automatically
- Track how many grants get removed each cycle as a health signal for the whole system
A review that removes nothing, cycle after cycle, is worth investigating on its own. Either your access is genuinely lean, which is rare enough to double check, or the review has become a formality that role owners click through without really looking. Watching that removal count over time tells you which one you're actually dealing with, and a sudden jump in removals after a long flat stretch is usually a sign the previous cycles weren't as rigorous as they looked.
What Good Looks Like
Every role maps to a specific set of actions rather than a job title, every high-privilege grant requires a second approver, and a quarterly review actually removes access that isn't re-approved rather than just documenting it.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Tenable can surface accounts and roles with excessive standing privilege as part of a broader vulnerability picture, which is a useful input into your quarterly access review.
CrowdStrike's identity threat detection is worth layering on top of your RBAC design to catch anomalous use of a legitimate role, like a login pattern that doesn't match how that account is normally used.
Frequently Asked Questions
How many roles should a small engineering team actually have?
Fewer than feels natural at first, often five to eight for a team under fifty people: a small number of broad roles covering most day-to-day work, plus a short list of narrowly scoped, time-limited grants for anything unusual. More than that and the roles start overlapping in ways nobody can reason about clearly.
What's the fastest way to find out how bad our current access sprawl is?
Pull a list of everyone with your highest-privilege role and ask each person's manager whether they still need it. You'll typically find at least a few grants nobody can explain, which is exactly the signal that your review process isn't running or isn't working.
Should service accounts and human accounts follow the same access rules?
The same principles apply, but service accounts need their own review cadence since nobody's manager is naturally prompted to reconsider them. A service account created for a project that shipped a year ago is just as much a liability as a former contractor's login, and it's easier to forget about because no person is attached to it day to day.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
Designing Role-Based Access Control That Survives Your Next Reorg
A worksheet approach to mapping roles to permissions so access control doesn't quietly rot every time your team's structure changes.
Designing Role-Based Access Control That Scales With You
A practical starting point for role-based access control: how many roles to define, where permissions belong in the data model, and what to avoid.
Setting Up Role-Based Access Control Without Overbuilding It
A practical way to set up role-based access control: start from real roles, separate roles from permissions, and handle exceptions on purpose.
Building an RBAC Model That Survives Contact With Reality
A step-by-step method for building a role-based access model for your APIs that stays accurate as your team and product both grow.
Enforcing Document-Level Permissions in Multi-Tenant RAG
Pre-filtering versus post-filtering, chunk-level metadata, and how to avoid an N+1 permission check: a practical guide to RAG access control.
Designing Role-Based Access for a Real-Time Data Pipeline
A step by step way to design roles for a real-time pipeline so producers, consumers, and admins each get exactly the access their job requires.