Conflicts often emerge from accumulated access rather than from a single role. Derived roles, temporary assignments, emergency access, copied templates, and organisational values can create the toxic combination only when evaluated together. That is why role-level review alone is not enough.
Why clean SAP roles can still produce SoD conflicts
Segregation of Duties is not just a role-design problem, it is an effective-access problem. A role can look clean in isolation and still participate in a toxic combination once you add derived access, temporary elevation, emergency access, copied templates, or values inherited from another assignment. The real question is what the user can do in total, not what any single role appears to allow.
That is why role review by itself often misses the conflict. The SoD rule engine has to evaluate the full access graph, including direct entitlements, inherited permissions, and organisational exceptions, before it can tell you whether the person can complete a risky business process end to end.
How accumulation creates hidden toxic combinations
Conflicts usually appear when multiple individually acceptable pieces of access combine across time or context. A derived role may add one side of a sensitive transaction, a temporary assignment may add the other, and a firefighter or emergency role may quietly bridge the gap during incident handling. Copied templates and default values can also import access you did not intend to review as part of the “clean” base role.
In practice, this means SoD analysis has to look beyond static entitlement names. The same user may be safe at role level and unsafe at assignment level, especially when access is accumulated from different sources or when role values are driven by organisational attributes rather than by a single catalogued role.
For deeper background on the control model, the Segregation of Duties (SoD) Guide explains how toxic combinations, compensating controls, and access-governance review fit together across roles, mitigations, and exception handling.
Why SAP review has to be person-centric, not role-centric
SAP environments are especially prone to false confidence because access can be assembled from multiple layers: composite roles, derived roles, organisational assignments, and special-purpose access paths. If you only certify the base role, you may miss the effective privilege set that actually exists in production.
The practical review unit is the user or account, then the complete access bundle attached to that identity. That includes standing access, temporary access, emergency access, and any access inherited from templates or organisational values. A conflict is present when the combined access enables both sides of the SoD rule, even if each source looks acceptable on its own.
Because temporary or emergency access often bypasses the normal approval path, teams should treat those assignments as first-class inputs to SoD analysis, not as exceptions to review later. The point is not to assume bad intent, but to recognise that time-bound privilege can still create a real control breach while it exists.
What to check before you trust a clean role report
Clean role output should be treated as a starting point, not an assurance. Verify whether the role report includes derived access, indirect assignments, temporary elevations, emergency accounts, and copied-template inheritance. If it does not, the report may be structurally unable to surface the conflict you actually care about.
You should also verify whether the SoD rule set evaluates the final effective access state, not just individual role memberships. Where the business process is spread across multiple transactions or functions, the conflict may only become visible when all privileges are evaluated together.
For control design and access review discipline, NIST SP 800-53 Rev. 5 Security and Privacy Controls provides the broader access-control and audit framing, while the NIST Cybersecurity Framework 2.0 helps organise governance, identification, protection, detection, and recovery around access-related risk.
Risk and Threat Considerations
SoD gaps matter because they can create fraud opportunity, unauthorised transaction completion, and weak detective coverage even when individual roles seem well designed. The main failure is not a bad role, it is an incomplete picture of cumulative access across assignments and exceptions.
Failure mechanism: A user accumulates complementary privileges through derived roles, emergency elevation, temporary access, or copied templates, and the combined access satisfies a toxic combination that no single role exposed on its own.
Impact: A control owner may miss a real segregation breach, allowing one identity to initiate and complete a sensitive process, bypassing intended approval or review boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | SoD issues arise from accumulated access and exceptions that account reviews must catch. |
| Recommendation — Review effective access regularly and remove standing privilege that creates toxic combinations. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Effective access must be bounded so combined entitlements do not create excessive privilege. |
| AU-6 — Audit Review, Analysis, and Reporting | SoD conflicts require auditability of derived, temporary, and emergency access paths. | |
| Recommendation — Apply least privilege to the final access state, not to each role in isolation. Correlate audit events and access history to detect toxic privilege combinations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must consider inherited and temporary entitlements that change effective privilege. |
| A.5.18 — Access rights | Access rights governance must cover provisioning, modification, and revocation of accumulated access. | |
| Recommendation — Define access control rules that assess effective privileges across all assignment sources. Review and revoke access rights based on the total entitlement set, not isolated roles. | ||
Practitioner Guidance
What to prioritise: Review the effective access state for each user or account, not the cleanliness of the base role catalogue. In SAP, that means checking inherited, temporary, and emergency access alongside the role itself.
What to verify: Confirm that SoD analysis is run on the final privilege set and that exception access is included in the same control cycle as ordinary access. If the review excludes time-bound or derived access, it is not testing the real risk.
Common mistake: Treating role certification as equivalent to SoD assurance. A clean role can still be part of a toxic combination when another entitlement completes the path.
Practitioner takeaway: SoD is only reliable when the control evaluates combined access, because toxic combinations are usually created by accumulation, not by a single visibly bad role.
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 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org