A multiple-role model lets one user or organisation membership receive permissions from more than one role at the same time. This reduces the need for oversized combined roles and can make access easier to manage across departments or projects. The control still needs governance, because overlapping roles can quickly recreate permission sprawl.
Expanded Definition
Multiple roles describe a governance pattern where one identity can receive entitlements from more than one role at the same time. In NHI and IAM programs, this is used to avoid creating large composite roles that bundle unrelated access for every team, workload, or project. The design can support cleaner administration, but it also demands strict oversight because role overlap can hide accumulated privilege and make review harder.
Definitions vary across vendors when multiple roles are discussed alongside role chaining, nested roles, or policy layering, so the term should be used carefully. In practice, the key question is not whether multiple roles are allowed, but whether the resulting effective access is understandable, reviewable, and bounded by least privilege. That is why role design should be paired with NIST Cybersecurity Framework 2.0 alignment and explicit entitlement governance. The most common misapplication is treating multiple roles as harmless convenience, which occurs when administrators grant overlapping access without revalidating the combined effective permissions.
Examples and Use Cases
Implementing multiple roles rigorously often introduces review complexity, requiring organisations to weigh delegation flexibility against the cost of analysing combined privileges.
- A service account holds one role for read-only telemetry and another for write access to a narrow deployment queue, instead of one broad operational role.
- An AI agent used in customer support inherits one role for ticket lookup and a separate role for redacted case-note updates, limiting the blast radius if one permission path is abused.
- A build pipeline receives one role for pulling dependencies and another for signing artefacts, which keeps separate control points for supply chain integrity.
- A third-party integration gets one role for event ingestion and another for scoped storage access, reflecting the needs of Ultimate Guide to NHIs guidance on visibility and lifecycle control.
- A platform team assigns separate roles for incident response and routine administration so that emergency access can be reviewed independently from day-to-day duties.
These patterns are most defensible when each role has a narrow purpose, the combined effective access is documented, and periodic review checks whether the identity still needs all assigned roles.
Why It Matters in NHI Security
Multiple roles can either reduce permission sprawl or conceal it, depending on how carefully the combination is governed. For NHI programs, the risk is that a service account or agent accumulates enough overlapping roles to bypass the intent of least privilege while still appearing compliant at the individual-role level. That creates blind spots in access reviews, secrets governance, and incident response. NHIMG research shows that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, which makes overlap especially dangerous when role inheritance is poorly documented, according to Ultimate Guide to NHIs.
Properly controlled multiple-role assignment also supports Zero Trust by forcing access to be explicit, bounded, and auditable rather than hidden inside oversized umbrella permissions. That aligns with NIST Cybersecurity Framework 2.0 expectations for access control and ongoing risk management. Organisations typically encounter the consequences only after an audit, breach review, or failed privilege cleanup, at which point multiple-role analysis becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Multiple roles can create hidden privilege accumulation across NHI entitlements. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions management covers role assignment and least-privilege enforcement. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, continuously verified access regardless of role count. | |
| NIST SP 800-63 | AAL2 | Assurance guidance informs how strongly role-bound access should be protected and governed. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can inherit multiple roles that widen tool and data exposure. |
Treat each role as separately justified and continuously recheck combined access before allowing use.
Related resources from NHI Mgmt Group
- How should security teams govern MongoDB users with roles across multiple databases?
- How should universities govern identity when people hold multiple academic roles?
- How should teams govern Oracle access when roles span multiple enterprise systems?
- How should security teams govern roles when entitlements span multiple systems?
