How should security teams design authorization models when users need multiple roles in one application?

Why Multiple Roles Need More Than Simple Role Stacking

When a user needs access across finance, support, and operations in one application, additive role assignment is often the least confusing starting point. The risk is not the union model itself, but unmanaged accumulation over time. Once roles are combined, teams must still enforce least privilege, separation of duties, and periodic access review or the effective permission set becomes broader than anyone intended.

This matters because role-based design is easy to describe but hard to keep clean in practice. Security teams often discover that users have inherited overlapping entitlements, temporary exceptions, and old project access long after the business need has changed. NIST SP 800-53 Rev 5 Security and Privacy Controls treats access enforcement and review as ongoing control activities, not one-time setup decisions. NHIMG research shows the same operational pattern in NHI environments: 97% of NHIs carry excessive privileges, which is a useful warning sign for any identity model that allows permissions to accumulate unchecked. See also Ultimate Guide to NHIs.

In practice, many security teams encounter privilege creep only after an audit finding or incident response review, rather than through intentional entitlement design.

How to Design Additive Authorization Without Losing Control

The practical model is to make each role narrowly scoped, then define the effective access as the union of assigned roles. That works only if roles are built from stable business functions, not from every edge-case workflow. Each role should have a clear owner, a documented purpose, and a review cadence. If a user needs temporary elevated access, use time-bound approval rather than a permanent role exception.

Implementation usually works best in three layers:

• Define baseline roles by job function, then separate privileged actions into distinct roles.
• Evaluate conflicting combinations with separation-of-duties rules before access is granted.
• Track effective permissions, not just assigned roles, so reviewers can see what the user can actually do.

This is where governance and enforcement have to align. The union of roles should be computed at runtime, but entitlement decisions still need policy-backed guardrails, especially for sensitive actions like payments, approval workflows, data export, or admin changes. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames access control, authorization, and review as operational controls that must be repeatable. For broader identity lifecycle guidance, the Ultimate Guide to NHIs highlights why over-privilege persists when visibility and revocation are weak. These controls tend to break down when role definitions are too granular, because administrators start creating one-off roles for every exception and the model becomes unmanageable.

Common Variations and Edge Cases

Tighter role control often increases administrative overhead, so organisations need to balance simplicity against risk reduction. That tradeoff becomes visible in applications with matrixed duties, delegated approvals, or customers who operate in more than one business unit. Best practice is evolving, but there is no universal standard for handling every combination of multiple roles inside one app.

Common edge cases include users who hold both requester and approver roles, shared administrative users, and merger scenarios where duplicate job functions exist across legacy systems. In those cases, additive roles alone are not enough. Teams should add conflict rules, just-in-time elevation for sensitive tasks, and periodic attestation of the effective access set. When possible, use application-level policy to block mutually exclusive permissions even if both roles are assigned.

NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which underscores how quickly permission drift becomes invisible once identity inventories get messy. Where the business truly needs overlapping roles, the safest pattern is to make exceptions explicit, short-lived, and reviewable rather than embedding them permanently into broad entitlements.

Related resources from NHI Mgmt Group

• How should security teams design authorization checks for multiple actions on the same resource in one request?
• What do security teams get wrong about using APIs to manage user roles and application licences?
• How should security teams govern MongoDB users with roles across multiple databases?
• How should security teams design account linking when users can sign in through multiple identity providers?