Role Mining That Doesn't Collapse Under Its Own Weight

RBAC is sold as the cure for entitlement chaos: define roles, assign people to roles, govern the roles. In practice, most RBAC initiatives produce a role explosion — thousands of roles, many overlapping, many with a single member, none clearly owned — that is harder to govern than the entitlements they were meant to tame. The failure is almost always the same: trying to model every nuance of access as a role.

The two-layer model that actually holds

The model I keep returning to separates roles into two layers with different purposes and different lifecycles:

• Business roles — coarse, organisationally meaningful, derived from HR attributes (department, job function, location). "Branch Teller," "Claims Assessor." These map to birthright access and are stable because the org structure is relatively stable.
• Application/technical roles — fine-grained bundles of entitlements within a system, owned by the application team who understands them. These change at the application's pace, not the org's.

Business roles grant access by requesting technical roles. This separation means the business does not need to understand application internals, and application teams do not need to understand the org chart. Each layer is owned by people who can actually maintain it.

Mine top-down and bottom-up, then meet in the middle

Pure bottom-up role mining — clustering existing entitlement assignments to discover patterns — produces statistically tidy roles that mean nothing to a human. Pure top-down — designing roles from job descriptions — produces clean roles that do not match what people actually have. Use both: mine bottom-up to find the candidate patterns, then validate top-down against business reality. The roles that survive both tests are the ones worth keeping.

Accept that RBAC won't cover everything — and that's fine

The fatal mistake is insisting that 100% of access flow through roles. It won't. There is always a long tail of legitimate, person-specific access that does not generalise. Trying to roleify the tail is what creates the explosion. Handle the tail through request-based access with proper approval and review — a complement to RBAC, not a failure of it. A healthy environment might have 70-80% of access role-derived and the rest individually granted and governed. That is a success, not a shortfall.

Govern roles like the assets they are

Every role needs an owner, a description a human can read, and a periodic review of its definition — not just its membership. Roles drift: entitlements get added "just this once" and never removed, and the role slowly becomes a grab-bag. Reviewing role contents is far more leverage than reviewing individual assignments, because one role fix corrects access for everyone who holds it.

RBAC done pragmatically — two layers, owned by the right people, complemented by governed request-based access for the tail — is one of the highest-leverage things an identity team can build. RBAC done dogmatically collapses into a role swamp. The difference is knowing what not to model.