Oracle RMC control gaps: mitigation and materialized-risk detection

At a glance

What this is: This analysis argues that Oracle Risk Management Cloud can flag risk, but cannot by itself prove mitigation execution or materialized-risk detection across Oracle and connected systems.

Why it matters: For IAM, SOX, and NHI governance teams, the gap is evidentiary: accepted elevated access must be continuously tied to real controls and activity, not just logged as an exception.

👉 Read SafePaaS's analysis of Oracle RMC control gaps and materialized-risk detection

Context

Oracle environments often contain some elevated access that cannot be fully removed without breaking operations. The governance problem is not whether risky access exists, but whether teams can prove it was monitored, mitigated, and did not result in misuse across Oracle and connected applications. For NHI governance, that is the same structural issue seen with service accounts and other non-human identities: the control challenge is evidence, not just entitlement.

Oracle Risk Management Cloud can support SoD rules and access checks, but the source article says it remains constrained by Oracle’s own role and inheritance model. That limitation creates a practical control boundary for IAM leaders, who need independent proof that compensating controls executed across the full period under review. The starting position described here is common in finance-heavy enterprise estates, not unusual.

Key questions

Q: How should teams handle accepted SoD conflicts in Oracle ERP environments?

A: Treat accepted SoD conflicts as monitored risks, not static exceptions. Assign each one a named compensating control, define the review period, and require evidence that the control executed for the affected users and transactions. If the control cannot be proven, the conflict is not really governed, only documented.

Q: Why do native ERP reports often fall short for audit-ready risk proof?

A: Native ERP reports usually prove assignment, not execution. They can show who had access, but not whether approvals, reconciliations, or exception checks actually ran across the full period under review. Audit-ready proof needs independent correlation between access, activity, and control operation.

Q: What breaks when mitigation controls are only tracked in spreadsheets?

A: Spreadsheets create a record of intent, but they do not reliably prove that a control ran for every user and every period. Over time, that leaves gaps between the accepted risk, the assigned mitigation, and the evidence presented to auditors. The result is governance by assumption.

Q: How can security teams prove elevated access did not become materialized risk?

A: Correlate elevated access with approvals, tickets, and transaction logs during the exact period of elevation. Then test whether any actions exceeded the approved pattern or crossed materiality thresholds. The answer should show both what the user could do and what they actually did.

Technical breakdown

Why accepted SoD conflicts become an evidence problem

Segregation of Duties conflicts are not always removable in ERP systems because business processes require some privileged combinations. The technical issue is that once a conflict is accepted, the control objective changes from prevention to detection and proof. Oracle RMC can surface conflicts and support review workflows, but it does not inherently create an independent evidence layer that links specific access, approvals, reconciliations, and transactions across time. Without that link, teams can show entitlement, but not control operation. For IAM and NHI governance, that distinction matters because auditors and risk owners care about whether the control actually ran, not whether the role label looked acceptable.

Practical implication: Treat accepted conflicts as monitored risk objects, not static exceptions.

How mitigation monitoring differs from access review

Mitigation monitoring asks whether a compensating control actually executed for each relevant user and period. That is different from periodic access certification, which only confirms whether access was still assigned. A reconciliation, secondary approval, or exception-based report is only meaningful if the team can show it covered the full population under review and not just a sampled subset. The article’s core point is that native ERP controls often stop at role awareness, while governance teams need a stronger chain from elevated privilege to control execution to documented outcome. That is the evidentiary layer many IAM programmes lack today.

Practical implication: Use control-to-user-period mapping so every mitigation has verifiable execution evidence.

Materialized-risk detection across Oracle and connected applications

Materialized risk is the point at which theoretical privilege becomes an actual event, such as an unauthorized posting, improper payment, or exception outside policy during a defined window. Detecting that requires correlating effective access, approvals, tickets, and transactions across systems, not just reading Oracle-native access reports. The article describes this as a period-specific query problem: teams need to ask what a user could do, what they were approved to do, and what they actually did. That architecture is especially relevant when Oracle workflows span ServiceNow, Coupa, or other adjacent systems that carry part of the control evidence.

Practical implication: Build cross-system queries that can prove whether elevated access produced any policy-breaking action.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Accepted risk is now a governance object, not a cleanup task. When Oracle SoD conflicts are structurally necessary, the security question shifts to whether each conflict has a living mitigation with provable execution. Static exception logs do not satisfy that requirement because they do not show the control firing over time. The practical conclusion is that teams should treat accepted risk as something to monitor continuously, not something to document once and file away.

