What the SoD rules engine actually checks
Dynamics 365 F&SCM's security model has four layers. Roles are assigned to users. Roles contain duties. Duties contain privileges. Privileges contain permissions to individual objects - menu items, fields, tables. The SoD rules page operates entirely at the second layer from the top: it compares the names of two duties assigned to the same role or user.
It does not look at which privileges those duties actually contain today. It does not look at whether a user has equivalent access through a different route entirely. It checks whether the duty labels match, full stop.
Three ways this gets exploited without anyone noticing
1. Privileges assigned directly to a role.
Microsoft's own documentation on role-based security is explicit: “Although you can assign privileges directly to roles, assign only duties to roles.” The system permits it anyway. If a privilege is attached to a role directly, rather than nested inside a duty, there is no duty name for the SoD rule to evaluate. The access exists. The rule has nothing to compare it against.
2. A duty emptied of its privileges.
A duty is just a named container. Nothing stops an administrator from stripping every privilege out of a duty while leaving its name - and the SoD rule referencing it - untouched. The rule keeps firing against a duty that, in practice, grants nothing, while a genuine conflict elsewhere in the role goes unchecked.
3. Access assigned through a security group.
Users provisioned through Microsoft Entra ID groups rather than direct role assignment inherit access the SoD rules engine was never designed to evaluate against. This gap doesn't close with the more advanced User Security Governance feature either - Microsoft's own Security Governance FAQ states outright that group-based access is not covered.
Why this isn't “the tool doesn't work”
None of this is a bug. The rules engine does exactly what it was built to do: compare duty labels attached to a role. The trap is assuming that a green light on that page means the underlying access is clean. It checks the packaging, not the contents.
Closing the gap
Microsoft does provide a deeper mechanism: Privilege separation validation, found under the process hierarchy security tasks, which analyzes overlapping privileges directly rather than duty names. It is a separate, less visible tool that most organizations never configure.
Authorization Monitoring closes this gap by analyzing Security Objects directly - roles, duties, privileges and the users assigned to them - rather than relying on duty labels alone, and by evaluating the access paths standard SoD rules were never built to see.
If your SoD rules page is green, do you actually know what that is - and isn't - telling you? Request a demo to see what Authorization Monitoring finds underneath.
