Segregation of Duties Access: Mid-Market Basics

Segregation of duties access is one of those controls every auditor asks about and almost no mid-market IT team has properly automated. You know the idea: no single person should be able to both create a vendor and pay that vendor, or both approve a purchase order and issue the payment. The principle is old and well understood. The problem is that most organizations between 200 and 2,000 employees still check it with a spreadsheet, once a year, right before the audit.

That gap is not because segregation of duties (SoD) is hard to understand. It is because the tooling to enforce it has historically come bundled with heavyweight identity governance suites built for banks and insurers, with SoD matrices spanning thousands of rules across SAP, Oracle, and a dozen other systems. If your reality is Microsoft 365, Entra ID, and a handful of business applications, that machinery is overkill. What you need is a short list of toxic combinations, checked automatically against your Entra ID and Active Directory groups.

This article covers what SoD access means, how to identify the toxic combinations that matter for a Microsoft-centric environment, and how to enforce them without buying an enterprise IGA platform.

What segregation of duties actually protects against

Segregation of duties is a control against a single point of failure in your processes, not a control against any one person being untrustworthy. A mistake, an oversight, or a deliberate act cannot go undetected because two different roles have to touch the same transaction.

Classic examples:

• The person who creates a new vendor in the finance system should not also be able to approve payments to that vendor.
• The person who requests access should not be the one who approves their own request.
• The person who deploys code to production should not be the same person who approved the change.
• An HR administrator who can both create employee records and process payroll runs can create a ghost employee and pay them.

None of these require malice to matter. Auditors care about SoD because it limits the blast radius of both fraud and error, and because ISO 27001, SOC 2, and NIS2-adjacent frameworks expect you to demonstrate it as a control, not just claim it as policy.

Why this becomes an access management problem

SoD sounds like a business process question, but in practice it is enforced through access: who is a member of which group, who holds which role, who can approve what. The moment someone accumulates group memberships over years of internal moves (a joiner/mover/leaver problem in disguise), a toxic combination creeps in silently. Nobody granted it on purpose. It just accumulated.

SoD and access governance are really the same discipline viewed from different angles. If you already have clean group definitions, an access review process, and a lifecycle that removes access when someone changes roles, you are most of the way to a working SoD control.

The toxic-combination approach for mid-market teams

Enterprise IGA suites tend to model SoD as an exhaustive matrix: every role against every other role, scored for risk, reviewed by a compliance team. For a company running mostly Microsoft 365 and a handful of line-of-business apps, that level of formality is rarely proportionate. A simpler approach works better and actually gets maintained.

Step 1: List your real toxic combinations, not a generic template

Start with a short list, ten to twenty pairs of roles or group memberships that genuinely should never overlap in your organization. Pull these from actual process knowledge, not a downloaded template. Talk to finance, HR, and IT operations and ask: "if one person could do both of these things, what could go wrong?"

Typical mid-market pairs:

1. Create vendor + approve payment
2. Approve purchase order + release payment
3. Request access + approve own access request
4. Grant Entra ID admin roles + audit those same roles
5. Process payroll + amend employee master data
6. Manage AD group membership + approve access reviews for that group

Step 2: Map each combination to real groups, then check overlap automatically

Every item on that list needs to translate into something checkable: an Entra ID group, an on-prem AD security group, an application role. This is the step teams usually skip, and it is why SoD policies stay theoretical. Once combinations are mapped, the check itself is simple set logic: does the intersection of group A and group B contain any users? That query can run continuously instead of once a year in a spreadsheet. The value is not sophistication, it is frequency: a toxic combination sitting there for eleven months before an annual audit catches it is still eleven months of exposure.

Where SoD breaks down in Microsoft environments

A few patterns show up repeatedly in Microsoft shops and are worth watching for specifically.

Nested groups and accumulated roles

A user might not be a direct member of two conflicting groups, but nested group membership can put them there indirectly, so a check that only looks at direct membership will miss it. A related pattern: someone moves from accounts payable into a finance manager role and keeps their old AP group membership because nobody remembered to remove it. Six months later they hold both sides of a toxic combination without anyone deciding that on purpose. This is the joiner/mover/leaver gap: access that follows a person's history instead of their current attributes.

Temporary access and unseparated admin roles

Someone covers for a colleague on leave and gets added to an approval group "just for two weeks." The two weeks become two years, because temporary elevated access is usually granted outside the normal review cycle and rarely gets an expiry attached. A similar risk sits in Entra ID admin roles: a common toxic pair is holding both a privileged role (Global Administrator, User Administrator) and the ability to approve or review access to that same role. Whoever can grant privilege should not be the sole reviewer of it.

How to enforce SoD without an enterprise IGA suite

For most mid-market organizations, three practical mechanisms cover the bulk of SoD enforcement:

Mechanism	What it catches	Where it runs
Attribute-based group rules (ABAC)	Prevents someone landing in two conflicting groups, since membership follows department, job title, and location	Entra ID dynamic groups, on-prem AD
Periodic access reviews on toxic pairs	Catches accumulated conflicts from historical grants and nested membership	Reviews scoped to the specific group pairs on your list
Self-service approval routing	Ensures the approver is never the requester, and sensitive requests route outside the requesting group	Self-service access portal, rule-based approval

The common thread: SoD enforcement works best when it is built into how access is granted and reviewed, rather than bolted on as a separate audit exercise. If your access model is already attribute-based, a small number of "these groups may never overlap" rules on top is a modest extension, not a new platform.

This is where ServiceChanger fits for Microsoft-only environments. Its ABAC engine assigns Entra ID and on-prem AD group membership automatically from attributes like department and job title, which limits how toxic combinations get created in the first place. Its access review functionality lets you scope a recurring review to exactly the group pairs that matter for SoD, instead of re-reviewing everything. And because access follows attributes rather than manual grants, the self-service portal can route approvals to someone outside the requesting group by rule, keeping request and approval separated by design.

Building a lightweight SoD program: a practical checklist

• Write down your real toxic combinations (ten to twenty is plenty to start).
• Map each combination to specific Entra ID groups, AD groups, or app roles.
• Resolve effective (nested) membership, not just direct, when checking overlaps.
• Run the overlap check on a schedule, not once a year.
• Route requests so the approver is never the requester and, for sensitive groups, sits outside that group.
• Set expiry dates on temporary or covering access so it cannot silently become permanent.
• Review the toxic-combination list itself annually; roles change, and your list should too.

FAQ

What is segregation of duties (SoD) in access management? SoD is a control ensuring no single person holds two roles or permissions that, combined, let them complete a sensitive process end to end without oversight, such as creating a vendor and approving payment to that vendor.

Do mid-market companies need a full IGA suite for SoD? No. Most organizations running primarily Microsoft 365 and Entra ID can enforce SoD with a short list of toxic combinations checked automatically against group and role membership, without the matrix machinery built for large ERP landscapes.

How do toxic combinations happen if nobody grants them on purpose? They usually accumulate through internal role changes where old memberships are never removed, through nested membership invisible to a direct check, or through temporary access that never gets revoked.

Can Entra ID dynamic groups help prevent SoD violations? Yes. When membership is driven by attributes like department and job title rather than manual assignment, it is harder to accumulate conflicting memberships unintentionally, because membership reflects the current role, not history.

Segregation of duties does not need to be a once-a-year audit scramble. Start with a short list of the combinations that genuinely matter, map them to real Entra ID and AD groups, and check the overlap automatically. To see how ServiceChanger's ABAC engine and access reviews support that for Microsoft-only environments, visit our access governance and compliance page, or browse access control and governance on the blog.