Segregation of duties (SoD) findings are the single most common reason a D365 F&SC security review turns up something uncomfortable in front of the audit committee. The frustrating part is that almost none of these conflicts are intentional. They accumulate quietly as roles get copied, extended, and reused over years of onboarding shortcuts.

This guide covers how D365's security model is actually structured, where conflicts hide inside it, and how to run a first-pass SoD analysis yourself before it shows up as a finding.

How D365 F&SC security is actually layered

D365 F&SC's security model has four layers, and most confusion about "who can do what" comes from conflating them:

Where conflicts actually live: almost never at the privilege level, since nobody deliberately grants "approve own payment." They live at the role level, where two individually reasonable duties get bundled into the same role, or the same user gets assigned two roles whose duties combine into a conflict.

The conflict pairs auditors check first

If you only have time to check a handful of combinations, start here. These are the pairs that show up in nearly every SOX-relevant F&SC audit:

Duty ADuty BRisk if combined
Create/edit vendor master data Approve vendor payments Fictitious vendor + self-approved payment
Enter purchase orders Approve purchase orders Unauthorized purchasing above approval limits
Post journal entries Reconcile bank accounts Concealment of misappropriated funds
Maintain customer credit limits Post sales invoices / process cash receipts Revenue manipulation, unauthorized credit extension
Maintain payroll master data Approve payroll runs Unauthorized payroll changes going undetected

How conflicts creep in through role inheritance

The scenario we see constantly: a legitimate "AP Coordinator" role is created cleanly, with no conflicts. Eighteen months later, someone needs a slightly expanded version for a senior AP staffer, so an admin clones the role, adds a duty for "payment approval up to $10k," and ships it as "AP Coordinator Ext," without re-checking whether the combined duty set now creates a conflict with the vendor-maintenance duties already present in the base role.

Multiply that pattern across a few years of role customizations, and you get a security model that passed review when it was first designed but has drifted into conflict territory nobody signed off on.

Running your own SoD analysis

  1. Export the full role → duty → privilege matrix for every custom and out-of-the-box role currently assigned to a user.
  2. Build a duty-conflict rule set. Start with the pairs listed above, then extend it to match your organization's actual risk areas (e.g. inventory adjustment + cycle count approval, if inventory shrinkage is a concern).
  3. Cross-reference against user role assignments. A duty conflict inside a single role is a design flaw; the same conflict split across two roles held by the same user is functionally identical risk.
  4. Flag by risk level, not just by presence. A conflict on a $500 purchase limit is not the same severity as one on unlimited payment approval.
  5. Remediate by splitting roles, not by removing access wholesale. The goal is realistic segregation, not breaking people's ability to do their jobs.
On remediation: the fastest fix, pulling access without a replacement workflow, is usually the wrong one. If someone genuinely needs both duties for business continuity reasons (common in small finance teams), the correct control is often a compensating control (mandatory second-approver, exception reporting) rather than a role split that isn't operationally realistic.

Where licensing and security governance overlap

Every role redesign you make to close an SoD gap has a licensing consequence, because Microsoft determines license tier from the same role → duty → privilege structure you're already remediating. Splitting an "AP Coordinator Ext" role back into a clean AP Coordinator role plus a separate, tightly-scoped approval role doesn't just fix the conflict. It can also drop the affected users from a Finance Premium requirement down to a plain Finance or Operations-Activity one, if the split removes the highest-tier securable object they previously had access to.

Microsoft's User Security Governance (USG) workspace, and specifically the License Usage Summary Report inside D365 F&SC (System administration → Security governance → License usage summary), shows exactly which securable objects are driving each user's license requirement. Run it alongside your conflict matrix, not after. A role split done for SoD reasons that ignores licensing impact tends to get quietly reverted six months later when someone notices the "temporary" Premium assignments never went away.

One exemption worth knowing for remediation planning: service accounts scoped only to non-interactive system roles, batch job manager, data management operations user, business events security role, and roughly forty others, are excluded from license requirements entirely. If your SoD remediation plan involves moving an integration off a shared human account onto a proper service account, confirm it's scoped to only those roles; adding even one business-functional duty for convenience turns it back into a licensable, and auditable, user.

What to do with the results

A completed conflict matrix becomes the backbone of your SOX/ISO evidence package: it shows the risk was identified, assessed by severity, and either remediated or covered by a documented compensating control. That's a materially stronger position than an auditor finding the conflict first and asking why it wasn't caught.

If licensing hasn't been reviewed alongside security in your tenant, it's worth doing both together. Role redesigns triggered by an SoD fix often change a user's license tier requirement too. Our companion pieces on D365 F&SC licensing types and where the money leaks and Microsoft's new mandatory license validation rollout cover that side of the same audit.