RBAC accuracy vs manageability: why roles break at scale

At a glance

What this is: This is an analysis of why role-based access control becomes unstable at scale, with Zluri arguing that organisations must choose between precise roles and manageable administration.

Why it matters: It matters because IAM teams, IGA leads, and PAM teams need to know when RBAC stops being a control and starts becoming an operational bottleneck across human, NHI, and delegated access.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's analysis of why RBAC becomes hard to govern at scale

Context

Role-based access control is simple in theory because it ties access to job function instead of individual entitlements. In practice, RBAC depends on stable job boundaries, visible applications, and a manageable number of role variants, which is exactly where large organisations start to strain. Zluri’s article is really about that governance fault line, not about a single feature or tool.

The primary identity problem here is human access governance, but the lesson extends to NHI and delegated access too. Once the environment includes shadow IT, application drift, regional variance, and exception-based provisioning, role precision and role manageability begin to pull in opposite directions. That is why RBAC often looks tidy in diagrams and messy in production.

Key questions

Q: How should security teams keep RBAC manageable as organisations grow?

A: Security teams should limit role sprawl, keep role definitions business-readable, and redesign roles once exceptions become routine. RBAC stays workable only when reviewers can still tell why a role exists, what it grants, and where manual exceptions begin. If those answers disappear, the model has outgrown itself.

Q: Why do access reviews matter so much for role-based access control?

A: Access reviews are the feedback loop that shows whether roles still match real work. Frequent exceptions suggest roles are too narrow, broad approvals suggest roles are too coarse, and confusion during review suggests the taxonomy has drifted. Without that feedback, RBAC becomes historical documentation instead of a control.

Q: What breaks when role-based access control depends on too many exceptions?

A: The model stops being role-based in practice and becomes ticket-based. Users wait for manual grants, managers share access workarounds emerge, and IT spends its time processing requests instead of governing access. At that point, the role catalogue no longer describes how work actually happens.

Q: Who is accountable when RBAC no longer reflects actual access patterns?

A: IAM and business owners share accountability because the problem spans design and governance. IAM owns the structure, but managers and application owners validate whether the role still matches the job. If the model drifts, accountability shifts from provisioning efficiency to lifecycle correction and access review discipline.

Technical breakdown

Why role explosion happens in RBAC

RBAC works by mapping a role to a bundle of permissions, then assigning people to that role. The trouble starts when real organisations add region, segment, employment type, product line, and special-case duties on top of a simple job family. Each new dimension multiplies the number of role objects. At that point, the model stops describing work and starts cataloguing exceptions. The result is not just more administration. It is a brittle abstraction that becomes harder to explain, review, and maintain as the application estate changes.

Practical implication: keep role design small enough that reviewers can still distinguish one role from another without relying on tribal knowledge.

How SCIM limits RBAC automation

SCIM automates account lifecycle actions for supported applications, but it does not solve the whole authorisation problem. It typically handles create and delete, not fine-grained permissioning inside an application. Zluri’s article also points to a practical coverage gap because only a minority of applications are SCIM-capable or actually integrated. That means RBAC can look automated while a large share of the estate still depends on manual tickets, custom APIs, or opaque app-level grants. The control is real, but its reach is narrower than many teams assume.

Practical implication: measure RBAC coverage by actual integrated applications, not by the number of roles you have defined.

Why access reviews become the feedback loop RBAC needs

Access reviews are the only part of the governance cycle that can tell you whether roles still match reality. If reviewers see repeated exceptions, the role model is too narrow. If they see unused access, the role model is too broad. If they cannot tell what a role actually grants, the model has drifted into administrative noise. RBAC therefore needs review evidence, visibility into application use, and a way to react when business changes outpace the role catalog.

Practical implication: tie review outcomes back to role redesign so the catalogue is corrected instead of merely recertified.

Threat narrative

Attacker objective: The objective is not just unauthorised entry but durable access that survives the formal role model and evades meaningful review.

1. Entry occurs when users, teams, or business units bypass the role model through shadow IT, manual requests, or shared access because official RBAC paths are too slow or too coarse. Escalation follows when broad roles or exception sprawl give people more access than their current job needs. Impact appears as review fatigue, uncontrolled access drift, and a governance model that no longer reflects how work is actually done.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RBAC fails when the organisation becomes more variable than the role model. The article’s core finding is not that roles are bad, but that role abstractions break once regional, functional, and employment differences compound faster than teams can maintain them. That is a governance limit, not a configuration mistake. Practitioners should treat role count as a design signal, not a badge of maturity.

