Role explosion is the moment when RBAC stops working. It does not announce itself — it accumulates. A new edge case appears that does not fit any existing role, so someone creates a new one. A restructure happens and three roles become six because the org chart changed but the access model did not. A nurse gets transferred between units and needs slightly different access in each, so a unit-specific role appears. Six months later, nobody can explain what half the roles do or whether they are still accurate.

The classic response is to propose ABAC. The classic counter-response from dev teams is panic: building and maintaining a policy engine that evaluates combinations of user, resource, and environmental attributes at runtime is genuinely complex work. And so the organization stays stuck: too many roles to maintain, and too much implementation risk to move away from them.

The way out is not a choice between RBAC and ABAC. It is a hybrid model that uses each where it works best, with an IGA platform handling the attribute-based assignment above the application layer so developers do not have to build it into the application itself.

Why Role Explosion Happens

Understanding the mechanics of role explosion makes the solution clearer.

RBAC works well when roles map cleanly to job functions and access requirements are stable. A role called "Nurse" grants access to nursing workflows. A role called "Physician" grants access to clinical documentation. Simple, auditable, and maintainable at small scale.

The problem starts when organizational nuance gets encoded into the role model. A nurse at Unit A needs slightly different access than a nurse at Unit B. Rather than handling that nuance at the attribute or context layer, someone creates "Nurse-Unit-A" and "Nurse-Unit-B." Then a nurse who works across both units needs both roles, and someone notices they now have more access than a nurse at either unit alone. Another role appears. Multiply this pattern across specialties, locations, and organizational units, and you arrive at 200 roles that made sense at the time they were created and are now collectively ungovernable.

A related problem: when a user's access is reviewed and one application within a role needs to be removed, the role does not change — a new, custom role has to be created for that user. Every exception creates a new role variant. Role proliferation is not a failure of discipline; it is the natural outcome of encoding too much specificity into the role model.

The 80/20 Rule for Role Design

The most consistent practical advice from experienced IGA practitioners is to aim for ten to a few dozen roles rather than hundreds. The goal is to get 80 percent (or 70, or 90) of access assignments right with a small set of well-defined roles, and treat the remaining variations as exceptions handled through access requests, not by creating new roles.

In a healthcare context, this means:

Horizontal roles (job function): Nurse, Physician, Lab Technician, Billing Staff, System Administrator. These describe what the person does and should remain relatively stable across organizational changes.

Birthright access for each horizontal role: the set of applications and permissions that every person in that role needs to function. A nurse should have access to nursing workflows on day one, without requesting it, regardless of which unit they are in.

Attribute-based scoping for the nuances: department, unit, location, patient relationship. Rather than creating "Nurse-ICU" and "Nurse-Cardiology" as separate roles, the Nurse role defines capability, and attributes determine scope. This is where ABAC logic belongs — in the scoping layer, not in the role definition.

Exception access requests for everything that does not fit the role model. Not every access pattern needs a role. If a physician needs access to a quality management system that 90 percent of physicians do not use, that is a request workflow, not a new role.

This structure keeps the role catalog human-readable and the organizational nuance in a layer that can be managed by attribute rules rather than by multiplying role variants.

The Third Way: Attribute-Based Assignment, Not Attribute-Based Enforcement

The fear that drives organizations away from ABAC is usually about enforcement complexity: building a policy engine inside every application that evaluates attribute combinations at request time. That complexity is real.

What many organizations miss is that attribute-based logic does not have to live inside the application. It can live in the provisioning layer, determining which roles get assigned to which users, while the application itself enforces simple role membership.

The pattern: the IGA platform holds the attribute-based assignment logic. The HRMS provides the authoritative source of user attributes (department, job title, location, employment status). When a new user is detected or an attribute changes, the IGA platform evaluates the assignment rules and provisions the appropriate role in the target application.

The application sees a user with the "Cardiology Physician" role (or just "Physician" scoped to cardiology by the IGA assignment). It does not need to evaluate the department attribute at runtime. The IGA platform handled that when it made the assignment.

In Zluri, this takes the form of WHEN-IF-THEN automation rules: WHEN a new user is detected, IF Department = Cardiology AND Role = Physician, THEN provision the Physician role in the clinical system and scope access to the Cardiology unit. The access logic is defined once in the governance platform and applied consistently without developer implementation work.

This is what practitioners mean when they describe "attribute-driven RBAC" — ABAC-style intelligence in the assignment layer, RBAC simplicity in the enforcement layer.

Segregation of Duties as a Negative Control

