Because IAM and PAM are the controls that decide who can act, who can approve, and who can certify the result. Without separation, a single privileged identity can accumulate enough authority to hide mistakes or abuse. SoD creates friction that makes collusion harder and accountability easier to prove.
Why Separation of Duties Matters in IAM and PAM
Separation of duties is the control that prevents one identity from both creating access and approving it, especially when that identity can also use privileged tools. In IAM and PAM programmes, that matters because access governance is only as strong as the review chain behind it. When provisioning, approval, and certification are collapsed into one path, errors become harder to spot and abuse becomes easier to hide. NIST’s NIST Cybersecurity Framework 2.0 treats governance and control accountability as core security outcomes, not optional process overhead.
For NHI-heavy environments, SoD is even more important because service accounts, API keys, and automation roles often outlive the humans who created them. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes independent approval and review a practical necessity rather than a compliance formality. In practice, many security teams only discover SoD weakness after a privileged workflow has already been used to approve itself or conceal a toxic access chain.
How SoD Should Work Across IAM and PAM Workflows
Effective separation of duties means no single person, team, or automation path should control the full lifecycle of a privileged entitlement. In IAM, that usually means one role requests access, another approves it, and a separate reviewer certifies whether it should remain. In PAM, the pattern extends to privileged session creation, approval, checkout, session monitoring, and post-session review. The control is not just about people. It also applies to bots, scripts, and orchestration pipelines that can function as non-human approvers if left unchecked.
Practitioners should design SoD around the highest-risk actions, not around organisational charts. A good model is:
- Requesters cannot approve their own access changes.
- Approvers cannot also administer the target entitlement or vault.
- Certifiers review usage separately from the person who provisioned the access.
- Emergency access is time-bound, logged, and independently reviewed after the fact.
This is especially important where credentials are stored in vaults or rotated through automation. NHIMG’s Ultimate Guide to NHIs highlights that only 20% of organisations have formal offboarding and API key revocation processes, which makes independent review a key defence against stale privileged access. For implementation guidance, pair PAM governance with policy checks in OWASP-aligned identity workflows and inspect control paths for self-approval risk. This guidance tends to break down when one platform team owns both the vault and the approval engine because the same operational group can silently bypass review gates.
Common SoD Failures and Where the Control Becomes Thin
Tighter separation of duties often increases operational friction, requiring organisations to balance stronger accountability against slower access delivery. That tradeoff becomes visible in incident response, infrastructure automation, and small security teams where the same people are expected to build, approve, and audit.
Current guidance suggests treating these cases as exceptions, not as reasons to remove SoD altogether. The safest pattern is to grant temporary, narrowly scoped exception paths with independent logging and retrospective review. In cloud and DevOps environments, this often means combining IAM approval separation with PAM session controls and immutable audit trails rather than relying on job titles alone. The challenge is that a technically separate approver can still be functionally compromised if they share tooling, credentials, or pipeline ownership with the requester.
NHIMG’s Azure Key Vault privilege escalation exposure and BeyondTrust API key breach illustrate why control separation matters when privileged tooling is itself part of the attack surface. In those environments, SoD can fail when administrators, approvers, and vault operators converge on the same small set of identities because compromise or collusion in one role can cascade across the entire access chain.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SoD supports distinct approval and access enforcement responsibilities. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Privileged NHI governance depends on preventing self-approval and toxic access paths. |
| CSA MAESTRO | TRUST-05 | Agent and workflow trust boundaries need separated control points to reduce abuse. |
Separate request, approval, and certification duties so no one role can self-authorise privileged access.