Access reviews are the only credible brake on role drift, but they cannot save a broken role taxonomy. If reviewers cannot tell why two roles exist or which applications they actually govern, recertification becomes symbolic. That is why RBAC should be judged by whether it can still be understood by the business, not only by whether it can be provisioned by IT. Teams should re-evaluate whether their role model is still legible to reviewers and managers.

SCIM coverage creates a hidden governance boundary that many IAM programmes undercount. The model may govern a handful of federated applications well while leaving the majority of the application estate in tickets, manual grants, and shadow processes. That split matters because the control surface is smaller than the access surface. Practitioners should stop assuming that a functioning RBAC layer means the estate is actually governed.

Role precision and role manageability are competing objectives, not sequential wins. The article correctly shows that tuning one side usually worsens the other. That tension is exactly why mature programmes evolve beyond pure RBAC when complexity rises, rather than pretending the tradeoff can be removed. Identity teams should plan for governance models that can absorb policy and attribute logic before role sprawl becomes operational debt.

RBAC is a lifecycle control as much as an access model, and lifecycle drift is where it fails first. New tools, reorganisations, contractor changes, and app migrations all test whether a role still matches lived reality. When those changes outpace the role catalogue, the organisation is no longer enforcing access by role, only by historical memory. Practitioners should align role governance with lifecycle change, not annual clean-up cycles.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly role logic fails when the underlying identity estate is incomplete.
• If role governance is drifting, use the NHI Lifecycle Management Guide to test where provisioning, rotation, and offboarding controls are breaking down.

What this signals

Role governance will keep slipping unless teams treat application visibility as a prerequisite, not an afterthought. When only a minority of applications are actually governed through structured integration, the rest of the estate is being managed through memory, tickets, and exceptions. That is the point where RBAC turns from a design model into an incomplete reporting layer. Teams should expect more pressure to pair role governance with discovery and lifecycle controls.

The broader signal is that identity programmes are moving from static role administration toward policy-aware governance. RBAC still has a place, but its practical value depends on how well the organisation can absorb change without multiplying exceptions. For teams managing human users today and NHI or delegated access tomorrow, that means building for change rather than for a frozen role map.

For practitioners

• Cap role proliferation early Set a threshold for role count, nested groups, and regional variants before the catalogue becomes unreviewable. Use that threshold to force redesign when the number of roles starts growing faster than the business can explain them. Track growth by function, not just by system.
• Measure real SCIM coverage Inventory how many applications are actually integrated, not how many are theoretically supported. Separate fully automated provisioning from manual ticket handling and from shadow IT so governance decisions reflect the true control boundary.
• Use access reviews to surface drift Treat recertification outcomes as design feedback. Repeated exceptions mean the role is too narrow, repeated approvals with no evidence of use mean the role is too broad, and unclear reviews mean the taxonomy is no longer legible.
• Document the business meaning of each role Require each role to answer who it is for, what it grants, and why it exists. If reviewers or managers cannot explain the difference between adjacent roles, collapse or rework them before the next provisioning cycle.

Key takeaways

• RBAC breaks when organisational variety grows faster than the role catalogue can stay intelligible.
• SCIM and access reviews help, but they do not eliminate the mismatch between designed roles and lived access patterns.
• Practitioners should govern RBAC as a lifecycle problem, with visibility and redesign triggers built in from the start.

Key terms

• Role-Based Access Control: Role-Based Access Control is an access model that assigns permissions through job-based roles instead of per-user grants. It works best when work patterns are stable and easy to classify. In complex organisations, the role catalogue can grow faster than governance can keep it accurate.
• Role Explosion: Role explosion is the point where a role model produces too many variants to maintain safely. It usually follows attempts to make roles perfectly precise across regions, teams, and exceptions. The result is administrative overload and a catalogue that no longer reflects actual access needs.
• SCIM Coverage: SCIM coverage is the share of an application estate that can be provisioned and deprovisioned through standard lifecycle automation. It matters because a role model can only automate what the connected applications support. Limited coverage leaves many access decisions in manual or shadow processes.
• Access Review: An access review is a governance checkpoint where a reviewer confirms whether a role or entitlement is still appropriate. In a healthy programme, reviews expose drift, over-permissioning, and unclear role boundaries. When reviews become mechanical, they stop correcting the model and start preserving its mistakes.

Deepen your knowledge

RBAC governance and access review design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is already seeing role drift, it is worth exploring the lifecycle angle as well.

This post draws on content published by Zluri: Access Management RBAC Model, and why accurate roles and manageable roles conflict. Read the original.