How should security teams design RBAC when users need access across multiple functions or projects?

Use atomic roles that map to clear business functions, then assign more than one role when a user legitimately spans responsibilities. This keeps permissions understandable, avoids hybrid mega roles, and makes reviews easier. The key control is additive access, where each role contributes a known slice of privilege and the final entitlement set remains transparent.

Why This Matters for Security Teams

When RBAC has to support users who span multiple functions or projects, the main risk is not simply over-permissioning. It is role confusion: teams start blending job duties into composite roles, then lose the ability to explain why any one person has a given entitlement. That makes access reviews noisy, slows approvals, and weakens segregation of duties. Current guidance from the OWASP Non-Human Identity Top 10 and NIST-style access governance both point toward clarity, traceability, and least privilege as the durable answer.

For human users, the design problem is usually organizational rather than technical: a product manager may need read access in one domain and approval rights in another, while an engineer may contribute across two delivery streams. If RBAC is built around exceptions, temporary merges, or ad hoc hybrid roles, the model stops reflecting business reality. That increases the chance that permissions persist after the need has ended. The practical lesson from NHIMG research is that identity failures often start with accumulation, not a single bad grant. In the Ultimate Guide to NHIs, excessive privilege is a recurring pattern, and the same design error appears in human RBAC when role boundaries are allowed to blur.

In practice, many security teams discover toxic role combinations only after a review, audit, or incident has already exposed how little the original role design was understood.

How It Works in Practice

The safest pattern is additive RBAC built from atomic roles. Each role should represent one business function, project, or control boundary, and the final permission set should be the sum of assigned roles rather than a custom role built for one person. That keeps the model readable and makes recertification straightforward. It also helps when a user legitimately spans responsibilities, because access can be explained role by role instead of defended as an exception.

Security teams usually implement this with a small set of rules:

• Define roles around stable business activities, not individuals or org chart titles.
• Keep each role narrow enough that reviewers can understand it without cross-referencing a dozen systems.
• Allow multi-role assignment when duties truly span functions, but avoid merging those permissions into a single mega role.
• Document which roles can coexist and which combinations violate segregation of duties.
• Review entitlement sets at the aggregate level so additive access remains transparent.

This approach aligns well with NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially the expectation that access be limited to what is necessary for the assigned function. It also matches the operational lessons in NHIMG’s 52 NHI Breaches Analysis, where excessive standing privilege repeatedly shows up as a root cause pattern. For teams managing both humans and service identities, the same logic applies: make entitlements composable, auditable, and easy to revoke. These controls tend to break down when role design tries to mirror every temporary project exception, because the access model becomes too granular to govern consistently.

Common Variations and Edge Cases

Tighter role design often increases administrative overhead, so organisations have to balance clarity against the cost of maintaining many small roles. That tradeoff is real, especially in matrixed environments where people split time across products, regions, or clients. Best practice is evolving, but the consensus still favors atomic roles plus additive assignment over broad composite roles.

One common edge case is the cross-functional operator who needs recurring access in two domains but only occasional access in a third. In that case, the recurring duties should be separate permanent roles, while the occasional need should be handled through time-bound elevation or a separate approval path. Another edge case is project-based access: if a project is temporary, the role should be temporary too, with explicit expiration or offboarding criteria. That keeps the entitlement model aligned to actual work, not historical convenience.

Teams should also be careful not to use “project role” as a dumping ground for unrelated permissions. Once that happens, access reviews lose meaning and SoD exceptions multiply. For broader identity governance context, the Ultimate Guide to NHIs — Key Challenges and Risks shows how quickly unmanaged privilege becomes operational risk, even before an incident is visible. The same failure mode exists in human RBAC when convenience outruns structure.

Related resources from NHI Mgmt Group

• How should security teams govern access reviews in complex Active Directory environments with nested groups and multiple domains?
• How should security teams approach CIAM deployment across multiple cloud marketplaces?
• How should security teams manage privileged access for vendors and remote users without relying on VPN access?
• How should security teams design role-based access so administrative tasks can be delegated without expanding full admin privileges?