Security Architecture

Securing Oracle Fusion Supplier Access with MFA

How PCL Addressed External Identity Risk Using Domain-Isolated IAM Architecture

As Oracle Fusion Cloud adoption increases, organisations are extending platform access beyond employees to suppliers, contractors, and partners.

Executive Summary

As Oracle Fusion Cloud adoption increases, organisations are extending platform access beyond employees to suppliers, contractors, and partners. While Fusion provides robust security capabilities, securing external supplier access—without weakening internal identity controls or degrading user experience—remains a recurring challenge.

PCL encountered this problem during an Oracle Fusion implementation where suppliers accessed sensitive procurement and invoicing functionality. Standard MFA approaches proved insufficient, either over-coupling suppliers with internal identity policies or leaving security gaps through unsupported access paths.

This document outlines how PCL designed and implemented a domain-segregated MFA architecture using OCI IAM to secure supplier access to Oracle Fusion—balancing security, governance, scalability, and usability.

The Problem: Supplier Access Is Not the Same as Employee Access

In most Oracle Fusion programs, identity and security design focuses heavily on employees. Supplier access is often treated as an extension of the same model. This assumption creates multiple risks:

  • Identity mixing: External suppliers share identity boundaries with internal users
  • Policy coupling: Changes intended for employees unintentionally affect suppliers
  • Inconsistent MFA enforcement: MFA applied at role or user level is difficult to govern
  • Multiple login paths: Suppliers bypass intended access routes, weakening controls
  • Audit complexity: External access cannot be cleanly demonstrated or isolated

In this case, the client required:

  • Mandatory MFA for all suppliers
  • Clear segregation between internal and external identities
  • No impact on employee authentication flows
  • A scalable model suitable for a growing supplier base

A naïve “turn on MFA everywhere” approach failed to meet these requirements.

Why Common Approaches Fall Short

PCL reviewed typical patterns seen in Oracle Fusion environments:

1. Global MFA with Exceptions

Applying MFA globally and carving out exceptions introduces:

  • Fragile rule logic
  • High operational overhead
  • Increased risk during future changes

2. Role-Based MFA Inside Fusion

Relying on application-level controls:

  • Couples security to role design
  • Creates inconsistent enforcement
  • Limits central visibility and governance

3. Shared Identity Domain for All Users

Placing suppliers and employees in the same identity domain:

  • Violates segregation principles
  • Makes audit and compliance harder
  • Forces compromise between security and usability

None of these approaches scale cleanly.

PCL’s Design Principle

External users must be isolated at the identity boundary, not just controlled downstream.

This led to a design where supplier authentication is segregated, enforced centrally, and accessed through a single controlled path.

Solution Overview: Domain-Isolated Supplier MFA

PCL implemented a dedicated OCI IAM domain exclusively for supplier users, integrated with Oracle Fusion using SAML SSO.

High-Level Architecture

  • Suppliers exist only in a Supplier IAM Domain
  • Oracle Fusion is configured as a SAML Service Provider
  • MFA is enforced via IAM sign-on policies
  • Fusion authorization remains role-based
  • All supplier access is IdP-initiated only

This ensures suppliers never authenticate through internal identity infrastructure.

Authentication Flow

  • Supplier accesses the Supplier Portal
  • Oracle Fusion redirects authentication to the Supplier IAM Domain
  • Supplier authenticates using credentials + MFA
  • IAM issues a SAML assertion to Fusion
  • Fusion authorizes access based on assigned supplier roles

There is no alternative login path.

Key Design Decisions Made by PCL

1. Dedicated Supplier IAM Domain

Separating suppliers at the domain level provides:

  • Complete isolation from internal users
  • Independent security policies
  • Clean audit boundaries

This avoids identity sprawl and future rework.

2. Centralised MFA Enforcement

MFA is enforced via IAM domain sign-on policies rather than Fusion roles.

Benefits:

  • Uniform enforcement
  • Simplified governance
  • No dependency on application configuration

Security posture is controlled centrally, not scattered across roles.

3. Enforced Authorization Controls

The Fusion integrated application is configured to allow access only to explicitly granted users, preventing accidental exposure through implicit access.

4. Controlled Login Entry Points

Generic Fusion login pages are explicitly avoided for suppliers.

Suppliers must authenticate via:

  • IAM-managed IdP-initiated access
  • Supplier-specific identity domain

This closes a common loophole where MFA can be bypassed unintentionally.

5. Usability Without Security Dilution

To avoid excessive MFA friction:

  • Trusted devices are enabled
  • Limits are applied on device count and trust duration
  • MFA remains mandatory for new or expired sessions

This strikes a balance between security and supplier experience.

Operational Outcomes

The implemented solution delivered:

  • Strong security posture for external users
  • Clear separation of internal and supplier identities
  • Predictable access behaviour for suppliers
  • Simplified audit and compliance evidence
  • Scalability without redesign as supplier numbers grow

Most importantly, the solution remains fully aligned with supported Oracle capabilities—no custom code, no unsupported extensions.

Key Considerations for Similar Implementations

Based on PCL’s experience, organisations should plan for:

  • Supplier IAM domain sizing and limits
  • Email readiness for MFA delivery
  • Monitoring of IAM–Fusion synchronisation jobs
  • Decommissioning unsupported Fusion login paths post go-live

These are operational factors that must be addressed early to avoid access disruptions.

Conclusion

Securing supplier access in Oracle Fusion Cloud is not a configuration exercise—it is an identity architecture decision.

By isolating suppliers into a dedicated IAM domain and enforcing MFA at the identity layer, PCL delivered a solution that is secure, scalable, auditable, and user-friendly.

This pattern allows organisations to extend Fusion access confidently to external users without compromising internal security or operational control.

Secure Supplier Access With Confidence

We help Oracle Fusion programmes implement scalable, auditable identity controls for external users without compromising internal security and user experience.

Published February 14, 2026