It becomes harder because access decisions, roles, and transaction paths are split across two environments that may not share the same control model. That creates blind spots in approvals, monitoring, and policy enforcement. Without unified rules, a user can accumulate risky permissions across systems even when each application appears compliant on its own.
Why Segregation of Duties Gets Harder Across Oracle EBS and Oracle Cloud
segregation of duties becomes harder because the control boundary is no longer a single application or a single role catalogue. Oracle EBS and Oracle Cloud often enforce access through different models, different approval paths, and different audit evidence. That makes it easy for a user to appear compliant in each system while still holding a toxic combination of privileges across both.
This is not just a role-design problem. It is an identity correlation problem, a transaction-routing problem, and a monitoring problem. Security teams need to see whether one person can create, approve, post, reconcile, and extract data across the combined estate. That is where traditional reviews break down, especially when static entitlements are carried forward during migrations. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats separation of duties as a core control objective, but the practical challenge is merging evidence across platforms without gaps. NHIMG research on the 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge. In practice, many teams only discover overlapping authority after a payment exception, audit finding, or fraud review has already exposed it.
How Control Gaps Form in a Split Oracle Estate
In a side-by-side Oracle EBS and Oracle Cloud deployment, SoD failure usually starts when access is provisioned independently in each environment. A user may have legacy responsibilities in EBS and newer cloud roles that do not look dangerous in isolation. If the GRC or access review process does not reconcile the two identities, the combined access path remains invisible.
Oracle Cloud and EBS also differ in how transactions are approved, logged, and delegated. One system may rely on named responsibilities, another on roles and policies, and the handoff between them may be managed manually. That creates opportunities for bypass, especially where integrations post transactions into one system based on approvals completed in the other. NIST SP 800-53 rev 5 recommends strong separation mechanisms and accountability, but it does not remove the need to map business functions end to end.
Practitioners usually need three controls working together:
- identity correlation so one person has a single risk view across both platforms
- cross-system SoD rules that evaluate incompatible combinations, not just individual entitlements
- continuous monitoring of privileged actions, not only periodic certification
For example, a user who can create suppliers in EBS and approve invoices in Oracle Cloud may never violate either catalog alone, yet still create a payment-control failure. NHIMG’s coverage of the Azure Key Vault privilege escalation exposure shows the same pattern in another control plane: permissions appear ordinary until they are combined across layers. These controls tend to break down when organisations run separate IAM owners, separate audit teams, and separate role models for each Oracle platform because no one owns the combined risk.
Common Variations and Edge Cases in Oracle SoD Design
Tighter SoD enforcement often increases operational friction, requiring organisations to balance fraud prevention against month-end close speed and support workload. That tradeoff becomes sharper during Oracle migrations, where teams need temporary overlap between EBS and Oracle Cloud to keep finance operations running.
Best practice is evolving, but current guidance suggests treating migration roles as time-bound exceptions with explicit expiry, not as permanent dual access. Temporary access should be approved against the combined estate, then removed as soon as a user no longer needs to operate in both systems. This is especially important when service accounts, integrations, or batch jobs trigger business actions that look like user activity unless you classify them separately.
Edge cases usually involve shared services, emergency access, and reporting roles. A read-only role can still become risky if it exposes sensitive master data that supports later fraud or privilege escalation. Similarly, an administrator may not approve transactions directly but can alter configuration in ways that weaken downstream controls. Oracle EBS and Oracle Cloud side by side also complicate evidence collection because audit logs may not align on object names, timestamps, or account identifiers. The result is a control gap that looks small in one dashboard and material in the combined environment. NHIMG’s The 2026 Infrastructure Identity Survey reinforces the governance problem more broadly: 67% of organisations still rely heavily on static credentials, which is a reminder that static access models do not age well in complex shared-control environments.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed across both Oracle estates. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Cross-system secrets and credentials often create hidden SoD bypass paths. |
| CSA MAESTRO | GOV-02 | Hybrid control-plane governance is central to split Oracle deployments. |
| NIST AI RMF | Risk management guidance applies to combined human and machine access paths. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust helps limit lateral movement between Oracle environments. |
Define one governance model for identities, approvals, and exception handling across both platforms.
Related resources from NHI Mgmt Group
- Why do rapid onboarding and deprovisioning become harder as organisations adopt more cloud services and automation?
- Why do healthcare identity programmes become harder to manage as organisations grow and modernise?
- Why does identity security become more difficult when organisations move faster into SaaS and cloud environments?
- Why does identity become harder to govern as organisations scale out their digital environment?
