Why do cross-application permission combinations increase SoD risk?

Why cross-application combinations change the SoD question

Segregation of duties has always been about preventing one identity from completing a sensitive business process end to end. Cross-application combinations matter because modern business flows are split across systems, so the risk is created by the composite path, not by any single permission. A permission set can look safe in isolation and still become toxic when another application closes the control gap.

This is why review based only on one system at a time misses the real exposure. A create action, a submit action, an approve action, and a post action may live in separate tools, but if the same identity can chain them together, the effective authority is much broader than any single entitlement suggests.

That is also why SoD analysis has to look at business function, not just access labels. The relevant question is whether the combined permissions let the same person, service, or bot initiate and complete a transaction with no independent check in between. NHIMG’s Segregation of Duties (SoD) Guide frames this as a ruleset problem, including toxic combinations and compensating controls.

Where toxic combinations emerge in practice

Cross-application conflicts usually arise when one system creates the transaction, another system approves it, and a third system executes or records the outcome. On paper, each role can be legitimate. In practice, the combination removes the independent verification that SoD is supposed to preserve.

The pattern is most dangerous when applications are joined by shared users, synchronized entitlements, API-driven workflows, or poorly scoped admin roles. A user may not be able to approve payments in the finance system alone, but if they can create vendors in one system and approve related changes in another, they may still control the business outcome.

That is why practitioners need to think in terms of effective permissions across the workflow. The same principle appears in cloud and identity programs, where overbroad privilege or mis-scoped roles can create escalation paths even when no single entitlement looks extreme. NHIMG’s Cloud PAM and CIEM Guide applies that logic to right-sizing and escalation-path reduction, while the Privileged Access Management Guide shows how standing privilege and broad admin reach amplify the same problem.

How to reason about SoD risk across systems

SoD risk increases when a single identity can move from request to approval, from preparation to release, or from configuration to execution without a separate control owner. The danger is not the individual permission, it is the business capability that emerges when the permissions are combined across applications.

A practical test is to ask whether the combination lets one identity create, modify, approve, and benefit from the same transaction. If the answer is yes, the control has likely shifted from preventive to detective, and the organisation is relying on review after the fact rather than separation before execution.

That is where role design, joiner-mover-leaver discipline, and access certification all matter. If entitlements are reviewed only within application silos, cross-system toxic combinations remain invisible. NHIMG’s Authorisation Models Guide is useful here because it helps practitioners distinguish simple role assignment from the finer-grained policy logic needed to prevent composite access paths.

Risk and Threat Considerations

Cross-application permission combinations create fraud and abuse risk because they let one compromised or overprivileged identity complete a business process without collusion. The issue is especially serious where procurement, finance, vendor master data, payroll, or release workflows are split across tools and no one is evaluating the full chain of authority.

Failure mechanism: a user or service account accumulates individually acceptable permissions across multiple systems, then uses that combined reach to create, approve, and execute a sensitive transaction without independent oversight.

Impact: the organisation can lose its SoD control, enabling unauthorized payments, concealed fraud, unauthorized data changes, and harder-to-detect abuse because each entitlement appears legitimate on its own.

Practitioner Guidance

What to verify: review access by end-to-end business process, not by application. You want to see whether any identity can complete a sensitive workflow step sequence without a distinct control owner or compensating control.

Common mistake: treating cross-application SoD as a reporting problem instead of an authorization problem. If the control only detects conflicts after access is granted, it is already weaker than the business process it is meant to protect.

Decision rule: if two permissions are harmless alone but together let the same identity originate and complete the same transaction, treat that as a toxic combination and require redesign, stronger approvals, or a compensating control that breaks the chain.

Practitioner takeaway: the real SoD unit is the transaction path, not the entitlement list, so control design has to follow the workflow across systems.

Related resources from NHI Mgmt Group

• Why do Salesforce integrations increase NHI risk?
• Why do cross-application SoD conflicts create more risk than single-system conflicts?
• Why do cross-application access combinations create fraud risk?
• Why do non-human identities create more audit risk than human accounts?