They should move from system-level rule checks to process-level authority mapping. That means reviewing the full workflow, the identities that can touch it, and the combinations of roles, groups and integrations that complete it. The question is not whether each system is clean, but whether any identity can finish a high-risk process end to end.
Why SoD Governance Has to Follow the Workflow, Not the System Boundary
Segregation of duties only works when the control question matches how work actually gets completed. In connected platforms, that means looking past individual applications and asking whether a single path of access can still initiate, approve, execute, and reconcile one high-risk process. For audit and IAM teams, the unit of analysis is the workflow and its authority chain, not the app silo.
That shift matters because a “clean” control in one platform can still leave an end-to-end privilege path intact through another platform, an integration account, or a delegated role. Effective SoD governance therefore has to map business process stages to the identities and entitlements that can move the process forward, then test whether any one identity can collapse those stages together.
When teams define SoD at the workflow level, they can identify toxic combinations that only appear when roles, groups, service accounts, and middleware permissions are viewed together. A process may look separated on paper, but the connected control plane may still allow one operator to trigger, approve, or override the same transaction through multiple systems.
How to Map Authority Across Connected Platforms
The practical method is to start with the process steps, then map every identity that can touch each step, including human roles and non-human integration paths. That inventory should include direct user access, privileged groups, delegated admin rights, scheduled jobs, API integrations, and any automation that can submit, modify, approve, or post the transaction.
Once that map exists, compare the path against the SoD rule itself. The important question is not whether each platform has separate entitlements, but whether the combined path lets one identity or tightly coupled set of identities complete a restricted process from start to finish. That is where process-level authority mapping becomes more reliable than system-level rule checking.
This also means treating exceptions as part of the design, not an afterthought. If a single team must retain temporary cross-functional access, the control should document the compensating constraint, the review cadence, and the exact scope of what is allowed so audit can verify the exception instead of discovering it as an informal workaround.
Why Cross-Platform SoD Breaks in Practice
SoD failures usually come from coupling that is easy to miss: shared admin groups, broad integration roles, reused service credentials, and approvals that exist in one platform while execution happens in another. A control may be formally separated inside each system, yet still fail because a connected identity can bridge the gap between request, approval, and posting.
NHIMG’s Segregation of Duties Guide is useful here because it frames toxic combinations and mitigations as a governance problem, not just a permissions problem. The same logic applies to connected platforms: if the workflow can be completed by one actor across boundaries, the segregation test has failed.
Audit teams should also watch for hidden control paths created by integrations. An API key, bot account, or privileged connector can turn a nominally separated approval flow into a single controllable path if it has rights to both sides of the process.
Risk and Threat Considerations
Cross-platform SoD gaps create fraud, error, and abuse exposure because the control is only as strong as the longest authority chain. When workflow steps are split across applications, a single overprivileged identity, connector, or admin group can preserve end-to-end power even when no one system appears to violate policy.
Failure mechanism: Segregation is bypassed when shared roles, integration accounts, or delegated privileges let one identity initiate and complete a restricted process across multiple systems, defeating any rule that is checked in isolation.
Impact: The organisation may miss unauthorized approvals, concealed self-service, or unreviewed overrides until after the transaction has already been posted, reconciled, or reported.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Cross-platform SoD relies on limiting any one identity's effective reach across workflow steps. |
| AC-5 — Separation of Duties | The question is directly about governing duties so no single actor can complete a high-risk process. | |
| AU-6 — Audit Review, Analysis, and Reporting | Audit teams need evidence that SoD rules are being tested against real workflow paths and exceptions. | |
| Recommendation — Restrict each workflow identity to the minimum permissions needed to avoid end-to-end process control. Define incompatible workflow roles and prevent one identity from holding conflicting approvals or execution rights. Review transaction and access evidence for end-to-end process paths that collapse separation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Connected-platform SoD depends on governed access decisions across systems and integrations. |
| A.5.3 — Segregation of duties | The subject is SoD governance, including conflicts that emerge across multiple platforms. | |
| Recommendation — Apply consistent access control rules to identities and integrations that touch restricted workflows. Assign and review incompatible duties so one party cannot both execute and approve the same process. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Connected workflows often rely on service accounts or integrations that can collapse SoD when overprivileged. |
| NHI-09 — NHI Reuse | Reusable shared identities can bridge systems and defeat separation between workflow stages. | |
| Recommendation — Right-size non-human access so connectors and automation cannot span conflicting workflow steps. Eliminate reused identities across systems that let one credential chain complete restricted processes. | ||
Practitioner Guidance
What to verify: Test the full business process path, not just entitlement reports. Confirm which identities can create, approve, post, reverse, or reconcile the same transaction across platforms, and document where automation or integration accounts extend that reach.
Decision rule: If one identity can complete the process without a genuinely independent second approval, treat it as an SoD failure even when each platform individually looks compliant. If a compensating control exists, it should be explicit, time-bound, and reviewable by audit.
What good looks like: SoD rules are expressed in process language, mapped to identities and connectors, and reviewed as a single control surface. Audit can trace every high-risk workflow from initiation to completion and show why no actor can carry it end to end without detection or exception.
Practitioner takeaway: Strong SoD governance is measured by whether a connected workflow can be completed by one authority chain, not by whether each platform has a separate access rule.
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 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org