How should security teams enforce segregation of duties in IAM?

Why This Matters for Security Teams

segregation of duties is not just an audit checkbox. In IAM, it is the control that prevents one identity from combining request, approve, provision, and administer powers in ways that defeat oversight. That matters even more for non-human identity because secrets, tokens, API keys, and service accounts often sit outside the normal joiner-mover-leaver process. NHI security research from The 2024 Non-Human Identity Security Report shows how often organisations still rely on immature access practices, while the NIST Cybersecurity Framework 2.0 emphasises governance, access control, and continuous monitoring as linked outcomes rather than separate tasks.

For security teams, the real risk is concentration of privilege. A person who can create a secret, assign a role, and approve their own exception can bypass the intent of RBAC, PAM, and review processes. The same weakness appears in workload identity when long-lived credentials are reused across environments, because the control is then enforced after the fact rather than at request time. In practice, many security teams encounter SoD violations only after an access review, incident, or audit sampling exercise, rather than through intentional prevention.

How It Works in Practice

Effective segregation of duties starts with defining incompatible actions, not just roles. Security teams should map which permissions cannot coexist in the same identity, especially across request, approval, administration, and secret issuance. That map then needs to be enforced in IAM workflows, PAM workflows, and, where possible, policy-as-code so the check happens before access is granted. For NHI, this usually means combining RBAC with workload identity, JIT credentials, and short-lived secrets instead of depending on standing access. Current guidance suggests using NIST Cybersecurity Framework 2.0 to anchor the governance and monitoring layers, then applying runtime controls where the identity is actually used.

Operationally, this works best when the control is embedded in three places:

• request time, where the system blocks incompatible entitlements before approval;
• issuance time, where JIT provisioning limits duration and scope;
• review time, where drift, temporary exceptions, and stale secrets are detected.

That matters because standing secrets create hidden privilege paths. The exposure patterns discussed in Azure Key Vault privilege escalation exposure show how a role intended for secret management can become a route to broader access if duties are not separated. Likewise, ASP.NET machine keys RCE attack is a reminder that one exposed secret can collapse multiple layers of trust. These controls tend to break down in legacy IAM stacks where approvals, provisioning, and logging are split across tools that do not share policy context.

Common Variations and Edge Cases

Tighter segregation of duties often increases operational overhead, requiring organisations to balance stronger control against slower fulfilment and more exception handling. That tradeoff is real, especially when teams support emergency admin access, platform engineering, or managed service providers. Best practice is evolving, but there is no universal standard for this yet: some environments use dual approval for high-risk entitlements, while others rely on policy engines that evaluate context at runtime and allow only narrowly scoped exceptions.

The hardest edge cases appear when one identity must both run and maintain a workload, or when a small team owns the full stack. In those environments, security teams should prefer compensating controls such as independent logging, separate break-glass accounts, time-bound elevation, and post-approval review by a different control owner. For agentic systems, the issue is sharper because the agent may chain tools autonomously, so static role design alone is not enough. The safer pattern is to bind the agent to workload identity, issue ephemeral credentials per task, and re-evaluate intent before each sensitive action. If SoD only exists in spreadsheets or audit narratives, it will not stop privilege collapse when a secret is reused or an approval path is abused.

Related resources from NHI Mgmt Group

• How should security teams enforce segregation of duties in IAM workflows?
• How should security teams enforce segregation of duties in SAP environments?
• How should security teams implement segregation of duties in IAM workflows?
• How should security teams unify identity risk across IAM tools?