Oracle Fusion Security: What Oracle Patches and What You Still Own

Oracle Fusion Security Is Not Fully Managed for You

A lot of Oracle Cloud ERP customers assume security is Oracle's problem. It isn't—at least not entirely.

Oracle patches and hardens the underlying platform. That part genuinely is handled for you. But everything inside your tenant? That's yours.

How users are provisioned. How roles are designed. Which integrations have API access. What gets logged. All of it sits with you.

This is the shared responsibility model, and it catches teams off guard more than it should.

Think of it this way: Oracle secures the building. You're responsible for the locks, the keys, and who has copies of both.

That means your team owns identity governance across the joiner/mover/leaver lifecycle, role design and segregation of duties, privileged access controls, integration and API accounts, and audit logging. If a user has accumulated excessive roles across three job changes—or an API account was set up with admin access "temporarily" two years ago—Oracle patches won't catch that. Those are tenant-level decisions, and they stay your responsibility.

We see this constantly during security reviews.

The root cause is almost never a missing patch. It's misconfiguration, access that was never cleaned up, or roles that expanded gradually without anyone noticing.

If you're coming from on-prem, the dividing line sits in a different place—but the principle doesn't change. Cloud doesn't mean you can outsource accountability. For a direct comparison of where responsibilities sit when you control the full stack, see our perspective on Oracle EBS security.

The Short Answer: A Shared Model With Real Gaps

Oracle Fusion Applications runs on a shared responsibility model. Oracle handles the infrastructure and patches the platform. What happens inside your tenant is entirely your problem.

That distinction matters more than most teams realise when they first go live.

Oracle's side of the deal is fairly well-defined. They manage the underlying cloud infrastructure, apply quarterly Critical Patch Updates (CPUs), and push service updates across the Fusion stack—database, middleware, application code. You don't schedule those patches or touch the underlying servers. That part is genuinely taken off your plate.

But your security posture inside the tenant? That's on you. All of it.

Role design, segregation of duties, user provisioning, approval policies, data access controls—Oracle doesn't configure any of that. Custom objects, BI Publisher reports, fast formulas, custom code: if you built it, you secure it. Integrations are another gap we see constantly during audits. API credentials, token handling, IP allowlists, end-to-end logging—none of that is Oracle's responsibility.

The tricky part is that nothing breaks visibly when these controls are missing.

Roles get over-permissioned gradually. Integration accounts accumulate access over time. Audit logs go unreviewed for months. The platform stays green while your actual exposure quietly grows.

What Oracle Patches Automatically in Fusion Cloud

Oracle owns patching for the parts of the stack it runs. That means the underlying infrastructure, core platform services, the database layer, and Oracle-managed middleware supporting Fusion applications.

The practical outcome: most platform-level vulnerability patching happens without you scheduling downtime, uploading patch files, or running patch cycles yourself.

Oracle Critical Patch Update (CPU) cadence

Oracle's scheduled, recurring release cycle for security fixes across Oracle products and cloud services.

1) Infrastructure and virtualization (Oracle-owned)

Oracle handles security updates for compute, storage, network fabric, hypervisors, and the control planes keeping the service running. You don't have administrative access to those layers in a SaaS model. So you can't patch them even if you wanted to.

From a security program standpoint, treat these as provider-managed controls. Your job is evidence and assurance—attestations, service documentation, internal risk reviews. Not execution.

2) Database layer provided with Fusion (Oracle-owned)

Where the Fusion service includes an Oracle-managed database, Oracle applies the relevant security fixes as part of operating it. Vulnerability remediation, hardening updates, keeping it supported—that's Oracle's responsibility.

You don't run database patching utilities in Fusion SaaS. Oracle does.

3) Oracle-managed middleware and platform components (Oracle-owned)

Fusion Cloud depends on middleware services, runtime components, and supporting platform services that Oracle manages and patches.

This matters more than it sounds. A significant share of published vulnerabilities target middleware and platform frameworks. In Fusion Cloud, Oracle owns the fix cycle for those layers entirely.

4) Quarterly Critical Patch Updates applied to the managed stack (Oracle-owned)

No patch downloads on your end. No regression testing of platform binaries. No coordination of patch application steps for Oracle-managed services.

