How should organisations detect and mitigate Segregation of Duties risks in D365 F&O environments?

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.

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?