Skip to main content
Identity Authority
Category: Access Control Models

Role Discovery

Simply put

Role discovery is an analytical technique that examines the access permissions users currently hold and groups together users with similar permissions to suggest candidate access roles. It is used to help organizations design a role structure rather than to grant access in real time.

Formal definition

Role discovery is a component of role mining within identity governance and administration (IGA) that analyzes existing identity-to-permission assignments and clusters identities exhibiting similar permission patterns into candidate roles. It is an analytical, design-time step that produces proposed role definitions for review; depending on deployment, these candidate roles typically feed subsequent role engineering, certification, and RBAC role modeling activities. It is distinct from runtime access enforcement and does not itself provision or authorize access.

Why it matters

As organizations scale, users tend to accumulate permissions granted directly or ad hoc over time, producing sprawling and inconsistent access assignments that are difficult to review, certify, or reason about. Role discovery addresses this by analyzing the permissions users already hold and grouping identities with similar patterns into candidate roles, giving governance teams an empirical starting point for a role structure rather than designing one purely top-down. This is a foundational input to role-based access control (RBAC) modeling, where well-formed roles reduce the number of individual assignments that must be managed and certified.

Because role discovery operates at design time and produces proposed role definitions for human review, its value lies in surfacing structure that already exists in the data and highlighting where access is inconsistent or over-broad. Cleaner candidate roles can make downstream identity governance activities, such as access reviews, certification campaigns, and segregation-of-duties analysis, more tractable, since reviewers can evaluate coherent roles instead of long lists of discrete permissions.

It is important to treat role discovery as an analytical aid rather than an authority on access. The technique suggests candidate roles based on current permission patterns, which may themselves reflect accumulated errors or excessive grants; discovered roles therefore require review before adoption. Role discovery does not itself provision, grant, or enforce access at runtime.

Who it's relevant to

Identity Governance Leads
Role discovery gives governance leads an empirical basis for designing a role structure from existing permission data, and its candidate roles feed downstream certification and RBAC role modeling activities. They should treat discovered roles as proposals requiring review rather than finished definitions.
IAM Engineers and Role Engineers
Engineers responsible for role engineering use the candidate roles produced by discovery as a starting point to refine and formalize RBAC roles. Understanding that discovery is a design-time analytical step, separate from provisioning and runtime enforcement, helps set correct expectations for where these outputs fit in the lifecycle.
Security Architects
Architects planning an access model can use role discovery to ground RBAC design in how permissions are actually assigned today, rather than designing roles purely top-down. They should account for the fact that current assignments may include accumulated over-broad grants that candidate roles could inherit.
Compliance and Audit Officers
Coherent candidate roles can make access reviews, certification, and segregation-of-duties evaluation more tractable by letting reviewers assess roles rather than long lists of individual permissions. Officers should remember that discovery reflects existing access patterns and does not by itself validate that access is appropriate.

Inside Role Discovery

Role Mining
The analytical process, typically applied within IGA programs, of examining existing entitlement and access assignment data to identify patterns of commonly co-occurring permissions that can be grouped into candidate roles. Role mining is generally the data-driven core of role discovery.
Bottom-Up Analysis
A discovery approach that starts from granular entitlements actually assigned to users and aggregates them into proposed roles based on observed access patterns. It reflects what access exists rather than what business logic dictates.
Top-Down Analysis
A complementary approach that derives roles from business structure, job functions, and organizational context. In most deployments, role discovery combines top-down and bottom-up methods rather than relying on either alone.
Entitlement Data Sources
The inputs to discovery, which typically include directory group memberships (for example from LDAP directories), application-level permissions, and provisioning records collected through the IGA platform. Data quality directly affects discovery outcomes.
Candidate Roles
Proposed role definitions produced by the discovery process, representing clusters of entitlements that are subsequently reviewed, refined, and validated before being promoted to production roles in an RBAC model.
Role Model Context
Role discovery is an administration and governance (IGA) activity that shapes the roles later used in RBAC; it is distinct from the runtime enforcement of those roles by a policy decision point or policy enforcement point.

Common questions

Answers to the questions practitioners most commonly ask about Role Discovery.

