TL;DR: Role modelling is increasingly used to streamline access assignment, lifecycle changes, and review processes, but the article also shows how complexity, manual monitoring, and governance gaps can turn role maintenance into a security liability rather than an efficiency gain, according to Zluri. The deeper issue is that access models often assume roles stay stable long enough to be designed, assigned, and reviewed cleanly, which is no longer true in fast-changing environments.
NHIMG editorial — based on content published by Zluri: Security & Compliance Everything You Need To Know About Role Modeling In 2026
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern role modelling in fast-changing environments?
A: Security teams should govern role modelling as a living lifecycle process, not a one-time design effort.
Q: Why does role modelling often fail to reduce access risk in practice?
A: Role modelling fails when organisations confuse grouping access with governing access.
Q: What breaks when access reviews are not connected to remediation?
A: When access reviews do not trigger actual deprovisioning or modification, the organisation gets documentation without control.
Practitioner guidance
- Separate role mining from role approval. Use mined entitlement data to propose patterns, then require business and security validation before a role is allowed into provisioning or certification workflows.
- Build retirement criteria into every role. Define when a role is obsolete, which entitlements must be removed, and who must approve decommissioning so stale access does not survive organisational change.
- Tie certifications to auto-remediation. When reviewers decline or reduce access, trigger deprovisioning or modification playbooks immediately so the certification produces a real access change.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step onboarding workflow configuration for assigning apps by employee role.
- Practical access request and approval flow detail for movers and role changes.
- Auto-remediation setup for certification outcomes that remove or modify access.
- Workflow examples for decommissioning outdated access during offboarding.
👉 Read Zluri's guide to role modelling and role-based access management →
Role modeling in 2026: where manual access governance breaks?
Explore further
Role modelling is only effective when role lifecycle governance is treated as a control, not a convenience. The article focuses on automation, but the real governance question is whether roles are being created faster than they are retired, reviewed, and narrowed. In identity programmes, role modelling becomes dangerous when it is mistaken for a one-time design project rather than an ongoing control surface. The practitioner conclusion is that role creation without role sunset is just privilege accumulation with better branding.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who should own role definitions and role retirement decisions?
A: Role definitions should be owned jointly by business process owners, IAM or IGA teams, and security governance. Business owners define necessity, IAM validates structure, and security confirms least-privilege and segregation-of-duties requirements. Role retirement should never be left to application admins alone.
👉 Read our full editorial: Role modeling in 2026 exposes the limits of manual IAM