They let teams test conflicting access conditions against the real authority chain instead of a flat entitlement list. That matters because segregation of duties can be violated by inheritance, not just by obvious direct grants, and the control only works when the review scope matches the actual path to privilege.
Why path-based queries are the right test for SoD
Segregation of duties is not just about who has a permission in the abstract, it is about whether a person or system can reach a conflicting action through the real access path. Path-based queries expose inherited roles, nested groups, delegated access, and policy chains that a flat entitlement list can hide, so they better reflect how privilege is actually exercised.
That matters in reviews because SoD failures often emerge from combination, not from any single grant. A path view lets analysts test whether two “safe” accesses converge on the same sensitive operation, which is the condition that usually turns an apparently compliant account into a toxic one.
When the query follows the authority chain, it also improves scoping discipline. Teams can separate direct assignment from effective access, which helps them distinguish a true SoD violation from a harmless permission that cannot be used without an additional step or control.
What path analysis reveals that entitlement lists miss
A flat list tells you what an identity appears to hold; it does not tell you how that access was assembled, inherited, or amplified. Path-based access queries reveal whether access came through a role hierarchy, group nesting, shared administration model, or application-specific policy, and those routes can create hidden combinations that matter more than the raw permission count.
This is especially important where one control owner reviews one system while another owns the upstream grant. If the review only checks the leaf permission, it can miss that the real exposure sits one step earlier in the chain, such as a parent role, a group membership, or a delegated entitlement that indirectly unlocks the conflicting action.
For SoD design, the practical insight is that the unit of review should be the effective path to privilege, not the entitlement fragment in isolation. That is how you catch cases where two separated duties recombine through inheritance, shared platforms, or cross-system trust relationships.
How teams should use path queries in SoD reviews
Path-based queries are most useful when they are tied to a defined conflict model. Start with the sensitive business action, then trace every route that can reach it, including inherited access and indirect control points, so the review can answer whether the same actor can both initiate and approve, request and fulfil, or create and release.
For this reason, the Segregation of Duties (SoD) Guide is the most direct reference for building conflict rules, compensating controls, and exception handling around real access paths. If your organisation uses role models or externalised authorisation, the Authorisation Models Guide helps you understand how RBAC, ABAC, and ReBAC can create different path shapes that affect SoD evidence.
Where access governance is broader than one control family, IAM and IGA Basics is useful for connecting SoD review to provisioning, access certification, and entitlement governance. That is the point where SoD becomes operational, because a review that cannot trace the path also cannot reliably prove revocation, recertification, or exception closure.
Risk and Threat Considerations
Path-based SoD controls fail when teams assume that direct assignment is the only risk surface. Inheritance, nested membership, and delegated authority can create a valid-looking permission set that still lets one actor reach conflicting duties, which is a classic control gap in fraud-prone and approval-heavy workflows.
Failure mechanism: A user or system receives separate grants that look acceptable in isolation, but the combined access path reaches a conflicting sensitive function through hierarchy, nesting, or delegation.
Impact: The organisation can lose the segregation that prevents self-approval, self-release, or unauthorized override, increasing fraud, error, and audit failure risk.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Path-based SoD queries test whether effective access exceeds necessary privilege. |
| AC-2 — Account Management | SoD reviews depend on governed account and entitlement lifecycle, not just static lists. | |
| AC-5 — Separation of Duties | The question is about verifying separation across real access paths and conflicting duties. | |
| Recommendation — Trace effective access paths and remove unnecessary privilege that enables SoD conflicts. Maintain account and entitlement inventories that support path-aware SoD review. Implement SoD checks that evaluate inherited and delegated access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Path-based SoD queries strengthen access control by evaluating effective rather than nominal permissions. |
| A.5.18 — Access rights | SoD reviews require visibility into granted rights and their inherited effect. | |
| Recommendation — Define access control rules that assess effective privilege paths for conflicting duties. Review access rights for indirect combinations that create SoD conflicts. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SoD depends on managing who can reach sensitive actions through the full access path. |
| Recommendation — Validate access control decisions against effective paths to critical functions. | ||
Practitioner Guidance
What to prioritise: Review the highest-risk business workflows first, especially where one identity can create, approve, and execute outcomes across different systems. Those are the places where hidden inheritance matters most because a single unexpected path can invalidate the control.
What to verify: Confirm that your query resolves effective access, not just assigned access, and that it traverses nested groups, role inheritance, service accounts, and delegated administration where those exist. If the review tool cannot show the full path, treat the result as incomplete rather than compliant.
Common mistake: Treating SoD as a role catalog problem instead of an access-path problem. The catalog may look clean while the runtime path still allows the same person or process to reach both sides of the conflict.
Practitioner takeaway: SoD only holds when the review follows the route to privilege that the system actually enforces, because hidden inheritance is often where the real violation lives.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- When should organizations review access controls?
- Why do browser-based controls matter for contractor and third-party access?
- Why do identity proofing controls matter when authentication already uses MFA and risk-based access policies?
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org