Why does RBAC create role bloat in larger organisations?

Why This Matters for Security Teams

RBAC works best when job functions are stable and access patterns are predictable. That assumption breaks down as organisations grow, because exceptions multiply faster than the underlying job taxonomy. Security teams then add “just one more role” for each edge case, and the model starts encoding temporary business decisions as permanent access constructs. NIST’s NIST Cybersecurity Framework 2.0 still points practitioners toward least privilege and access governance, but RBAC alone does not prevent overfitting the directory to organisational noise.

For NHI governance, the pattern is even more visible. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that entitlement sprawl is usually a symptom of weak decision design, not just bad housekeeping. When role count grows faster than the business, access reviews become harder to defend because reviewers are validating structure rather than actual need. In practice, many security teams discover role bloat only after audit friction, delayed provisioning, or privilege creep has already become normal operating behaviour.

How It Works in Practice

Role bloat usually starts with a sensible shortcut. A team needs access for a contractor, a regional exception, a service account, or a one-time project, and instead of changing the authorisation model, they create a new role. That role often inherits 80 to 90 percent of an existing one, then adds a small delta. Over time, the catalogue becomes a patchwork of near-duplicates that are difficult to name, difficult to audit, and difficult to retire.

In mature environments, RBAC bloat shows up in three places:

• Provisioning: help desks and IAM teams cannot tell which role is the “real” one, so they over-assign to avoid delays.

• Review: approvers cannot distinguish business necessity from historical drift, so access recertification becomes rubber-stamping.

• Engineering: application teams hard-code role checks that mirror the directory instead of the actual task or resource context.

Current guidance suggests combining RBAC with attribute-based or policy-based decisions so the role defines a coarse baseline while runtime policy decides whether the access is valid in context. That is especially important for NHIs, where service accounts and API keys often outlive the workload that created them. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into service accounts, and 71% of NHIs are not rotated within recommended time frames, which means role explosion often coexists with weak lifecycle control.

A practical way to reduce bloat is to separate permanent entitlements from temporary exceptions, then enforce expiry dates, ownership, and review triggers for every exception role. Stronger programs also map roles to application function and data sensitivity, not to every exception path. These controls tend to break down when legacy applications require embedded entitlements and the organisation lacks a reliable inventory of who or what is actually using each role.

Common Variations and Edge Cases

Tighter role design often increases administrative overhead, requiring organisations to balance cleaner access control against faster onboarding and lower support load. That tradeoff becomes obvious in large, federated enterprises where local teams need some autonomy, and there is no universal standard for whether roles should be centralised, delegated, or hybrid.

A common variation is “pseudo-RBAC,” where roles are really bundles of entitlements created to satisfy one application or one department. Another edge case is machine access: teams may assume service accounts should follow human-style role structures, but workload identity usually benefits more from narrow, task-specific policy than from broad enterprise roles. The Ultimate Guide to NHIs is useful here because it frames the lifecycle problem, not just the permission problem.

Where possible, best practice is evolving toward fewer, more stable roles plus runtime controls such as conditional access, approval workflows, and short-lived credentials. That approach does not eliminate RBAC, but it prevents the directory from becoming the system of record for every exception. For organisations operating under NIST Cybersecurity Framework 2.0, the operational goal is not zero roles, but roles that remain understandable, reviewable, and tied to a real business function.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?