Oracle publishes security fixes on a regular CPU schedule and applies them to the managed Fusion Cloud stack directly. That's the key difference from on-prem or self-managed Oracle environments, where all of that falls on your team.

For broader context on how the CPU release rhythm works and how to think about it operationally, see patch updates. Useful for internal governance—aligning review cycles, stakeholder communications, and change-management expectations around the same cadence Oracle uses.

What this means operationally

For Fusion Cloud customers, patching the Oracle stack is largely a provider-run motion. Oracle identifies applicable vulnerabilities, packages fixes, and applies them as part of running the service.

Your internal patch reporting should reflect that. Instead of "we patched X servers," your evidence is "Oracle applied updates to the service"—plus your own verification steps: release note monitoring, change impact reviews, control mapping.

The boundary matters, though. Oracle's automatic patching reduces exposure in the managed layers. It doesn't eliminate security work inside your tenant.

Treat Oracle's patching as a strong baseline. Then make sure your governance and monitoring cover the configuration and access decisions that remain in your hands.

Security Controls That Remain Your Responsibility

Even when Oracle is patching and operating the Fusion Cloud platform, your tenant can still be exposed. Configuration gaps, weak processes, unmanaged data flows—these are where real incidents come from. In our experience, the vast majority of Fusion security problems aren't platform bugs. They're day-to-day decisions: who got access, what role they were given, whether a credential was ever rotated, what happened to that scheduled extract.

1) User provisioning and role segregation (SoD)

You control who gets access, when they get it, and at what privilege level. Access requests, approvals, emergency access, revocation—all of it lands with you.

Consistency is everything here. The same access request should produce the same outcome every time. Every privileged change should trace back to a named individual, not a shared account.

Key practices to own and maintain:

• Joiner/mover/leaver process: Tie HR events directly to access changes. "Movers" are where risk quietly accumulates—people collect roles across departments and nobody removes what they no longer need.
• Role assignment standards: Define which job roles are valid for which org units, legal employers, and data access scopes. Avoid broad role bundles that make approvals easy but silently expand access.
• SoD controls: Enforce segregation between create/approve/pay, supplier setup/payment, journal entry/posting, and similar high-risk combinations. Where exceptions are unavoidable, document compensating controls and time-bound them. Don't leave exceptions open-ended.

2) Fusion Security Console configuration (and why it's a frequent source of drift)

Security Console is powerful. That's exactly the problem.

Small tenant-side changes can have outsized impact—especially when someone makes them under pressure. During a go-live, an acquisition, a production emergency at 11pm. We see this constantly during audits: a change gets made, the crisis passes, and nobody reverses it.

What to treat as production security configuration—not casual admin work:

• Administrative role assignments: Keep a short list of who can administer users, roles, and security policies. Review it regularly. Short means short.
• Session and sign-in controls: Document your intended settings for authentication, session timeouts, and access policies. Verify them after major releases and identity changes—they can drift without anyone noticing.
• Role hierarchy changes: A seemingly minor duty role tweak can propagate additional privileges to dozens of users through inheritance. Test changes in a controlled environment and maintain versioned documentation of role design decisions.

3) Audit and reporting setup (including evidence you can actually use)

Audit capability is only useful if it captures the right events, is retained long enough for investigations, and is actually reviewed by someone accountable.

A common assumption we see: "audit is on by default."

It's not always. And those gaps tend to surface at the worst possible moment—when an auditor or incident responder is asking for logs.

Own these decisions:

• What to audit: Focus on privileged actions (role and user changes, security policy changes), financial master data, supplier and bank account changes, and approvals. Align with your internal control framework.
• Retention and access: Decide how long logs are kept and who can view or export them. Audit data is sensitive—treat it that way.
• Monitoring workflow: Assign someone responsibility for review. Define escalation paths. Set a cadence—daily or weekly depending on risk. The best audit setup still fails if nobody looks at it.

4) Custom OTBI/BIP reports with sensitive data

Custom reporting is one of the fastest ways to unintentionally broaden access to regulated or confidential data. OTBI and BI Publisher can expose PII, payroll data, bank details, or customer records depending on your modules and subject areas.

