Notifications
Clear all
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.
NHIMG editorial — based on content published by Zluri: Access Management RBAC Model, and why accurate roles and manageable roles conflict
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Cap role proliferation early Set a threshold for role count, nested groups, and regional variants before the catalogue becomes unreviewable.
- Measure real SCIM coverage Inventory how many applications are actually integrated, not how many are theoretically supported.
- Use access reviews to surface drift Treat recertification outcomes as design feedback.
What's in the full article
Zluri's full blog post covers the operational detail this post intentionally leaves for the source:
- The sales-role multiplication example with the full 72-role calculation across segments, regions, and employment types.
- The SCIM coverage discussion showing how many applications remain outside automation even when RBAC appears mature.
- The maintenance-burden math behind initial setup, monthly role upkeep, and exception processing load.
- The staged evolution path from RBAC toward attribute- and policy-based models.
👉 Read Zluri's analysis of why RBAC becomes hard to govern at scale →
RBAC at scale: what IAM teams miss about role drift?
Explore further
10/06/2026 10:00 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: RBAC accuracy vs manageability: why roles break at scale
