Separation of duties gaps still drive fraud and compliance risk

At a glance

What this is: This is a Saviynt analysis of why separation of duties remains a core internal control, focusing on conflicting permissions across finance and IT workflows, users, and service accounts.

Why it matters: It matters because IAM, IGA, and PAM teams need consistent separation-of-duties enforcement across applications and identities before conflicting access turns into fraud, audit findings, or operational misuse.

Context

Separation of duties is a control design pattern, not a product feature. The article frames the problem as one person accumulating conflicting access across business processes, which creates a path to fraud, error, and weak accountability when review and approval are not separated.

In identity programmes, SOD sits at the intersection of role design, entitlement governance, and access request control. The article extends the issue beyond human users to service accounts and cross-application access, which is where inconsistent policy enforcement usually becomes visible.

Key questions

Q: What breaks when separation of duties is not enforced in regulated environments?

A: High-risk actions become easier to execute without challenge, and the organisation loses a major control against both misuse and insider risk. In critical infrastructure, that also weakens confidence in incident investigations because approval and execution can no longer be independently verified.

Q: Why do conflicting entitlements create so much fraud risk?

A: Because they remove the independent check that prevents one identity from completing both sides of a sensitive transaction. If the same person or account can create and approve, submit and release, or request and authorise, the control no longer constrains behaviour. Fraud, error, and audit failure become much easier to hide.

Q: How should security teams detect segregation of duties conflicts that matter in practice?

A: They should correlate assigned entitlements with actual activity across systems, not just rely on role definitions. The most useful SoD control distinguishes a theoretical conflict from a conflict that is being exercised in a real workflow. That requires unified visibility, event telemetry, and risk thresholds tied to business processes, not abstract policy tables.

Q: Should organisations include service accounts in segregation of duties checks?

A: Yes. Any account that can perform sensitive actions should be subject to SoD logic, including service or unmapped accounts. If those accounts are excluded, the organisation creates a parallel access path that can bypass the same governance applied to human users.

Technical breakdown

How separation of duties conflicts emerge across applications

Separation of duties conflicts arise when a single identity can complete multiple critical steps in the same process, such as creating and approving invoices or requesting and approving access. In practice, these conflicts are often hidden by application silos: one system may expose the risky entitlement pair while another lacks the context to detect the combined effect. That is why cross-application SOD is harder than local rule checks. The governance challenge is not just identifying toxic combinations, but ensuring they are evaluated against the business process that creates the conflict.

Practical implication: Model toxic entitlement combinations across applications, not just within individual systems.

Preventive and detective SOD enforcement

The article distinguishes between preventive control at request time and detective control after access has already been granted. Preventive analysis blocks or routes risky requests before the user receives the entitlement, while detective analysis surfaces conflicts already present in the environment. Both are necessary because access drift is unavoidable in large organisations, and standing entitlements change over time. A mature SOD programme therefore needs policy evaluation at request time, continuous monitoring over time, and remediation paths for previously unknown conflicts.

Practical implication: Evaluate SOD both when access is requested and after access has changed.

Why human and service account access both matter

A common SOD blind spot is treating service accounts as operational exceptions rather than governed identities. The article explicitly includes human and service accounts in SOD visibility, which matters because non-human access can carry the same conflicting authority as a user account. If an automation account can trigger a transaction and also approve or complete it, the control failure is the same. SOD programmes that exclude non-human identities leave a material gap in enterprise control coverage.

Practical implication: Include service accounts in entitlement analysis and SOD rule evaluation.

NHI Mgmt Group analysis

Separation of duties is still a control integrity problem, not a policy declaration problem. Organisations often have SOD rules on paper but still allow conflicting access to accumulate across applications, users, and service accounts. The article shows that the real failure mode is inconsistent enforcement across the identity lifecycle. The practitioner takeaway is that SOD quality must be measured by prevented conflicts, not by the existence of a rule library.

Cross-application SOD is where most governance programmes lose context. A conflict rarely matters because of one entitlement in isolation; it matters because two entitlements together let the same identity complete a full business transaction. That is why application-level approval logic is not enough. Security and IGA teams need process-aware entitlement analysis that follows the workflow, not just the system boundary.

Non-human identities belong inside SOD governance, not beside it. The article’s inclusion of service accounts is a useful reminder that automated or operational identities can also create conflicting authority. If a workload or service account can originate and finalise a sensitive action, the organisation has recreated the same control weakness it was trying to remove from human access. The implication is broader identity governance, not narrower exception handling.

The named concept here is cross-application conflict exposure. This is the point where entitlement risk becomes enterprise risk because the conflict spans more than one platform, process, or account type. Once that happens, local role design cannot solve the problem on its own. Practitioners need an identity governance model that evaluates critical function combinations as a single control surface.

What this signals

Cross-application SOD is a governance model, not an application setting. Teams should expect conflicts to appear where business process ownership, application ownership, and identity ownership do not line up. That means the programme needs a shared entitlement view, not isolated reviews per platform.

Service accounts are part of the same control problem. When automation identities can initiate and complete sensitive processes, the separation of duties design has failed at the identity layer. Governance teams should treat those accounts as first-class subjects in access certification and conflict analysis.

For practitioners

• Map toxic role combinations across critical processes Identify which entitlement pairs let one identity both initiate and complete a sensitive transaction, then document those pairs at the business-process level rather than per application.
• Apply SOD checks at request time Evaluate access requests against SOD policy before granting new entitlements, and route risky combinations to approval or rejection workflows.
• Extend SOD rules to service accounts Include automation accounts in the same conflict analysis used for human users so non-human access cannot bypass review by default.
• Run continuous conflict review jobs Schedule recurring evaluations to find existing conflicts that were not visible at the time of request and track remediation until closed.

Key takeaways

• Separation of duties fails when one identity can carry conflicting authority through a business process, especially across multiple applications.
• The article’s examples show that fraud and compliance exposure come from inconsistent enforcement, not from a lack of policy language.
• SOD programmes need process-aware detection and remediation, including service accounts, to keep conflicting access from becoming operational risk.

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.
• Conflicting Access: Conflicting access occurs when one account or role holds permissions that should be separated because they create a control bypass. The problem is structural, not personal, and it often appears when role design or provisioning rules are too broad.
• Detective SOD Analysis: A monitoring approach that reviews existing entitlements against separation-of-duties rules after access has been granted. It is used to find hidden conflicts, inherited risk, and access drift that preventive request-time controls may not catch.
• Cross-Application Access Governance: Cross-application access governance is the practice of managing entitlements across multiple systems from a unified control view. It helps teams see how access accumulates across applications, identify excessive permissions, and apply policies consistently when identities, roles, and business processes span a large enterprise environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.