Controls to put in place:

• Report inventory: Maintain a living list of custom OTBI analyses, dashboards, and BIP reports—including owners and last review date.
• Data classification: Label reports that contain sensitive fields and apply stricter access rules to them.
• Distribution controls: Be careful with bursting, email delivery, shared folders, and exports. A report that's secure inside Fusion becomes unsecured the moment it's downloaded to a laptop or emailed externally.
• Change management: Treat report creation and changes like code: peer review, test, promote, document.

5) Third-party integrations and API credentials

Integrations tend to get built with broad access because it's easier and less likely to break something. That's also why they're a high-value target. Treat every integration user and API client like a privileged account—because that's what it is.

What to own:

• Credential lifecycle: Centralise where secrets live, rotate them on a schedule, and rotate immediately after staff changes or suspected exposure.
• Least privilege integration roles: Create dedicated roles for integration service accounts. Don't reuse powerful job roles because it's convenient.
• Inbound/outbound data control: Map what's being pulled or pushed, justify each data element, and re-check after interface changes.
• Monitoring: Log integration calls where possible, alert on unusual volumes, and investigate repeated failures—they can indicate credential stuffing or misconfiguration.

6) Data residency, exports, and cross-border controls

Oracle handles cloud hosting. You still control what data is extracted, where it goes, and who it's shared with.

Common exposure points: scheduled extracts to SFTP, data replication to analytics platforms, ad hoc exports by power users, files sent to vendor support. Each one is a potential gap.

Practical controls:

• Export governance: Define who can export, what formats are allowed, and where files can land.
• DLP-style checks (process-based if tooling is limited): Require justification and approvals for exporting regulated datasets—payroll, bank details, national IDs.
• Third-party storage review: If extracts land in other clouds or tools, confirm encryption, access control, and retention there—not just in Fusion.

7) Incident response procedures (for Fusion-specific scenarios)

When something goes wrong, speed and clarity matter.

Your incident response plan needs Fusion-specific steps: who can suspend users, how to preserve audit evidence, how to safely disable integrations, how to communicate internally. Make sure you have:

• Runbooks for common incidents—credential leak, suspicious admin activity, sensitive report exposure, compromised integration.
• Clear decision rights: who can revoke access, approve emergency changes, and engage Oracle Support.
• Post-incident review: identify the tenant-side root cause—process, configuration, or training gap—and put a control in place before it happens again.

If you want Fusion security to hold up under audits and real incidents, treat these areas as an ongoing operating program, not a one-time setup task. The tenants that do this well have disciplined access governance, controlled Security Console changes, monitored audit signals, and tight control over data leaving Fusion. That's the standard worth building toward.

Custom Extensions, VBCS Apps and Integration Security

Custom extensions change the risk profile of Oracle Fusion because they sit outside Oracle's patching scope. The moment you build an app in Visual Builder Cloud Service (VBCS), deploy an Oracle Integration Cloud (OIC) flow, or create a REST API consumer that reads or writes Fusion data, you've introduced code, configuration, and credentials that only you can secure and maintain.

Oracle patches Fusion Cloud services. It cannot patch your JavaScript in a VBCS page, your OIC mapping logic, or the way your API client stores tokens. That gap is entirely yours to close.

Treat extensions like any other application. Apply secure coding standards, test for abuse cases, and review controls whenever changes ship.

What you still own for VBCS and custom UI

We see this constantly during technical audits: VBCS apps get treated like built-in Fusion screens, so basic security controls get skipped. They shouldn't.

The areas that get missed most often:

• Secure coding and input handling: Validate input server-side, not just in the UI. Don't expose internal IDs or query logic in client-side code.
• Authentication and session management: Use the correct identity provider settings, enforce MFA where required, and don't let "internal" users fall back to weaker auth.
• Authorization checks: A hidden button is not access control. Enforce authorization at the API and service layer—not just in the interface.
• Secrets handling: No tokens, client secrets, or endpoints hard-coded in VBCS source or stored in plain text config.

What you still own for OIC and integration security

OIC is where security drifts fastest.

Teams treat it as plumbing. In practice, it's a privileged channel directly into Finance, HCM, and Procurement—and it needs to be treated that way.

