Roles are meant to make access simple: give someone a role and they get what their job needs. In practice, many organisations end up with thousands of roles, many nearly identical, some with nobody assigned and others granting far more than any job needs. Role explosion makes reviews meaningless, provisioning slow and least privilege impossible. This guide explains how to design a role model that stays manageable, how to use role mining to discover roles from existing access, and how to maintain roles over time, including for non-human identities.
Key takeaways
- Aim for a small number of well-understood roles covering most access, with requests and attributes handling the rest. Chasing 100% role coverage creates role explosion.
- Use a layered model: business roles (what a job needs) built from technical or application roles (what a system grants).
- Role mining finds patterns in existing access, but existing access includes errors. Validate mined roles with business owners.
- Every role needs an owner, a description and periodic review of its contents.
Types of role
| Role type | Describes | Example |
|---|---|---|
| Birthright role | Access everyone in a population gets | Email, intranet, HR self-service for all employees |
| Business role | Access a job function needs across systems | "Accounts Payable Clerk" |
| Technical / application role | A bundle of permissions in one system | "ERP AP Invoice Entry" |
| Privileged role | Administrative access, usually granted just in time | "Database Administrator – Production" |
Business roles contain technical roles. Keep privileged roles separate and time-bound. See the JIT Access and Zero Standing Privilege Guide.
Top-down and bottom-up design
- Top-down: start from the organisation's job functions and processes, and define what each needs. Aligns with the business but is slow and can miss real-world needs.
- Bottom-up (role mining): analyse existing entitlements to find groups of access commonly held together. Fast, but reproduces existing over-privilege.
- Hybrid: mine candidate roles, then validate and clean them with business and application owners. This is the most practical approach.
Role mining in practice
- Prepare data: collect entitlements from key applications and HR attributes (job code, department, location). Clean up leavers and obvious orphaned access first.
- Cluster: group users by shared entitlements and by HR attributes; identify entitlements held by, say, 80–90% of people in a job code.
- Propose candidate roles: the common core becomes a role; the rest stays as requestable access.
- Validate: business and application owners confirm or trim each role; remove entitlements that are common but unnecessary.
- Check SoD: ensure no role contains conflicting permissions. See the Segregation of Duties Guide.
- Pilot and roll out: assign roles to a pilot group, compare against current access and handle exceptions.
Avoiding role explosion
- Do not create a role for every exception; use requests or attribute-based rules instead. See the Authorisation Models Guide.
- Parameterise roles with attributes (for example, region) rather than duplicating them per region.
- Set naming standards and require descriptions in business language.
- Retire roles with no members or unchanged for long periods without review.
- Track metrics: number of roles, members per role, percentage of access granted by roles versus requests.
Maintaining roles
- Assign a role owner accountable for contents and membership rules.
- Review role definitions periodically, separately from user access reviews. See the Access Reviews Guide.
- Monitor usage: remove entitlements from roles if most members never use them.
- Version role changes and test for SoD impact before publishing.
Roles for non-human identities
- Do not reuse human business roles for service accounts or AI agents.
- Define workload-specific roles or policies, granted per application and environment.
- Use permissions-used analysis in cloud platforms to right-size NHI roles.
- For AI agents, keep roles narrow and pair them with task-scoped access. See the AI Agent Authorisation Guide.
Practitioner checklist
- Define a layered role model: birthright, business, technical and privileged.
- Clean data before mining; use hybrid mining with business validation.
- Target the common core of access, not full coverage.
- Check every role for SoD conflicts.
- Give every role an owner, description and review schedule.
- Monitor role usage and retire unused roles and entitlements.
- Design separate, narrow roles for NHIs and AI agents.
Standards and references
Related NHI Mgmt Group resources: IAM and IGA Basics · Joiner-Mover-Leaver Guide · IGA Buyer's Guide · Authorisation Models Guide
