How should security teams implement cross-application SoD in modern enterprise workflows?

Why This Matters for Security Teams

Cross-application segregation of duties is no longer limited to a single ERP control. Modern workflows span SaaS apps, cloud consoles, APIs, and non-human identities, so the real risk is not just who can approve a payment or deploy code, but who can combine permissions across systems to complete an action without meaningful oversight. That is why security teams need process-level controls, not isolated role checks. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it emphasises governance, access control, and continuous oversight rather than one-time provisioning.

The practical challenge is that cross-application SoD usually fails at the join points: identity data is fragmented, entitlements are named differently, and business owners only see violations after the fact. NHI governance makes this harder because service accounts, API keys, and OAuth grants can execute steps that used to require a human user. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that turns a simple workflow into an unreviewed control bypass.

In practice, many security teams encounter SoD violations only after an auditor, fraud case, or production incident has already exposed the cross-system path.

How It Works in Practice

Effective cross-application SoD starts with a business-process map, not a role catalogue. Security and application owners should document the end-to-end workflow, identify each decision point, and define which combinations of actions must never sit in the same effective identity. That includes human users, service accounts, machine identities, and delegated OAuth access. The control objective is to prevent one actor from initiating, approving, and executing the same sensitive process across applications.

From there, teams should build entitlement correlation across systems. That means normalising permissions from ERP, ITSM, cloud, CI/CD, SaaS, and API layers into a single policy model. A worker may appear compliant in each system individually, yet still violate SoD when permissions are combined. Current guidance suggests evaluating this at request time and review time, not only during provisioning. NIST’s Cybersecurity Framework 2.0 supports that posture because it treats access governance as an ongoing function, not a static event.

• Define SoD rules around business outcomes, such as create, approve, and release.
• Map each rule to all participating applications, including NHIs and API clients.
• Continuously reconcile entitlements so inherited access and delegated tokens are included.
• Route violations into access review, ticketing, or approval workflows with named owners.

For NHI-heavy workflows, combine this with lifecycle hygiene. NHIs should use least privilege, short-lived secrets, and explicit ownership, because a stale integration can quietly preserve a SoD breach long after the human user has changed roles. The NHIMG research library shows how fragile these environments can be, especially when secrets leak across pipelines or vendor-connected apps, including the GitHub Action tj-actions Supply Chain Attack case study. These controls tend to break down when entitlement sources cannot be normalised across legacy ERP, custom APIs, and shadow SaaS because the SoD engine cannot reliably see the full effective permission set.

Common Variations and Edge Cases

Tighter SoD often increases review and integration overhead, requiring organisations to balance stronger fraud prevention against slower workflow execution. That tradeoff becomes more pronounced when one business process spans multiple application owners, because no single team controls the full control path. Best practice is evolving here: there is no universal standard for how to encode cross-application SoD, so many organisations start with the highest-risk workflows and expand gradually.

Edge cases usually involve delegated access and automation. A user may not hold the conflicting permission directly, but an agent, bot, workflow engine, or service principal may do the restricted action on their behalf. That is why teams should treat third-party OAuth grants, admin automation, and service-to-service trust as part of SoD scope, not exceptions. When a workflow spans finance, HR, and cloud infrastructure, the policy must account for the full chain of custody, including temporary elevation and privileged session replay. NHIMG’s State of Non-Human Identity Security is a useful reminder that visibility gaps remain common, especially where third-party OAuth access is involved.

Where the model breaks down most often is in highly customised enterprise workflows with poor system integration and no authoritative entitlement source, because the SoD decision becomes impossible to evaluate consistently.

Related resources from NHI Mgmt Group

• How should security teams evaluate SoD software for cross-application conflicts?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?