How should organisations discuss segregation of duties and sensitive access before an ERP cloud go-live?

Organisations should treat segregation of duties and sensitive access as design requirements, not after-the-fact audit findings. Teams need to map critical business processes, identify where conflicting access could occur, and confirm controls before go-live. The goal is to prevent users from combining incompatible privileges, reduce overexposure, and ensure the implementation can pass compliance review without redesign.

Why This Matters for Security Teams

Before an ERP cloud go-live, segregation of duties is not just an audit checkbox. It is the control that stops a single user, contractor, or integration account from combining incompatible privileges across procurement, finance, payments, and administration. That matters because ERP failures tend to surface as business process abuse, not just technical misconfiguration. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this as a core access-control concern, while NHIMG’s Ultimate Guide to NHIs shows how quickly access sprawl becomes hard to unwind once identities, secrets, and workflows are live.

Security teams often get this wrong by waiting until role build, test sign-off, or post-launch audit to discover that the same account can create vendors, approve invoices, and release payments. At that point, remediation is slower, business owners are already dependent on the system, and exceptions become the default control.

In practice, many security teams encounter SoD violations only after a workflow has already gone live and business users have started using it at production speed, rather than through intentional pre-go-live design.

How It Works in Practice

The practical approach is to review the ERP process chain end to end and ask where one actor could create, approve, post, or reconcile the same transaction. That mapping should cover human users, service accounts, API integrations, batch jobs, and admin functions. For cloud ERP, sensitive access is often less about one privileged login and more about a web of roles, tokens, and delegated permissions that can be reused outside the original intent.

Current guidance suggests treating access review as a business control exercise, not only an IAM exercise. Start with the highest-risk objects: vendor master data, payment runs, journal entries, tax configuration, user administration, and emergency access. Then define which combinations must never coexist, which ones require approval, and which should be time-bound. A useful pattern is to separate request, approve, execute, and reconcile into different roles, then test those separations with real scenarios before go-live.

This is where evidence matters. NHIMG’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, which is a strong signal that cloud go-live planning often underestimates machine access. If ERP automations depend on service identities, compare each identity’s actual permissions with what the process truly requires, and use policy review against standards such as the OWASP Non-Human Identity Top 10 to catch excessive privilege, secret reuse, and weak lifecycle controls.

• Map SoD conflicts to specific ERP transactions, not just broad job titles.
• Test least privilege with production-like roles, integrations, and fallback paths.
• Separate emergency access from routine access and make it time-limited.
• Validate that service accounts cannot bypass human approval chains.

These controls tend to break down when the ERP design relies on shared admin accounts, custom exceptions, or legacy batch jobs that were never rebuilt for cloud-native identity governance.

Common Variations and Edge Cases

Tighter segregation often increases implementation overhead, so organisations must balance control strength against launch timing, operational flexibility, and support burden. That tradeoff is real, especially when finance teams want speed and auditors want evidence.

One common edge case is emergency access. Best practice is evolving, but current guidance suggests using just-in-time elevation with strong approval, logging, and automatic expiry rather than permanent privileged roles. Another edge case is integration-heavy ERP designs, where middleware, RPA, and vendor connectors need access that looks excessive if viewed only through human job roles. In those cases, the question is not whether the account is privileged, but whether its scope is narrowly constrained to one workflow and one environment.

Cloud ERP also introduces hybrid ownership issues. A business owner may approve the process, IT may manage the platform, and a third party may administer the service. That split can hide conflict unless the access review explicitly names who can request, approve, implement, and attest. NHIMG’s 52 NHI Breaches Analysis and Azure Key Vault privilege escalation exposure show the recurring pattern: overbroad machine access and weak lifecycle control become business-impacting incidents when launch pressure overrides review discipline.

For organisations with complex SoD matrices, the safest language before go-live is that controls are designed, tested, and approved in production-like conditions. There is no universal standard for every ERP variant, but the expectation is consistent: no one identity should be able to initiate, approve, and release the same sensitive business action without an explicit, documented exception.

Related resources from NHI Mgmt Group

• What breaks when organisations do not monitor application controls after an ERP cloud go live?
• How should organisations improve SAP access governance when native segregation-of-duties controls only show technical violations?
• How should organisations perform a segregation of duties health check in Oracle ERP environments?
• How should security teams implement ERP access governance before go-live?