Security teams should combine role analysis, object-level access review, and continuous monitoring to find conflicting duties before they reach audit time. The goal is to identify where a user can both initiate and approve sensitive actions, then redesign roles, tighten approvals, and test the control continuously so the evidence shows the control works, not just that it exists.
Why This Matters for Security Teams
segregation of duties in D365 F&O is not just an audit mapping exercise. It is a practical control over who can create, change, approve, and release high-risk business actions in the same workflow path. When SoD is weak, a single account can manipulate purchasing, payments, vendor master data, or journal approvals without meaningful challenge. Current guidance still favours role analysis, but it must be paired with continuous evidence and exception management, not annual recertification alone. For broader identity governance context, NHI Mgmt Group notes that 97% of NHIs carry excessive privileges in modern enterprises, a pattern that mirrors how SoD drift accumulates over time in ERP systems, as described in the Ultimate Guide to NHIs — Why NHI Security Matters Now. The same lesson applies here: over-permissioned access becomes normal until a control failure or audit finding forces a reset. In practice, many security teams discover SoD conflicts only after a payment exception, vendor fraud review, or audit sampling has already exposed the issue.
How It Works in Practice
Effective SoD detection in D365 F&O starts by breaking access down into the actual business capabilities users can exercise, not just the roles they have been assigned. Security teams should review role inheritance, duty assignments, privileges, and object-level access to identify toxic combinations such as create and approve, maintain and pay, or request and release. Microsoft’s control model must be translated into business terms, then validated against real workflows, because a clean role name can still hide conflicting permissions.
A practical program usually includes three layers:
- Role mining to identify where permissions overlap across duties that should remain separate.
- Process tracing to see whether one user can initiate, edit, approve, or post the same transaction end to end.
- Continuous monitoring to flag exceptions when temporary access, emergency access, or custom roles create new conflicts.
For a control baseline, align the review to the NIST Cybersecurity Framework 2.0, especially access governance and continuous monitoring expectations. For identity lifecycle discipline, the NHI Lifecycle Management Guide is useful because SoD failures often begin when access is granted quickly and never revisited. In D365 F&O, the best practice is to maintain an SoD matrix tied to business risk, test it against actual role assignments, and require compensating controls where a clean separation is not possible. These controls tend to break down in highly customised D365 environments because custom duties, legacy integrations, and one-off emergency roles obscure the true end-to-end authority of each user.
Common Variations and Edge Cases
Tighter SoD controls often increase operational friction, requiring organisations to balance fraud prevention against business continuity. That tradeoff is especially visible in D365 F&O during month-end close, urgent payment runs, or small-team operations where the same staff member wears multiple hats. Best practice is evolving, but there is no universal standard for how much compensating control is enough in every environment.
Edge cases usually appear in three forms. First, delegated access and temporary elevation can create invisible conflicts if approvals are not time-bound and reviewed after use. Second, custom workflows can bypass the standard control design, especially when business units modify forms or add approval paths without security review. Third, non-human accounts used for integrations, batch jobs, or automated posting can create SoD risk when they inherit broad access and are treated like technical necessities rather than governed identities. For that reason, SoD reviews should include service accounts and automation paths, not only named employees. The broader NHI risk picture is reinforced by the Ultimate Guide to NHIs — Key Challenges and Risks and the Top 10 NHI Issues, both of which show how excess privilege and poor lifecycle control turn into repeat findings. Security teams should treat SoD exceptions as living risk decisions, not static audit notes.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SoD is an access authorization and privilege separation problem. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Non-human accounts in D365 can create hidden SoD conflicts. |
| CSA MAESTRO | CTRL-05 | Agent and workload governance patterns help with automated D365 actions. |
| NIST AI RMF | Continuous evaluation and accountability support risk-based SoD monitoring. | |
| NIST Zero Trust (SP 800-207) | 5.1 | Zero trust reinforces least privilege and continuous verification for ERP access. |
Apply policy checks to automated workflows so machine actions cannot both initiate and approve sensitive steps.
Related resources from NHI Mgmt Group
- How should organisations improve SAP access governance when native segregation-of-duties controls only show technical violations?
- What do organisations get wrong about segregation of duties in federated environments?
- How should organisations implement segregation of duties in hybrid environments?
- What breaks when access reviews and segregation of duties are still handled manually at enterprise scale?
