What breaks when organisations rely only on segregation of duties checks in ERP cloud security?

SoD checks catch important conflicts, but they can miss broader sensitive access risks. In practice, the bigger problem is often ineffective role design, where users inherit capabilities they do not need. If teams stop at SoD, they may leave privileged functions in seeded roles and fail to spot access that enables misuse or fraud.

Why This Matters for Security Teams

segregation of duties is necessary, but it is not a complete cloud ERP security model. SoD checks are designed to stop a single person from combining conflicting tasks, yet they do not tell a team whether a role is already too broad, whether privileged functions are buried in a seeded profile, or whether access is still usable for fraud outside the exact conflict rule set. That gap matters because ERP cloud environments often accumulate exceptions faster than they are reviewed.

This is why organisations that rely only on SoD can miss the difference between “no direct conflict” and “safe access.” Current guidance from CSA Cloud Controls Matrix and ISO/IEC 27001:2022 Information Security Management points toward broader access governance, not conflict detection alone. In cloud ERP, privileged actions can be inherited through roles, duty assignments, service accounts, and admin extensions that never surface in a simple SoD review.

NHIMG research on the Snowflake breach and 230M AWS environment compromise shows how broader access paths can persist even when the obvious control looks intact. In practice, many security teams discover the weakness only after a role review or abuse investigation, rather than during design-time control validation.

How It Works in Practice

Effective ERP cloud security starts by treating SoD as one control layer inside a larger access model. The practical problem is that cloud ERP roles are often pre-seeded, composable, and extended by business administrators, which means a user can accumulate sensitive capabilities without ever tripping a classic conflict rule. That is especially true when access is inherited through job codes, indirect assignments, delegated admin features, and integration accounts.

A stronger approach combines SoD with role engineering, privileged access review, and entitlement analysis. Security teams should map what each role can actually do, not just whether two duties conflict on paper. This usually means:

• Reviewing seeded roles for hidden administrative or financial functions.
• Separating business use roles from elevated operational roles.
• Using time-bound elevation for rare tasks instead of permanent access.
• Checking service accounts, integrations, and batch jobs for privileged ERP actions.
• Validating that SoD rules cover indirect access paths, not only direct assignment.

For governance maturity, The State of Non-Human Identity Security is useful because it shows how often organisations still lack confidence in identity controls and over-privileged access remains common. That matters in ERP because machine-to-machine access, API connectors, and automation agents can bypass the human-centric assumptions behind SoD. The right question is not just “is this duty separated,” but “can this identity, role, or integration still move money, change vendors, or alter approvals?” These controls tend to break down in highly customised ERP tenants because local role exceptions, emergency access, and third-party integrations outgrow the original SoD matrix.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance fraud reduction against business continuity and support effort. That tradeoff becomes sharper in ERP cloud programs where finance, procurement, and operations need rapid exception handling and where release cycles can change role behaviour without formal security review.

There is no universal standard for this yet, but current guidance suggests SoD should be paired with exception governance and compensating controls. For example, a user may pass SoD checks and still retain dangerous capability through a delegated approval path, a temporary admin grant that was never revoked, or an integration token that has broader reach than the human user behind it. The Azure Key Vault privilege escalation exposure illustrates why role scope and privilege boundaries must be checked beyond classic conflict rules.

In practice, the most important edge cases are seeded superuser roles, emergency access workflows, and third-party connectors that are exempt from ordinary user SoD policy. A mature program will test for toxic access combinations, but it will also review whether the role model itself is too permissive, whether monitoring can detect misuse, and whether access removal is fast enough after a task ends. SoD is a detection control; it is not a substitute for least privilege or access design.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on posture checks for NHI security?
• What breaks when organisations rely on cloud storage security without data loss prevention?
• What breaks when organisations rely on traditional security controls instead of CASB in cloud environments?
• What breaks when organisations rely on configuration checks alone for AI workload security?