Ask a finance team whether Segregation of Duties is under control in their Dynamics 365 environment, and you will often get the same answer: yes, we have rules configured, and the page is green. It is an honest answer. It is also a weaker guarantee than almost everyone assumes, and the gap between the two is where audit findings are born.
This matters well beyond one organization. Anyone implementing, supporting or auditing Dynamics 365 Finance & Supply Chain Management runs into it eventually, usually at the least convenient moment: mid-audit, or during an incident review when someone asks how a particular combination of access was ever possible.
What the native rules engine actually evaluates
Dynamics 365 F&SCM ships with a Segregation of Duties mechanism under System administration > Security > Segregation of duties. An administrator declares two duties incompatible, for example a duty covering vendor bank account maintenance and one covering payment processing. The system then evaluates role definitions and user assignments against that declaration, logs conflicts, and requires an administrator to allow or deny each one.
That mechanism does exactly what it promises. The catch is what the promise covers: it compares the names of the two duties it was given against the duties attached to a role or user. It does not examine what those duties contain, and it has nothing to say about duties nobody wrote a rule for.
Three reasons a green page can be misleading
The rule has to exist first. Only combinations somebody identified in advance and configured as a rule get evaluated. A risky pairing that was never declared is not flagged, however obvious it looks to an auditor reading the role afterwards.
Duty contents drift away from duty names. Duties get customized during implementation, copied, extended and occasionally emptied. If the vendor bank permissions from the rule above also sit inside a differently named duty, the pairing occurs in practice while the rule stays quiet. And a duty stripped of its privileges keeps triggering the rule that references its name, generating conflicts about access that no longer exists.
Privileges can bypass duties entirely. Microsoft's own documentation on role-based security notes that although you can assign privileges directly to roles, you should assign only duties. The system permits the shortcut, and it happens: during go-lives, during support incidents, whenever something needs fixing today. Because Segregation of Duties rules are declared between duties, a directly assigned privilege has no duty name to match against and is never evaluated.
What this looks like in a real process
Take the vendor payment cycle, the example most auditors reach for first. Creating a vendor record, maintaining its bank details, approving the resulting invoice and releasing payment are separate duties for a reason: together they let one person move money to an account they control, with no independent check anywhere in the chain.
Nothing in the interface prevents a single role from carrying all of them. Roles grow over time, absorbing a temporary task here and a just-in-case duty there, until the title on the role no longer describes its reach. And if the relevant conflict was never declared as a rule, or the permissions arrived through a duty the rule does not mention, the rules page reports no problem at all.
A control that verifies labels without verifying access is, in effect, a paper control. It demonstrates that the administration is tidy. It does not demonstrate that the risk is covered, which is the assertion the organization is actually making to its auditors.
Curious how the four layers of F&SCM security fit together, and what a complete view of a role actually shows?
What closing the gap requires
Microsoft does offer a mechanism that works a layer deeper. Privilege separation validation, found under the security tasks in the process hierarchy, analyzes overlapping privileges on a role rather than duty names. It is worth knowing about, though it sits apart from the standard rules page and comparatively few organizations have it configured.
User Security Governance, standard since version 10.0.43, is a genuinely useful addition as well, with process-based role design, time-bound privileges and license usage reporting. Its focus, though, is on designing and assigning security rather than on reviewing Segregation of Duties conflicts with a documented conclusion per finding.
Whatever tooling you land on, the underlying requirement is the same. An SoD review that holds up needs to start from actual granted access rather than duty labels, cover every path by which a user can reach a permission, and record each conclusion, including accepted risks, with a reviewer, a date and a rationale that an auditor can sample months later.
A practical starting point
If you want to know where your own environment stands, three questions are enough to get an honest answer. Can you show, today, which privileges are assigned directly to roles rather than through duties? Do you know whether any duty contains permissions its name does not suggest? And could you produce, right now, the documented conclusion of your last Segregation of Duties review?
Answering those questions is uncomfortable the first time. It is considerably less uncomfortable than answering them during an audit.
See what is actually sitting in your roles
In 45 minutes we walk through Authorization Monitoring on a realistic F&SCM security setup, including the blind spots above. Bring your own questions.
This article was contributed by 2-Controlware, developer of
.
Our software is built by IT auditors and analyzes Security Objects and user assignments to detect Segregation of Duties violations and build audit-ready evidence. More articles on Dynamics authorization management are available on
.