TL;DR: Segregation of duties software only reduces fraud and audit risk when role design, access reviews, provisioning, and deprovisioning are governed consistently across the user lifecycle, according to Zluri’s 2026 overview of SoD tooling. The deeper issue is not feature coverage but whether identity controls can keep conflicting access from accumulating faster than governance can remove it.
At a glance
What this is: This is a Zluri overview of SoD software that finds segregation of duties depends on lifecycle governance, not just role design or alerting.
Why it matters: It matters because IAM and IGA teams need SoD controls to survive joiner-mover-leaver changes, access requests, and offboarding without letting conflicting access persist.
By the numbers:
- Zluri says the platform offers more than 300 SaaS application integrations.
Context
Segregation of duties software is meant to stop one identity from accumulating conflicting access that can enable fraud, errors, or audit failure. In practice, that only works when access is governed across the full user lifecycle, not treated as a one-time role design exercise. For IAM and IGA teams, SoD is therefore a control system problem, not a dashboard problem.
Zluri’s article frames SoD tooling as an identity governance issue because provisioning, deprovisioning, access reviews, and self-service requests all influence whether duty conflicts are created or removed. The article also links SoD to SaaS discovery and lifecycle automation, which makes the underlying governance model more operational than theoretical.
Key questions
Q: Why does segregation of duties fail when lifecycle governance is inconsistent?
A: SoD fails when conflicting access is granted in one workflow and removed in another, because the control depends on consistent lifecycle enforcement. If provisioning, role changes, exceptions, and offboarding are not tied together, identity entitlements can outlive the policy that should have constrained them.
Q: What happens when access reviews do not track how permissions were granted?
A: Reviews can miss the real conflict if they only confirm who has access today and do not trace why that access exists. That leads to stale exceptions, inherited rights, and manual workarounds surviving long after the business need has disappeared.
Q: What breaks when SoD rules are applied without current SaaS discovery?
A: You get policy coverage on paper but not in the actual application estate. Conflicts remain hidden in systems that were never mapped, which means enforcement and reporting both become incomplete and audit evidence stops matching operational reality.
Q: How should IAM teams decide whether SoD software is effective?
A: Look for whether the platform can continuously detect conflicting access, connect it to lifecycle events, and remove or flag it across the full SaaS estate. If it only produces reports after the fact, it is supporting compliance evidence more than real segregation.
Technical breakdown
Why SoD breaks when lifecycle controls are fragmented
Segregation of duties depends on the system knowing who can do what, where conflicting permissions exist, and when those permissions should disappear. If provisioning, role changes, and deprovisioning sit in separate workflows, SoD policies become static rules applied to a dynamic identity estate. That creates a mismatch between policy intent and lived access. Real SoD control therefore depends on lifecycle-aware enforcement, not just role templates or periodic reports.
Practical implication: tie SoD policy evaluation to joiner-mover-leaver events and access review outcomes.
How access reviews support SoD enforcement
Access reviews are the governance checkpoint that confirms whether conflicting access still exists after role changes or exception grants. They matter because SoD violations often accumulate gradually through exceptions, one-off approvals, and inherited permissions. A review process that only verifies current entitlements without tracing how those entitlements were granted can miss the control drift that SoD is supposed to prevent. In other words, reviews are only useful when they are connected to lifecycle data and enforcement actions.
Practical implication: validate review campaigns against lifecycle events and remove conflicts, not just record attestations.
Why discovery and automation change the SoD control model
SoD fails quickly when teams do not have a current inventory of applications, identities, and permission paths. Discovery creates the visibility needed to map duties to actual systems, while automation reduces the delay between detecting a conflict and revoking it. In SaaS-heavy environments, manual handling lets conflicts survive across disconnected applications and team boundaries. The technical issue is not whether SoD rules exist, but whether the organisation can continuously see and enforce them across the estate.
Practical implication: connect SaaS discovery, policy enforcement, and provisioning workflows so SoD decisions act on live access data.
NHI Mgmt Group analysis
SoD is an identity lifecycle control problem before it is a policy problem: conflict rules are only effective when they are evaluated against live joiner-mover-leaver state. A role model that is correct on paper can still fail if access persists through transfers, exceptions, or stale accounts. The practical conclusion is that SoD governance must be lifecycle-enforced or it will drift into audit theatre.
Lifecycle drift is the real SoD control gap: the article shows that provisioning, deprovisioning, and access review must move together or conflicting access accumulates faster than review cycles can clear it. That is why SoD software cannot be judged only by rule logic or reporting depth. Practitioners should treat stale access as the condition that breaks SoD, not merely a symptom of weak policy.
SaaS sprawl raises the identity blast radius of SoD failures: when duties are distributed across many cloud applications, no single control plane can infer conflict without discovery and correlation. Zluri’s emphasis on multiple discovery methods reflects a broader market reality: SoD now depends on visibility into the actual application estate, not just directory data. The practitioner takeaway is that incomplete discovery produces incomplete segregation.
Manual SoD governance does not scale with modern identity estates: the more applications, requests, and exceptions an organisation has, the more likely conflicting access will outpace human review. Automated enforcement does not replace governance, but it does determine whether SoD operates continuously or only during audit prep. That makes SoD an operational discipline, not a periodic compliance task.
Identity governance and SoD are converging into one operating model: the article makes clear that access requests, automated reviews, role design, and offboarding are no longer separate disciplines when the goal is to prevent duty conflicts. The strongest programmes will treat SoD as a lifecycle invariant embedded in IGA, not a standalone control bolted onto access review. Practitioners should align SoD policy with the same governance workflow that manages the identity lifecycle.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: NHI Lifecycle Management Guide
What this signals
Lifecycle-aware segregation is now the defining SoD requirement: teams that still treat segregation as a static policy layer will miss the way access changes across provisioning, transfers, and offboarding. The control boundary has moved to the identity lifecycle, which means SoD must be evaluated where access is born, changed, and removed.
Discovery is a prerequisite for enforcement, not a reporting accessory: if the organisation cannot see all SaaS applications and user entitlements, it cannot reliably prove that duties are actually separated. That makes inventory quality a governance issue, not just an operational hygiene issue.
SoD and IGA are collapsing into one control pattern: access requests, automated reviews, and revocation workflows now determine whether duty conflicts are prevented or merely documented. Practitioners should design SoD as a continuous operating control rather than a quarterly compliance exercise.
For practitioners
- Map SoD rules to lifecycle events Bind segregation rules to joiner, mover, and leaver events so role changes and offboarding automatically trigger conflict checks before access persists.
- Reconcile access reviews with exception grants Use review campaigns to find permissions that were added through temporary approvals, then remove or reauthorise them against current duty separation policy.
- Centralise SaaS discovery before policy rollout Inventory the applications and identity sources that actually hold business access, then test SoD policy against that live estate instead of a directory-only view.
- Automate revocation for unresolved conflicts Where a duty conflict is confirmed, route it to automated removal or compensating control workflow rather than leaving it to a manual follow-up queue.
Key takeaways
- SoD software is only effective when conflicting access is controlled across the identity lifecycle, not when roles are defined once and left to drift.
- The article ties SoD capability to discovery, provisioning, deprovisioning, and automated reviews because those are the places where conflicts are created or removed.
- For practitioners, the key test is whether the control can see live SaaS access, detect conflicts continuously, and resolve them before they become audit or fraud issues.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SoD depends on governing entitlements and removing conflicting access across the lifecycle. |
| Recommendation — Apply PR.AA-05 to continuously govern entitlements and remove conflicting access as roles change. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SoD is a practical least-privilege control for limiting conflicting permissions. |
| Recommendation — Enforce AC-6 to prevent identities from accumulating conflicting privileges beyond job need. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle management is central to keeping SoD conflicts from persisting. |
| Recommendation — Use CIS-5 to govern account creation, modification, and removal in step with SoD policy. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding failures let conflicting access survive after the business need ends. |
| NHI-05 — Overprivileged NHI | Excess permissions create the conditions for duty conflicts across applications. | |
| Recommendation — Treat offboarding as a SoD control point and revoke access when role responsibility ends. Review privilege scope for each identity and remove access that creates SoD conflicts. | ||
Key terms
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
- Identity Lifecycle Event: A business event that changes a person’s access, obligations, or record status, such as hiring, role change, or offboarding. In HR programmes, these events often drive entitlement changes and evidence requirements, so they need to be governed as part of the identity lifecycle rather than handled as isolated paperwork.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
- Duty Conflict: A condition where one identity can perform incompatible actions that should remain separated for security, compliance, or fraud prevention. In practice, duty conflicts often emerge from exceptions, role creep, or offboarding gaps rather than from initial role design alone.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org