Key ownership areas:

• Connection authentication choices: Use OAuth where appropriate, rotate credentials, and avoid shared service accounts that can't be traced to a business owner.
• OAuth token lifecycle: Manage token scopes, expiry, refresh behaviour, and revocation. Refresh tokens are high-value secrets. Treat them as such.
• Least-privilege scopes and roles: The principal used by integrations should only reach the APIs and objects it actually needs. Nothing more.
• Error handling and logging: Logs can leak sensitive payloads—bank details, salary data, invoice lines. Configure masking and redaction, and control who can view run histories.
• Change control: Integration changes create new data paths. Review, test, and approve them like you would any application release.

Review custom objects and permissions, not just Fusion roles

A common mistake we see: Fusion roles are carefully designed, but custom components quietly bypass those assumptions.

Extensions add custom objects, wire them into pages and reports, and nobody explicitly reviews what access that creates. The permissions surface grows without anyone noticing.

Check these specifically:

• Object-level permissions: Who can read, create, update, and delete custom objects and related attachments?
• Row-level filtering: Are integrations and apps enforcing the same data access rules the business expects—by business unit, ledger, or legal entity?
• API exposure: Which endpoints are reachable from outside your network? Are they restricted by network policies, identity policies, and scopes?

The practical fix is governance. Maintain an inventory of every VBCS app, OIC integration, and API consumer. Assign an owner. Schedule periodic reviews of token scopes, object permissions, and logging exposure.

If it isn't tracked and reviewed, it becomes the easiest route to sensitive Fusion data.

And in our experience, that's usually exactly what attackers find first.

Role Design and Segregation of Duties in Oracle Fusion

Oracle Fusion's role-based access control (RBAC) framework is flexible. That flexibility, though, puts SoD design squarely on your plate. Oracle gives you the building blocks and a set of default roles to get you started. But they are not compliance-ready out of the box. If you're aiming for controlled access that holds up under SOX testing, GDPR access governance, or ISO 27001 evidence reviews, you have to design, validate, and actively operate your own role model.

At a practical level, Fusion security is assembled from layers:

• Abstract roles define a user's relationship to the organisation—employee, contingent worker—and drive baseline access patterns.
• Job roles represent what someone actually does: AP specialist, HR specialist. Most teams anchor access requests here, but job roles are often too broad unless you've deliberately curated them.
• Duty roles are the specific capabilities that make up a job—entering invoices, approving invoices, managing suppliers. This is where SoD conflicts are created or resolved. Most of the real work happens here.
• Data security policies control which rows of data a user can reach: business units, ledgers, legal entities, payroll groups, person records. Two users with identical functional privileges can carry very different risk profiles depending on data scope.

Most Fusion SoD issues we see are not caused by a single "bad" role—they come from mixing duty roles across modules without re-checking the data security scope.

Why default roles don't equal compliant roles

Oracle ships predefined roles to support common business processes and speed up implementation. Reasonable starting point. The problem is that "works operationally" and "passes audit" are not the same thing.

Predefined roles often bundle duties that make sense for smaller teams, phased rollouts, or demo environments. But once you map them against your financial controls and approval hierarchy, violations start appearing. We see this constantly during technical audits.

Common places this surfaces:

• Users who can both create and maintain master data (suppliers, customers, bank accounts) and execute transactions (payments, refunds, journal entries).
• Users who can request and approve within the same process chain because roles were assigned for convenience rather than control.
• Users whose data access—business unit, ledger, payroll—is far wider than intended, turning what looks like a local permission into enterprise-wide exposure.

So why does this matter across frameworks? For SOX, auditors test whether key financial processes have preventive or detective controls against inappropriate access. For GDPR, the core question is whether access to personal data is limited, justified, and reviewable—least privilege, purpose limitation, auditability. For ISO 27001, you need evidence that access is authorised, reviewed, and adjusted through a controlled process. Not just configured once at go-live and forgotten.

How to build SoD into the role model (not bolt it on later)

SoD problems are much easier to prevent at the design stage than to untangle after go-live. The tricky part is getting teams to treat it as a design constraint rather than a post-implementation checklist item. A workable approach is to enforce SoD at the duty-role layer from the start, then validate it against real business scenarios—not just module names.

