Role Mining vs Attribute-Based Provisioning: Choosing the Access Model Your Data Supports

Identity programmes often pick between role mining and attribute-based provisioning on preference, when the deciding factor is the quality of the data each one consumes. Role mining reads the entitlements people hold today and proposes roles from the patterns; attribute-based provisioning reads HR and directory attributes and grants access by rule. Mining inherits every error in current access, and attribute rules inherit every error in the HR record. This guide compares the two on their data prerequisites, how each fails at scale (role explosion against attribute sprawl), the threat model, cost and effort, how each copes with non-human identities that have no HR record, and a hybrid path most organisations end up on. It is for identity governance leads, IAM architects and access model owners deciding where to invest next. Mining technique is covered in the Role Mining and Role Design Guide and rule design in the Birthright Access Design Guide; this page is about choosing.

Key takeaways

• Data quality decides, not philosophy. Role mining needs reasonably clean entitlement data; attribute-based provisioning needs accurate, coded, timely HR attributes. Measure both before committing budget to either.
• Mining describes the past, rules describe a policy. Mining is fast to start but reproduces existing over-privilege unless owners validate each candidate role. Attribute rules encode an intended policy but only cover access that is predictable from attributes.
• Each has its own scaling failure. Roles explode when every exception becomes a role; attribute rules sprawl when every exception becomes a rule condition. Both are symptoms of trying to automate access that should be requested.
• The hybrid path is the normal end state. Attribute rules for birthright and coarse layers, a small set of validated business roles for job functions, and request-based access for everything else.
• Non-human identities need a different anchor. Service accounts, workload identities and AI agents have no HR record, so neither HR attributes nor human peer groups describe them. Use owner, application and environment attributes, and workload-specific roles.

Definitions and scope

Role mining: bottom-up analysis of who holds which entitlements, clustering identities with similar access, often alongside HR attributes such as job code, to propose candidate roles. The output is a role catalogue that business and application owners validate, and a set of role assignments. The model it feeds is role-based access control (RBAC), standardised as ANSI/INCITS 359 and reflected in NIST SP 800-53 Rev. 5 AC-3(7).

Attribute-based provisioning: rules that grant and remove access automatically from identity attributes, for example "department equals Finance and worker type equals Employee grants the finance shared drive". It is how birthright access and most dynamic group membership work. It is related to, but narrower than, attribute-based access control (ABAC) as defined in NIST SP 800-162, where attributes of the subject, object, operation and environment are evaluated at the moment of each access request. Attribute-based provisioning evaluates attributes when they change and writes the result into accounts and groups; ABAC evaluates them at decision time. The wider model comparison is in the Authorisation Models Guide.

Both are ways of automating the provisioning decision. Neither replaces a request and approval path for access that cannot be predicted, which is where the Access Request and Approval Workflow Design Guide applies.

Side-by-side comparison

Data quality prerequisites

Entitlement hygiene for role mining

Mining clusters what exists. If 30% of a department holds an entitlement because one manager copied a user profile years ago, the algorithm will propose it as part of the department's role. Before mining, check:

• Leaver and orphan clean-up: accounts of people who have left, and accounts with no owning identity, distort every cluster. Remove them first.
• Entitlement catalogue: each entitlement needs a readable description and an owner, or validators cannot decide whether it belongs in a role. See the Entitlement Catalogue Guide.
• Coverage of connected applications: mining only sees applications the governance platform collects from. Roles mined from five systems will be incomplete for jobs that live in a sixth.
• Usage data: where available, last-used dates separate entitlements people hold from those they use, which is the quickest way to stop unused access becoming part of a role.

HR attribute accuracy for attribute rules

Rules act on whatever value the attribute holds, immediately. Before building rules, check:

• Coded, not free text: SCIM (RFC 7643) defines title as a free-text value such as "Vice President", and an enterprise extension (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User) carrying employeeNumber, costCenter, organization, division, department and manager. Base rules on coded values such as department or cost centre codes, not on titles.
• Worker type is populated and controlled: RFC 7643 lists typical userType values (Contractor, Employee, Intern, Temp, External, Unknown) but allows any value. A rule keyed on "Employee" silently misses a record entered as "Permanent".
• Timeliness: a transfer recorded in HR two weeks after the person moves means two weeks of old access and missing new access.
• Write protection: anyone who can edit an attribute can grant themselves the access it drives. Microsoft's dynamic membership documentation specifically warns about on-premises Active Directory attributes that allow SELF write and advises restricting self-service write on attributes used in security-sensitive groups.

