How should security teams implement separation of duties in SaaS environments?

Why This Matters for Security Teams

Separation of duties in SaaS is not just an audit checkbox. It is the control that stops one identity from requesting, approving, and carrying out a sensitive change with no independent review. In SaaS platforms, that risk grows because admin roles, delegated approvals, OAuth connections, and API-driven automation often bypass the same controls used in on-prem systems. The practical goal is to prevent a single compromise or misuse event from turning into an unchecked privilege change.

That distinction matters because SaaS workflows are often designed for speed, not conflict-of-interest control. A user may be able to submit an access request, approve a ticket through a workflow integration, and then use an elevated role or token to execute the change. Current guidance suggests that teams should treat the entitlement path, not the job title, as the real unit of SoD. NIST’s NIST Cybersecurity Framework 2.0 remains a useful baseline for governance, while NHIMG research shows why this is urgent in practice: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes for API keys.

In practice, many security teams discover SoD failures only after an over-privileged admin or automation path has already been used to approve and execute the same change.

How It Works in Practice

Effective SaaS SoD starts with identifying incompatible actions at the entitlement level. For example, the same person should not be able to create an access request, approve it, and grant the entitlement in the same system. That may sound simple, but SaaS reality is messier: approval may happen in one product, execution in another, and evidence in a third. Security teams need a control model that follows the workflow across applications, identities, and integrations.

A workable pattern is to define SoD rules in policy, then enforce them at request time and review them continuously. Map each sensitive SaaS action to a specific role, approver, and execution path. Where possible, make approval independent of the requester and prevent self-approval at the identity layer, not just through process guidance. For higher-risk actions, use time-bound access, step-up verification, and explicit audit logging so the approval trail is testable after the fact. This is consistent with the direction of the NIST Cybersecurity Framework 2.0, which emphasises governance, identity control, and ongoing assurance.

NHIMG research on the Snowflake breach and Salesloft OAuth token breach shows why SaaS controls must also cover tokens, integrations, and delegated access, not only interactive users. A compromise can move through a trusted SaaS link even when the human approval path looks clean on paper. Best practice is to pair SoD with periodic access certification, log review, and revocation testing so the control is proven, not assumed.

• Separate request, approval, and execution across different identities.
• Block self-approval and same-session elevation for sensitive SaaS changes.
• Assign time-limited access for execution, then revoke it automatically.
• Log who requested, who approved, and which entitlement actually changed.
• Review SaaS integrations and API tokens as part of the SoD scope.

These controls tend to break down in heavily automated SaaS environments where workflow tools, service accounts, and delegated admin APIs can all perform the same action path.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, requiring organisations to balance change velocity against review depth. That tradeoff is real in SaaS because many platforms were built for collaboration, not for hard segregation of duties. The control model has to be strong enough to stop abuse, but still workable for incident response, finance operations, and identity administration.

One common edge case is emergency access. Best practice is evolving, but current guidance suggests emergency elevation should be separate from routine approvals, time-boxed, and retrospectively reviewed by someone who did not grant the access. Another edge case is automation: a service account may legitimately request or execute actions, but it should not approve them. If a bot triggers an approval workflow, that approval must still come from an independent human or a distinct control plane with auditable policy logic.

Teams should also be careful with role explosion. Too many fine-grained roles can create a false sense of SoD while still allowing one administrator to chain permissions through nested groups, shared inboxes, or delegated app scopes. The Ultimate Guide to NHIs is useful here because excessive privilege and weak rotation are recurring contributors to compromise. In SaaS, that often means SoD must include non-human identities, OAuth grants, and API keys, not just end-user permissions. There is no universal standard for this yet, so teams should document the rule set, test it against real workflows, and revalidate it after every major SaaS change.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams implement identity governance in SaaS-heavy environments?
• How should security teams implement segregation of duties automation in hybrid environments?