Topic starter
10/06/2026 9:10 pm
TL;DR: RBAC gives organisations a clean access model, but Zluri’s analysis shows the tradeoff is structural: precise roles can grow to 50 to 75 objects in a 1,000-employee environment, while broad roles drift into over-permissioning and exception churn. The real constraint is not role design alone, but whether the governance model can keep pace with application change.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “RBAC Model: Why You Can't Have Both Accurate and Manageable Roles”.
By the numbers:
- The article says a sales organisation can reach 72 separate roles in a 1,000-person company when segment, region, role type, and employment status all combine.
- Zluri says even perfect RBAC governs only 30-40% of actual applications because most usage sits outside SCIM coverage and central visibility.
- Zluri says ongoing maintenance can demand 40+ hours per month once new applications and role changes are included.
Key questions
Q: What breaks when RBAC roles become too granular?
A: When RBAC roles become too granular, the organisation usually gets role explosion.
Q: Why do broad RBAC roles increase governance risk?
A: Broad roles reduce maintenance effort, but they also bundle unrelated entitlements into one access package.
Q: How should security teams move beyond RBAC without losing control?
A: Start by keeping RBAC for broad access boundaries and layering ABAC or policy-based rules where decisions depend on context, ownership, or environment.
Practitioner guidance
- Set a role-count threshold Define a point at which new role creation requires architecture review, because uncontrolled role multiplication is the early warning for brittle RBAC.
- Measure application coverage honestly Compare the full application estate against the subset governed through SCIM and manual provisioning so you know what RBAC actually controls.
- Review roles for drift signals Look for repeated exceptions, stale role names, and reviewer confusion as evidence that role definitions no longer match current business use.
Bottom line: RBAC fails when organisations ask it to be both exact and easy to maintain, because those goals eventually conflict.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
10/06/2026 10:00 pm
RBAC accuracy and RBAC manageability are not simultaneously optimisable at enterprise scale: the model eventually forces a trade-off between precise access and operational sustainability. The article shows that as organisations add segments, regions, and job variants, role counts grow faster than teams can maintain them. That means RBAC is a bounded governance pattern, not a permanent operating model, and practitioners should treat its limits as expected rather than exceptional.
A question worth separating out:
Q: When should organisations move beyond simple RBAC to a more attribute-based model?
A: Move beyond RBAC when role alone cannot express the decision you need. Common examples include approving only unpublished posts, allowing actions based on user approval status, or limiting access by resource attributes. ABAC is the better fit when access depends on context, not just a fixed role and a resource type.
👉 Read our full editorial: RBAC accuracy vs manageability: why roles break at scale
This post was modified 4 days ago by NHI Mgmt Group