What to document for audit readiness

Fewer surprises during an audit comes down to one thing: evidence that your RBAC design is intentional and actively maintained.

That means keeping:

• A current role catalog—job roles, duty roles, custom roles—with owners and descriptions.
• The SoD rule set you enforce, including which conflicts are tolerated and what compensating controls cover them.
• An approval workflow for role grants and changes, including how emergency access is handled and tracked.
• A schedule and output record for periodic access reviews, with remediation tracking against findings.
• Clear linkage from data security policies to your organisational structure—business units, ledgers, legal entities—including documented ownership of who can change that structure.

Oracle provides the framework and the defaults. The SoD design, and the evidence that it's working, is yours to own.

Treat role engineering and data security as ongoing control activities rather than a one-time configuration task. Do that, and you'll be in a significantly stronger position when compliance questions arrive—planned or otherwise.

Oracle EBS vs Oracle Fusion: Security Model Differences

The biggest shift when moving from Oracle E-Business Suite to Oracle Fusion Cloud isn't technical. It's ownership. Who patches what, who hardens what, and who's accountable when something goes wrong.

That question sits at the heart of oracle fusion security: what oracle patches and what you still own.

Oracle takes on a meaningful chunk of infrastructure and patching responsibility in Fusion. But meaningful isn't the same as complete.

EBS is a build-and-maintain model. You control patch timing, database vulnerability remediation, OS hardening, and network lockdown. That control is genuinely useful—and it's also where teams get into trouble. Patch cycles slip. Environments drift. Dependencies get missed.

Fusion flips this entirely. Oracle standardises the cloud service baseline, which removes certain categories of risk. Infrastructure patch drift, for instance, largely stops being your problem.

But the tenant is still a security system you configure.

And that's where most of the risk lives now. Most incidents we see in Fusion environments don't come from missing infrastructure patches. They come from incomplete access governance, weak authentication settings, approval workflows with gaps, and "temporary" configuration exceptions that quietly become permanent.

So what does that mean in practice? EBS security programmes tend to revolve around patching and hardening projects. Fusion security programmes revolve around configuration assurance. Different work, different rhythms, different team structures.

In EBS, you're planning patch windows, pre-prod cloning, and emergency remediation paths. In Fusion, you're focused on release readiness—particularly role impacts—periodic access reviews, and continuous configuration checks so nothing drifts as the business changes.

We see this constantly during technical audits. Teams that ran tight EBS programmes still get caught out in Fusion because they're applying the wrong playbook.

There's also a collaboration shift worth flagging.

EBS security usually means deep coordination with DBAs and system administrators—they own critical control points. Fusion shifts that effort toward identity and access management teams, process owners, and application administrators. Security outcomes depend on how the tenant is configured and how changes get governed, not on what's happening at the infrastructure layer.

If you're planning a migration, treat it as a security operating model change—not a hosting change. Your EBS playbook needs to evolve. Patch planning and system-level monitoring give way to tenant configuration management, access governance, and release readiness as your core disciplines.

For more detail on each approach, see our EBS security model notes and our Fusion security and compliance coverage.

Know Exactly Where Your Fusion Security Gaps Are

Most Fusion security gaps aren't caused by missing patches. They come from unclear ownership and configuration drift—building quietly in the background until an audit or incident forces the issue.

That's the part most teams don't see coming.

The fastest way to reduce real exposure is knowing exactly what Oracle handles versus what can weaken silently inside your tenant. Those are two very different things, and confusing them is where risk accumulates.

A practical gap review maps your current posture across the areas you still control:

• ✓Identity and access settings
• ✓Role design and approval workflows
• ✓SoD conflict checks
• ✓Data access policies
• ✓Logging and alerting coverage
• ✓Security of extensions and integrations connected to Fusion

The goal isn't a long report. It's a prioritised list—gaps ranked by business risk, with clear owners and specific next actions attached.

We see this constantly during Fusion audits: teams assume a control is covered, but no one has actually verified it in months.

Sometimes years.

AppsolveGroup can run a Fusion security responsibility review or gap assessment so you know what you own, what's working, and what needs tightening—before something forces your hand.

You might also find helpful