Documented SoD controls can look complete while users still hold conflicting or excessive access in the live system. That creates audit exposure, operational risk, and hidden privilege drift. The practical failure is not the policy itself but the absence of continuous evidence that the policy is enforced against current entitlements.
Why documentation alone fails for SoD in D365 F&O
Segregation of Duties only works when the live authorization model matches the rule set you wrote down. In D365 F&O, that means the control has to be tested against current roles, duties, privileges, indirect access, and any compensating control, not just reviewed as a policy artifact. A documented matrix can be neat and still miss the actual conflict in production.
What breaks first is assurance. If reviewers treat the spreadsheet or policy as the control, they can miss role changes, temporary access, inherited privileges, and custom security design that reintroduce a toxic combination after the last review. That is why SoD must be treated as an operating control, not a one-time design exercise.
In practice, the gap is usually between “approved” and “effective.” Users can accumulate access through role stacking, overlapping duties, emergency access, or cloned accounts, and those paths are often invisible unless entitlement data is continuously reconciled. The relevant baseline is the Segregation of Duties (SoD) Guide, which frames SoD as something to prevent and detect in the live access model, including service accounts and other non-human actors.
What operational and audit problems show up
The practical failure is hidden privilege drift. Once access is documented instead of enforced, the business can drift into a state where no single person appears to have excessive access on paper, but the system still permits conflicting actions through accumulated entitlements or poorly governed exceptions. That breaks audit evidence, because auditors need proof of current enforcement, not just a design intent.
It also weakens incident response and detective control. If you cannot show who actually has conflicting access today, you cannot quickly scope abuse, prove containment, or explain whether a compensating control was active when the access existed. A documented SoD model without live validation creates a false sense of control maturity.
This is why control catalogs consistently pair access restriction with monitoring and review. NIST SP 800-53 Rev 5 Security and Privacy Controls supports the need for enforced access control and auditability, while CIS Controls v8 reinforces account management and access review as operational safeguards rather than paper exercises.
What good looks like in D365 F&O
Good SoD governance in D365 F&O starts with a ruleset that is executable against current entitlements. The control should identify conflicts across roles, duties, privileges, and exceptions, then show whether each conflict is blocked, compensated, or formally accepted. If the control cannot be evaluated against live access, it is not really controlling access.
Practically, the strongest programs connect SoD design to identity lifecycle events, role assignment changes, and periodic recertification. That keeps the control tied to the system of record instead of to a static document that ages the moment someone gets provisioned, transferred, or granted temporary elevation. CSA Cloud Controls Matrix is useful here because its IAM-oriented control families reflect the need to govern access as a live cloud control, not a spreadsheet artifact.
The most reliable evidence is simple: a current entitlement view, a tested SoD ruleset, an exception register with expiry, and a repeatable report showing that live access is checked against the rule set on a defined cadence. Where that evidence is missing, the organization does not have control assurance, only control documentation.
Risk and Threat Considerations
When SoD is only documented, the main risk is that conflicting access persists long enough to create fraud exposure, unauthorized transactions, or unreviewed changes to sensitive business data. The attacker does not need to defeat the policy if the live system already permits the conflicting path.
Failure mechanism: Role accumulation, stale exceptions, cloned access, and untested compensating controls let effective privileges diverge from the approved sod matrix, so the conflict remains present even though the documentation says it is controlled.
Impact: Audit findings, undetected misuse, operational rework, and harder incident scoping follow, because the organization cannot prove which entitlements were actually active when the conflicting action occurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | D365 F&O SoD depends on current account and role governance. |
| AC-6 — Least Privilege | SoD failures often arise when users retain more access than needed. | |
| AU-6 — Audit Review, Analysis, and Reporting | SoD needs evidence that live access and conflicts are being monitored. | |
| Recommendation — Review active assignments and remove conflicting access promptly. Limit roles and duties so no user can complete conflicting actions. Continuously review access logs and entitlement changes for SoD violations. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD breaks when access assignments drift beyond documented separation. |
| Recommendation — Centralize account governance and recertify access on a fixed cadence. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud access governance must enforce SoD in the live entitlement model. |
| Recommendation — Enforce role governance and exception handling as an operational IAM control. | ||
Practitioner Guidance
What to verify: Confirm that every SoD rule can be evaluated against current D365 F&O entitlements, including temporary access and exceptions. If the rule set cannot be tied to live assignments, treat it as design documentation, not evidence of control.
Common mistake: Assuming a clean SoD matrix means the environment is controlled. The usual miss is failing to re-run conflict checks after role changes, emergency access, or custom security updates.
What practitioners underestimate: Compensating controls lose value quickly if they are not time-bound and independently observable. A mitigation that cannot be refreshed, tested, and re-evidenced is not a durable substitute for enforced segregation.
Practitioner takeaway: In D365 F&O, SoD is only real when the live entitlement model is continuously checked against the conflict rules, because documentation without enforcement only proves intent, not control.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org