Notifications
Clear all
Topic starter
19/08/2026 3:25 pm
TL;DR: RBAC role explosion makes role counts outpace the people they are meant to govern, slowing access checks and forcing administrators into near-duplicate roles, according to Teleport. Nested access lists reduce that drift by moving exceptions into inheritable lists, but governance still depends on clear ownership, recertification, and lifecycle discipline.
NHIMG editorial — based on content published by Teleport: How to Prevent RBAC Role Explosion with Nested Access Lists
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should security teams implement RBAC without creating role explosion?
A: Start with actual access patterns, not job titles, and define roles around repeatable business functions.
Q: Why do nested access lists help with access governance?
A: Nested access lists reduce duplication by letting membership in one list inherit permissions from another list.
Q: What breaks when organisations keep adding exceptions to RBAC?
A: The role catalogue grows until roles no longer represent stable business functions.
Practitioner guidance
- Freeze role definitions and move exceptions into lists Limit role changes to structural needs only, then use access lists for temporary or team-specific variations so the role catalogue does not multiply with each exception.
- Map inheritance paths before recertification Document how parent and child lists pass access so reviewers can see whether a user has direct rights, inherited rights, or both before each access review.
- Assign explicit owners to parent and child lists Make sure every nested list has a named owner responsible for membership changes, offboarding, and approval of inherited privileges.
What's in the full article
Teleport's full blog post covers the implementation detail this post intentionally leaves for the source:
- Step-by-step examples of how nested access lists are structured in Teleport.
- Operational walkthroughs for mapping team-based inheritance to reusable roles.
- Practical guidance on using access lists to reduce manual role edits at scale.
- A product-specific demonstration of how hierarchical RBAC behaves in large environments.
👉 Read Teleport's article on nested access lists and RBAC role explosion →
RBAC role explosion: are nested access lists the answer?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:10 pm
Role explosion is a governance failure, not just an RBAC inconvenience. When role counts outpace the actual population they are meant to serve, reviewability breaks first and least privilege breaks second. The control issue is not whether RBAC can express access, but whether the organisation can still explain entitlement scope without a spreadsheet of exceptions. Practitioners should treat role growth as an access-governance signal, not an administrative nuisance.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, according to the Ultimate Guide to NHIs , Key Challenges and Risks.
A question worth separating out:
Q: How do organisations prevent inherited access from surviving offboarding?
A: They should review parent and child list memberships together, not just the most obvious group assignment. Offboarding must check whether inherited entitlements remain active through another list, team, or delegated owner path. If that step is skipped, the person may be removed from one group while still retaining effective access elsewhere.
👉 Read our full editorial: RBAC role explosion and nested access lists in enterprise access