The Identity Data Quality and Authoritative Sources Guide covers how to measure and fix both data sets.

A quick readiness test

If entitlement data is poor and HR data is good, start with attribute rules for coarse layers and use them to clean up before mining. If HR data is poor and entitlement data is good, mine within the populations HR data does describe reliably, and fix HR data in parallel. If both are poor, neither will work: fix data first.

Role explosion vs attribute sprawl

Both models break the same way: someone tries to automate an access decision that is really an exception.

• Role explosion: a role per region, per project, per exception. Symptoms are hundreds of near-duplicate roles, roles with one member, and role names nobody outside IT understands. Reviews become meaningless because reviewers cannot tell what a role grants.
• Attribute sprawl: rules with long "and not" lists, new attributes invented to make one rule work (a custom flag that exists only for one team), or rules keyed on values that only a handful of people hold. Symptoms are rules nobody can explain and HR fields repurposed as access switches.

A useful signal for both: the share of access granted automatically. When automation already covers most access and each further step adds many roles or rule conditions for little extra coverage, stop and let the remainder be requested.

Threat model for each

Role mining

• Over-privilege laundering: excess access that was granted by mistake becomes "normal" once it is inside a role, and stops showing up as an outlier in reviews.
• Segregation of duties conflicts baked in: two conflicting entitlements that commonly appear together can be mined into one role. Every role needs a check against the Segregation of Duties Guide matrix before publishing (NIST SP 800-53 Rev. 5 AC-5).
• Movers accumulating roles: without an attribute that removes the old role, people keep it after a transfer.

Attribute-based provisioning

• Attribute tampering: anyone who can change a department code, or a user who can write to their own directory attributes, can grant access. The HR system and the identity sync become privileged systems.
• Bad data at scale: an HR bulk import with a wrong cost centre can grant or remove access for hundreds of people in one cycle.
• Silent gaps: people whose records do not match any rule get nothing automatically and are then provisioned by hand, outside the model.

Both models depend on the leaver path: the same HR event must remove access, as NIST SP 800-53 Rev. 5 PS-4 and PS-5 expect for termination and transfer. The Identity Lifecycle Event Design Guide covers the event design.

How identity platforms express attribute rules

Platforms are listed alphabetically. Each section states what the vendor documentation describes, as of November 2026.

Availability (Microsoft Entra ID): Microsoft documents that each unique user who is a member of one or more dynamic groups needs a Microsoft Entra ID P1 or Intune for Education licence.

Availability (Okta): Okta documents that only super admins and org admins can edit group rules.

Both platforms keep privileged assignment out of attribute rules, which matches good practice: administrative roles belong behind approval and just-in-time access, whatever the model.

Fit for non-human identities

Service accounts, workload identities, API keys and AI agents break both models' assumptions. They have no HR record, so there is no department, job code or manager feed; and human peer groups mean nothing to them, so clustering them with people produces nonsense roles.

• Replace HR attributes with ownership attributes: owning team, application, environment (production or not), data classification and expiry date. These must come from an authoritative source, usually the application or service catalogue. See the NHI Ownership Guide.
• Mine permissions used, not permissions held: for machine identities, the useful analysis is per identity, comparing granted permissions with those actually exercised, then right-sizing to a workload-specific role or policy. Cloud platforms' permission usage data is the practical input.
• Never reuse human business roles: a service account that holds an employee role inherits whatever that role gains later.
• Owner departure is the trigger: when the human owner leaves, the NHI needs a new owner before anything else changes. That event comes from the human's HR record, which is where attribute logic and NHI governance meet.

The hybrid path

