How SoD rules actually evaluate a role
F&SCM's security model is a hierarchy: roles contain duties, duties contain privileges, privileges contain permissions. Segregation of Duties rules are declared between two duties. When the system checks a role assignment for conflicts, it is comparing duty names attached to that role against the rules table.
Microsoft's own documentation on role-based security confirms the mechanism directly: “Although you can assign privileges directly to roles, assign only duties to roles.” The word “although” is doing real work in that sentence: the system allows it, even though it isn't the recommended path.
Why the shortcut is invisible to the rule engine
When a privilege sits directly on a role with no duty wrapping it, there is no duty name for an SoD rule to match against. The access is real. A user with that role can use it immediately. But the rule that was supposed to catch “this privilege combined with that other privilege” has nothing to evaluate, because the rule was written in terms of duties, and this privilege was never assigned as part of one.
Multiply this across a handful of go-live shortcuts, consultant access requests, and “temporary” fixes that outlive the project, and an environment can accumulate a meaningful amount of access that its own SoD program was never able to see.
Why it stays that way
The SoD rules page will still show every configured rule as satisfied. Nothing about this access shows up as a violation, because nothing about it was ever evaluated as one. An administrator reviewing the rules page has no reason to suspect anything is wrong. The gap isn't a failure of the rule; it's a category of access the rule was never built to check.
What does catch it
Privilege separation validation, a separate and less-used mechanism under the process hierarchy security tasks in F&SCM, analyzes overlapping privileges assigned to a role directly, rather than duty names, which is exactly the layer this shortcut operates in. Few organizations have this configured, because it isn't the same page as the standard SoD rules and isn't promoted alongside it.
Authorization Monitoring is built to catch this class of gap by design: it analyzes Security Objects and user assignments directly, so a privilege sitting on a role outside of any duty is visible in the results, not hidden behind a rules page that was never built to see it.
If a consultant added a privilege directly to a role during your last go-live, would your current SoD setup have caught it? Request a demo to find out what's actually sitting in your roles today.
