How should security teams manage organization-wide access when users need more than one role?

Why This Matters for Security Teams

When users need more than one role, the real risk is not the extra label itself but the permission combination that role sprawl creates over time. Security teams often start with clean RBAC, then add exceptions for finance, engineering, support, and incident response until access becomes hard to reason about. That is where excessive privilege, weak segregation of duties, and audit friction usually emerge.

NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks shows how quickly access problems compound when identities and permissions are left to grow without lifecycle discipline. This pattern is not limited to service accounts. The same logic applies to people who need overlapping roles, especially in smaller teams where one person may act as operator, approver, and responder.

Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both reinforce the same operational point: identity design should stay understandable, reviewable, and constrained to what is actually needed. In practice, many security teams discover access creep only after an audit finding, an overbroad exception, or a misused shared entitlement has already occurred.

How It Works in Practice

The most effective model is to treat access as a composition problem rather than a role explosion problem. Instead of creating a bespoke role for every combination, teams define small, reusable roles or permission sets, then assign the minimum set needed for a person’s job. That keeps access intelligible and reduces the temptation to create “super roles” that silently accumulate privilege.

For organisations with mature IAM, the next step is to separate assignment from activation. A person may be eligible for multiple roles, but only activate the one needed for the current task, ideally with time bounds and approval logic where sensitivity is high. This is where RBAC often needs to be supplemented by JIT provisioning, so elevated access exists only for the task window and is automatically revoked afterward.

• Use small base roles with clear purpose, not broad catch-all bundles.
• Review role intersections for conflicts, especially finance, admin, and production access.
• Require periodic recertification of multi-role assignments, not just the roles themselves.
• Prefer group-based assignment where it simplifies control and auditability.
• Apply separation of duties checks before access is granted, not only during audit.

This approach aligns with lifecycle discipline described in NHIMG’s Ultimate Guide to NHIs and with NIST control thinking in NIST SP 800-53 Rev. 5 Security and Privacy Controls. The control objective is simple: keep the permission union necessary, visible, and reversible. These controls tend to break down in fast-moving environments where teams create temporary exceptions in production and never come back to collapse them into normal access paths.

Common Variations and Edge Cases

Tighter access design often increases administration overhead, so organisations have to balance operational speed against review burden. That tradeoff becomes sharper in departments where people genuinely wear multiple hats, such as security operations, platform engineering, and internal IT support.

Best practice is evolving for cases where role-based access alone is too coarse. Some teams use policy-based access decisions, context-aware approvals, or attribute-driven rules for the most sensitive actions, while keeping ordinary access in standard roles. There is no universal standard for this yet, but the direction is clear: the more dynamic the job, the less useful static role bundles become.

Two edge cases deserve special care. First, emergency access should not be solved by permanently expanding a user’s normal roles. Second, delegated admin and break-glass accounts need separate review because they can bypass ordinary separation of duties. NHIMG’s Top 10 NHI Issues is useful here because the same failure patterns show up when privileged access is left standing longer than necessary. For teams operating under audit pressure, the goal is not fewer roles at any cost, but cleaner role composition with stronger expiry, evidence, and cleanup.

Related resources from NHI Mgmt Group

• How should security teams use AI to reduce role sprawl in access modeling programs?
• How should security teams handle short-lived access when users need to extend it without creating standing privilege?
• How should security teams implement policy-based access control in hybrid environments without creating brittle role sprawl?
• How should security teams run access reviews for non-human identities?