One underused lever in complex access environments is shifting from defining all permissible access (an endless positive definition problem) to defining forbidden combinations.

Segregation of Duties (SoD) rules specify access combinations that are not allowed: a user cannot simultaneously have the ability to prescribe controlled substances and approve their own prescriptions. A billing user cannot both create and approve invoices. An IT administrator cannot have access to both production systems and the audit logs that record production system changes.

In healthcare, SoD maps well to regulatory requirements: patient care access and billing access should not be held by the same user without explicit justification. Clinical documentation and quality assurance oversight may need to be separated.

The governance approach: rather than trying to perfectly define every permissible role combination, define the toxic combinations that are strictly prohibited. An IGA platform that monitors for SoD violations can flag conflicts automatically, generate exception workflows when a business justification requires an override, and maintain an auditable record of every violation and resolution.

This does not replace role design, but it provides a safety net that lets the role model operate with somewhat less precision than pure ABAC would require — because the guardrails catch the most consequential errors.

Role Mining: Cleaning Up the Existing Mess

Before designing the future access model, most organizations need to address the existing one. Hundreds of roles that accumulated organically are not cleaned up by designing new ones — someone has to analyze what access is actually in use and whether the current role structure reflects it.

Role mining is the process of analyzing actual access patterns to identify clusters of access that appear together across users, then proposing role definitions that encode those clusters. Rather than guessing which entitlements should be bundled, the analysis reveals which entitlements are actually bundled in practice.

Several practical approaches:

Bottom-up from application entitlements. Start with a specific application (Epic, Cerner, or a key clinical system), export all user-to-entitlement mappings, and look for clusters. Which combinations of entitlements appear together across many users? Those clusters are candidates for role definitions. This works without an IGA platform, though at scale it requires tooling.

Top-down from HR attributes. Correlate existing access against HR data: for users with the same job title and department, what access do they share? What access is inconsistent? The shared access defines the birthright role; the inconsistencies surface exceptions and potential over-provisioning.

Role composition reviews. Once roles are defined, run regular certifications where application owners review the entitlements within each role and confirm they are appropriate. This pushes maintenance to the people who understand the application, rather than expecting the IAM team to understand the clinical nuances of every system in the portfolio.

The consistent practitioner advice: IAM teams should facilitate role mining and governance, not own the role definitions. The teams that understand what a Cardiology Physician needs to do their job are in the Cardiology department and in Clinical IT, not in the IAM team. The IAM team provides the data, the methodology, and the governance framework. Domain owners make the decisions.

How Zluri Handles Hybrid Access Control at Scale

Zluri operates as the IGA control plane above the application access model, handling the attribute-based assignment logic that keeps applications themselves simple.

Attribute-driven provisioning. Zluri connects to the HRMS as the source of truth for user attributes and evaluates WHEN-IF-THEN rules to determine access assignments. Department, location, job title, employment status, and combinations thereof drive automatic provisioning of the appropriate application roles without manual IT intervention.

SoD violation detection. Zluri's SoD module identifies toxic access combinations across the connected application portfolio, flags violations automatically, and generates remediation workflows. Access combinations that a compliance audit would flag as risks surface in the platform before the audit.

GenAI role mining (roadmap). Zluri's roadmap includes AI-powered role mining that analyzes actual usage patterns across connected applications and generates role definition recommendations. Rather than manually correlating access data, the AI surfaces the clusters that define natural role boundaries and recommends policies based on observed behavior.

Access reviews scoped to role composition. Zluri's certification campaigns can be scoped to specific applications or role groups, routing review requests to the application owners or department heads who have the context to evaluate whether the role's entitlements still make sense. Results are captured in an auditable record.

What "Done" Looks Like

A mature hybrid access control model has these characteristics:

The role catalog is small enough that every role can be explained in plain English by a non-technical stakeholder. Aim for tens of roles, not hundreds.

Birthright access for well-defined roles provisions automatically on day one, driven by HR attributes through the IGA platform.

Organizational nuances (unit, location, patient relationship) are handled at the assignment layer through attribute rules, not by multiplying role variants.

Exceptions are managed through access requests, not by creating new roles. The catalog stays stable.

SoD rules catch the combinations that compliance and regulatory frameworks prohibit, providing a safety net that operates independently of the role model's precision.

Role composition is reviewed on a regular cadence by people who understand the applications, with results captured in the governance platform.

Getting there requires the upfront role mining work, the organizational discipline to hold the line on role proliferation, and the tooling to make attribute-driven assignment and access reviews operational rather than manual.