1. Measure both data sets: run the readiness test above per population, not organisation-wide. Finance may have clean data while engineering does not.
2. Fix the leaver path first: automate removal from the HR termination event before anything else, because both models depend on it.
3. Build coarse attribute layers: enterprise, worker type, location and department layers as birthright rules, each driven by one coded attribute, adding and removing access. Run them in report-only mode first, compare the result with current access, and resolve differences before enforcing.
4. Mine within the layers: with birthright explained by rules, mine what remains per job code. Target the common core, not full coverage; the live role design guide uses entitlements held by roughly 80 to 90% of a job code as a starting threshold.
5. Validate with owners: business and application owners confirm or trim each candidate role, with usage data shown; check every role against the segregation of duties matrix.
6. Assign roles by attribute where possible: a validated business role can itself be assigned by a job code rule, so movers lose it automatically.
7. Leave the rest to requests: sensitive, privileged and unpredictable access goes through request and approval with time limits.
8. Roll back safely: keep previous group memberships exported before enforcing a new rule or role, and switch a misbehaving rule back to report-only rather than deleting it.

Decision guidance

• Choose attribute rules first when: HR data is coded and timely, the population is large and homogeneous (retail, call centres, field staff), and mover volume is high.
• Choose role mining first when: HR data is weak but entitlement data is collected and owned, jobs need bundles across several systems, and auditors expect role-based evidence.
• Choose neither yet when: orphaned accounts are widespread and HR attributes are free text. Spend the budget on data quality.
• Small organisations: a few attribute-driven groups in the identity provider and a handful of documented roles usually cover most access; formal mining tools rarely pay back below a few hundred staff.
• Large organisations: run both, by population, with a role owner and an attribute steward named for each layer, and track automation coverage per business unit rather than globally.

Worked scenario: a regional insurer

An insurer with 6,000 staff across claims, underwriting, finance and IT wants to reduce manual provisioning tickets and stop failing access reviews.

1. Assessment: HR has coded department and location for 98% of employees, but contractors are held in a spreadsheet. Entitlement data covers twelve applications; 9% of accounts have no matching active identity.
2. Decision: attribute rules first for employees, because HR data is strong. Contractors are moved into the HR system as a separate worker type before any rules apply to them; the Contractor Identity Lifecycle Guide sets the pattern.
3. Clean-up: orphaned accounts are reviewed and removed before mining, so they do not distort clusters.
4. Layers: four birthright layers go live after a month in report-only mode, which exposes a department code used for two different teams. HR splits the code before enforcement.
5. Mining: the claims and underwriting job codes are mined. Claims produces three business roles with clear owners. Underwriting produces fourteen candidates, most single-purpose; owners keep four and move the rest to request-based access.
6. Segregation of duties: one mined finance role combined payment creation and approval; it is split before publishing.
7. Service accounts: the 400 service accounts found are excluded from both models, given owners from the application catalogue and right-sized from usage data.

The outcome is a smaller model that auditors can follow: rules explain who gets the basics, a few owned roles explain job access, and requests explain the rest.

Detection and measurement

• Automation coverage: percentage of entitlements granted by rule or role rather than by request or by hand, per population.
• Role health: roles per 100 users, single-member roles, and roles without an owner or description.
• Rule health: rules with exclusion lists, attributes used by only one rule, and rules without a named steward.
• Attribute accuracy: HR records failing validation (missing or unknown department, worker type or manager), and median delay between a real move and the HR change.
• Attribute change monitoring: alert on changes to attributes that drive access when made outside the HR feed, and on bulk changes above a threshold before they are applied.
• Mover residue: access still held 30 days after a transfer that the new rule set or role would not grant.

Framework mapping

Practitioner checklist

• Measure entitlement hygiene and HR attribute accuracy per population before choosing a model.
• Automate removal on the HR leaver event before building any rules or roles.
• Base rules on coded attributes from the authoritative source, never on job titles.
• Restrict who can write each attribute that drives access, including self-service directory attributes.
• Run new rules in report-only mode and reconcile against current access before enforcing.
• Remove orphaned and leaver accounts before role mining.
• Have owners validate every mined role, with usage data, and check it against the segregation of duties matrix.
• Stop automating when coverage gains need many new roles or rule conditions; leave the rest to requests.
• Keep service accounts and AI agents out of human roles and rules; anchor them on owner and application attributes.

Standards and references

• NIST: SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• NIST: Role Based Access Control project (ANSI/INCITS 359)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• IETF: RFC 7643 SCIM Core Schema
• Microsoft Learn: Dynamic membership rules for groups in Microsoft Entra ID
• Okta: About group rules

Related NHI Mgmt Group resources: Role Mining and Role Design Guide · Birthright Access Design Guide · Authorisation Models Guide · SCIM Provisioning Guide · Identity Data Quality and Authoritative Sources Guide