Independent evidence matters more than native system reporting. Native ERP views can show assigned access, but they are not enough when the control question is whether access was actually contained and observed. The broader NHI lesson is that runtime evidence must be generated outside the system under test whenever the control owner and the system owner are the same. Practitioners should favour evidence paths that are independently reconstructable.

Materialized-risk detection is becoming the real audit test. Auditors increasingly want proof that elevated access did not produce a loss, misstatement, or unauthorized transaction during a relevant period. That raises the bar from role governance to outcome governance. For NHI and IAM teams, this is the same shift seen with service accounts and emergency access: entitlement management alone is no longer enough.

The control gap here is a preview of broader NHI governance failure. If a team cannot connect risky access to a monitored mitigation and a period-specific outcome, then the programme is relying on assumptions rather than evidence. That pattern will not scale as autonomous systems and machine identities take on more operational authority. Practitioners should re-evaluate whether their current controls can survive an audit that asks what actually happened, not what should have happened.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a broader control model, see NHI Lifecycle Management Guide for lifecycle governance patterns that keep elevated access from becoming standing risk.

What this signals

The programme-level signal is that evidence quality is becoming a control domain in its own right. As organisations extend privileges to more autonomous systems, the old split between access management and audit evidence will keep breaking down. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, practitioners should expect stronger pressure for independently reconstructable control evidence.

Identity blast radius: the real governance metric is no longer only who has access, but how far that access can move before a control interrupts it. That framing matters for ERP, cloud, and agentic workloads alike. Teams that can trace access, approvals, and outcomes across systems will be better positioned for both audit and incident response.

For practitioners

• Map accepted Oracle conflicts to named compensating controls Create a control register that links each accepted SoD conflict or elevated role to a specific reconciliation, approval workflow, or detective report. The goal is to tie each risk to a control that can be tested for execution in the review period.
• Test mitigation execution for every user and period Move beyond sample-based review and verify that each mitigating control ran for every applicable user, close cycle, and emergency access window. Use the review period as the unit of proof, not just the entitlement list.
• Correlate access with upstream and downstream evidence Join Oracle entitlements with tickets, approvals, exceptions, and transaction records so you can prove whether elevated access matched the approved pattern. This is essential for vendor requests, payment actions, and quarter-end journal activity.
• Separate entitlement checks from materialized-risk queries Run one process to confirm who had access and a second to determine what they did during the elevated window. That separation keeps access review from becoming a false proxy for control effectiveness.
• Build audit-ready evidence outside the system under test Preserve a control layer that can independently reconstruct access, approvals, and transaction outcomes without relying only on Oracle-native reports. Independent reconstruction is what makes the evidence defensible under audit.

Key takeaways

• Oracle RMC can surface control risk, but it does not by itself prove that compensating controls actually operated over time.
• The relevant governance question is shifting from entitlement review to period-specific evidence of mitigation and transaction outcome.
• IAM and NHI teams should design independent control reconstruction now, because audit expectations are moving toward materialized-risk proof.

Key terms

• Segregation of Duties conflict: A Segregation of Duties conflict exists when one identity can combine steps that should be separated to reduce fraud or error risk. In ERP environments, some conflicts are unavoidable, so the control objective becomes documenting and proving compensating controls rather than pretending the risk can always be removed.
• Mitigating control: A mitigating control is a compensating safeguard used when risky access cannot be eliminated. It may be a reconciliation, approval workflow, detective report, or exception review. In practice, the control is only meaningful if a team can prove it executed for the relevant users and period.
• Materialized risk: Materialized risk is the point where theoretical access exposure becomes an observable adverse outcome, such as an unauthorized posting, improper payment, or policy breach. The term matters because auditors and risk owners increasingly care about evidence of actual impact, not just the presence of access.
• Effective access: Effective access is the real set of permissions an identity can use after roles, inheritance, and policy overlays are combined. It is more useful than raw role assignment because it reflects what a user could actually do inside the environment, which is the basis for monitoring and audit proof.

Deepen your knowledge

Mitigation monitoring, materialized-risk detection, and evidence reconstruction are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model around elevated access and audit proof, it is worth exploring.

This post draws on content published by SafePaaS: The Two Control Gaps Oracle Risk Management Cloud Can’t Provide. Read the original.