Is role discovery the same thing as assigning roles to users?
No. Role discovery (often called role mining) is the analytical process of examining existing entitlements and access patterns to propose candidate roles, typically as part of role engineering within an IGA program. Assigning those roles to users is a separate provisioning and lifecycle activity that occurs after roles are defined and validated. Discovering a role structure does not, by itself, grant anyone access; the resulting roles must still be reviewed, approved, and provisioned. Conflating the two blurs the design-time governance concern with the runtime and lifecycle administration concern.
Does running role discovery mean my organization is doing RBAC and no longer needs attribute- or policy-based controls?
Not necessarily. Role discovery is most closely associated with building or refining an RBAC model, but discovering roles does not make RBAC universally superior to or a replacement for ABAC, PBAC, or ReBAC. In many deployments organizations combine models, for example using discovered roles for coarse-grained access while relying on attribute- or policy-based rules for finer-grained decisions. Role discovery informs the RBAC portion of a design and does not obligate an organization to enforce access exclusively through roles.
What data sources are typically needed to perform role discovery?
In most deployments role discovery draws on current entitlement assignments and account data, often collected from directories, target application permission stores, and provisioning records aggregated within an IGA platform. Some approaches also incorporate access usage or activity data where available. The exact sources and their quality vary by environment, and incomplete or stale entitlement data can significantly affect the usefulness of discovered roles.
How do top-down and bottom-up role discovery approaches differ in practice?
Top-down approaches typically derive candidate roles from business structure, job functions, or organizational context, describing what access a function should have. Bottom-up approaches, often referred to as role mining, analyze existing entitlement assignments to cluster common patterns into candidate roles. Many programs blend both, using bottom-up analysis to surface patterns and top-down business input to validate and name roles. The appropriate balance depends on the organization and the quality of available data.
How can role discovery help address segregation of duties concerns?
Because role discovery examines aggregated entitlements, it can help surface combinations of access that may conflict with segregation of duties policies, and the resulting role definitions can be checked against SoD rules before roles are finalized. However, role discovery itself is a design-time governance activity; enforcing SoD at assignment time and during access certification remains a separate control. Whether conflicts are detected depends on how SoD policies are defined and applied within the IGA tooling.
What are common pitfalls that limit the effectiveness of role discovery?
Frequently cited challenges include poor or incomplete underlying entitlement data, role explosion when candidate roles are too granular, and overly broad roles that grant excessive access. Discovered roles also require ongoing maintenance, since access patterns and business needs change over time. The relative impact of these issues varies by deployment, and discovered roles generally should be treated as candidates for human review rather than final definitions.

Common misconceptions

Role discovery automatically produces a finished, production-ready role model.
Discovery typically generates candidate roles that require human review, validation against business context, and refinement. Output quality depends on the completeness and accuracy of the underlying entitlement data, and results usually still need certification and segregation-of-duties checks before use.
Role discovery enforces access or makes authorization decisions.
Role discovery is a governance and administration concern focused on defining roles from existing access patterns. It does not perform runtime authorization; enforcement happens separately through mechanisms such as a PDP and PEP. Discovering a role is not the same as granting or evaluating access at request time.
Bottom-up role mining alone yields correct, business-meaningful roles.
Bottom-up mining reflects existing access, including accumulated or excessive entitlements, so it can reproduce over-provisioning. In most deployments it is combined with top-down, business-driven analysis to produce roles that align with actual job functions.

Best practices

Combine top-down (business-function-driven) and bottom-up (entitlement-driven) analysis rather than relying on a single approach, since each surfaces different aspects of a workable role model.
Assess and remediate the quality of source entitlement data from directories and applications before mining, because discovery output is only as reliable as its inputs.
Treat mined roles as candidate roles subject to human review, and validate them against business context before promoting them to production.
Incorporate segregation-of-duties and access certification checks into the review of candidate roles so that discovery does not carry forward toxic combinations or accumulated excess access.
Keep role discovery scoped as an IGA activity distinct from runtime enforcement, and coordinate with the teams responsible for the PDP/PEP that will consume the resulting roles.
Re-run discovery periodically to account for organizational and access changes, since a role model that fit at one point can drift as entitlements evolve.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.