What is Separation of Duties?
Separation of Duties is a control principle that splits critical tasks among multiple people so that no one person can carry out a high-risk action from start to finish without oversight. The goal is to create checks and balances that prevent fraud, catch errors, and reduce the risk of insider threats.
The classic example comes from accounting: the person who approves a purchase order should not be the same person who authorizes payment. If one person can do both, they could approve a fake invoice and pay themselves. By splitting these tasks between two people, you create a natural check.
In the context of identity and access management, SoD means making sure that users do not hold combinations of access that would allow them to bypass controls. For example, the person who creates new vendor accounts in the ERP system should not also be able to approve payments to those vendors. The person who writes code should not be the same person who deploys it to production. The person who manages user access should not also be able to approve their own access requests.
SoD does not prevent any individual action. It prevents dangerous combinations of actions.
Why does SoD matter?
Fraud prevention. SoD is one of the oldest and most effective controls against internal fraud. When multiple people must be involved in a financial transaction, collusion is required for fraud to occur — and collusion is much harder to pull off than a single person acting alone.
Error detection. Even without malicious intent, mistakes happen. When a second person reviews or approves an action, errors are more likely to be caught before they cause harm.
Compliance requirements. SoD is explicitly required or implied by most compliance frameworks. SOC 2 requires controls that prevent unauthorized changes and ensure proper authorization of transactions. ISO 27001 (Annex A.6.1.2) specifically addresses segregation of duties. NIS2 requires appropriate access controls and risk management measures. SOX (for publicly traded companies) has extensive SoD requirements around financial reporting.
Audit expectations. Auditors look for SoD controls as a standard part of any assessment. If you cannot demonstrate that critical processes involve appropriate segregation, that is a finding.
SoD in practice: common conflict examples
SoD violations (also called SoD conflicts) occur when a single user holds access that lets them complete both sides of a process that should require two people. Common examples relevant to mid-sized companies:
Finance and procurement: creating vendors AND approving invoices, submitting expense reports AND approving them, managing the bank account AND reconciling bank statements.
IT and access management: creating user accounts AND approving access requests for those accounts, managing Entra ID roles AND auditing role assignments, deploying code to production AND approving the deployment.
HR and payroll: adding new employees to the HR system AND processing payroll, modifying employee records AND approving salary changes.
These are not theoretical risks. They are the kinds of access combinations that auditors specifically check for, and that fraud investigators look at first when something goes wrong.
How does SoD apply to Microsoft Entra ID?
In an Entra ID environment, SoD means being careful about which directory roles and application access are assigned to the same person.
Entra ID role combinations to watch: Global Administrator combined with any other role (Global Admin can already do everything, so it inherently creates SoD issues), and User Administrator combined with Privileged Role Administrator (can create users and assign them admin roles).
Cross-application SoD: More often, SoD conflicts occur across applications rather than within Entra ID itself. A user who has admin access in both the ERP system and the payment system has a conflict, even if their Entra ID roles are fine. Detecting these cross-application conflicts requires visibility into access across all systems, not just the directory.
Group membership conflicts: If your access model uses security groups, SoD conflicts can emerge when a user belongs to groups that grant conflicting access. For example, membership in both the "Finance-Approvers" group and the "Vendor-Management" group might create a conflict.
How to identify SoD conflicts
Identifying SoD conflicts starts with defining what combinations of access are problematic for your organization. This is called a SoD ruleset or policy matrix.
First, map your critical processes. List the business processes that carry financial, operational, or security risk. For each process, identify the distinct steps and who performs them. Then define conflicting access pairs — for each process, identify which combinations of access should not be held by the same person. These become your SoD rules. Example: "Access to create vendors" conflicts with "Access to approve payments."
Next, map access to systems. Translate those abstract access definitions into concrete system permissions. "Access to create vendors" might mean membership in the "ERP-Vendor-Admin" group in Entra ID. "Access to approve payments" might mean the "Payment-Approver" role in your finance application.
Then scan for violations by comparing your SoD rules against actual user access. Look for users who hold both sides of any conflicting pair. In a small organization, this can be done with a spreadsheet. As you scale, you need tooling.
Finally, remediate or document exceptions. For each violation found, either remove one side of the conflicting access or document a compensating control. Not every SoD conflict can be resolved — in very small teams, one person might need to wear multiple hats. In those cases, compensating controls (additional logging, management review, or secondary approval) mitigate the risk.
SoD challenges for mid-sized companies
SoD is particularly tricky for smaller organizations.
Small teams mean shared responsibilities. In a company with 100 employees, the finance team might be three people. Someone has to both manage vendors and process payments. You cannot always split duties the way a large enterprise can.
Awareness is often low. Many mid-sized companies have never formally defined their SoD requirements. Access is granted based on job needs without considering what combinations are risky.
Detection is manual without an IGA tool. Detecting violations requires manually cross-referencing access across multiple systems, and most IT teams do not have time for this.
The answer for smaller organizations is not to ignore SoD. It is to be realistic about it. Define the most critical SoD rules (focus on financial processes and admin access first), check for violations, and implement compensating controls where full segregation is not feasible.
How Adcyma helps with Separation of Duties
Adcyma helps organizations using Entra ID implement SoD controls by providing visibility into who has what access across the environment. You can define SoD policies that flag when a user's combined access creates a conflict — whether within Entra ID roles, across group memberships, or across connected applications.
When a conflict is detected, it can trigger a review or block the access assignment until it is approved with proper justification. This prevents new SoD violations from being created and helps identify existing ones.
For mid-sized companies that need to demonstrate SoD controls to auditors but do not have the resources for an enterprise GRC platform, this provides a practical, right-sized approach.