Every application update introduces new roles. Every team that customizes an application creates new roles for their specific use cases. Every integration project creates service roles. The organization that has deployed 150 SaaS applications has deployed 150 independent role models, each with its own role population, each governed — or not — independently, and none of them visible to the identity governance program that was built around the on-premises directory.
How Role Explosion Happens
SaaS role models are designed by the SaaS vendor for operational flexibility. Most SaaS applications provide a base set of predefined roles — administrator, editor, viewer — and the capability to create custom roles with specific permission sets. The operational teams that use the application create custom roles for their specific needs: the marketing team's content manager role, the sales team's regional manager role, the support team's tier-two escalation role. These custom roles are created by the people who need them, when they need them, without governance review.
Over time, the custom role population grows. Roles created for temporary projects remain after the project ends because no one is triggered to remove them. Roles created for organizational structures that have since changed remain because the organizational change did not include a SaaS role cleanup. Roles created with overly broad permissions because the minimum necessary permission set was not known at creation remain because the access review process does not audit SaaS custom role definitions — it only audits user-to-role assignments.
The access review that examines which users have which roles confirms whether user-to-role assignments are appropriate. It does not examine whether the roles themselves are appropriately scoped. A user with an appropriately assigned role that has accumulated excessive permissions has passed the access review while retaining the excessive access.
Why Nobody Is Cleaning It Up
No Single Owner for the SaaS Role Portfolio
Individual SaaS applications have owners — typically the business team that uses the application. The SaaS role portfolio across all applications has no single owner. The identity governance program owns the on-premises role model. The SaaS applications are owned by business teams. The cross-application role governance that would identify role sprawl and excess permission accumulation across the SaaS portfolio requires a governance function that exists between the business owners and the IAM team — a function most organizations have not created.
Access Reviews That Do Not Include Role Permission Audits
Quarterly access reviews focus on user-to-role assignments: does this user need this role? They do not focus on role permission audits: does this role need these permissions? The role with the overly broad permission set assigned to an appropriate user passes the access review. The excessive permission in the role is invisible to an access review designed around user-to-role assignment rather than around role definition adequacy.
No Technical Mechanism for Cross-SaaS Role Visibility
The identity governance platform that provides visibility into on-premises roles and user-to-role assignments typically does not have connectors to all SaaS applications in the organization's portfolio. The visibility it provides is the visibility its connectors support. SaaS applications that are not connected to the governance platform are governed outside the platform — if they are governed at all — through application-level access reviews that are not connected to the enterprise identity governance program.
Making Progress on the Problem
Role explosion in SaaS environments cannot be fully resolved without significant investment. The investment required: SaaS application discovery to identify what applications are in use and what their role models look like, identity governance platform integration for the highest-risk SaaS applications, access review process extension to include role permission scope alongside user-to-role assignment, and a governance function with ownership of the cross-application role model.
The practical starting point is the SaaS applications that are highest-risk — those with access to the most sensitive data, those with administrative access to other SaaS applications through integrations, and those with the broadest user populations. Extending identity governance to these applications first produces the most significant risk reduction for the available investment. The remainder of the SaaS portfolio is a longer-term remediation backlog.
The access review extension to include role permission scope is the highest-leverage change that does not require new tooling. Reviewing not only which users have which roles but whether each role's permissions are limited to what the role's purpose requires identifies permission accumulation in the existing review process. It adds complexity to the review. It produces governance value that the assignment-only review does not.
Extend access reviews to include role permission scope. Connect the highest-risk SaaS applications to the identity governance program. Create ownership for the cross-SaaS role model. None of these is optional in a SaaS-heavy environment.
Audit the roles, not just the user-to-role assignments. The role with excessive permissions assigned to an appropriate user has passed the access review and is still a governance gap.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.