Implementing a SaaS application across multiple subsidiaries — each with its own HRIS and IdP — is one of the more complex identity architecture problems practitioners encounter. The goal is to let each subsidiary's employees authenticate with their existing IdP (Okta, Entra ID, or others) while maintaining centralized visibility, provisioning, and governance across the entire population. Getting this wrong typically results in either forcing a single authentication standard on subsidiaries that have already invested in their own stack, or ending up with fragmented user management that defeats the purpose of a centralized platform.

The Core Architecture Decision: Central Hub vs. Federation

The fundamental choice is whether the central SaaS platform accepts multiple IdPs directly (true multi-SAML), or whether a central identity governance layer sits above all subsidiary IdPs and presents a unified identity to the platform.

True multi-SAML means the SaaS application has a separate SAML configuration for each subsidiary IdP. Each subsidiary has its own sign-on URL and X.509 certificate. Users from Subsidiary A are routed to the Okta tenant for that subsidiary; users from Subsidiary B are routed to their Entra ID. The SaaS platform accepts authentication assertions from all configured IdPs.

The practical requirements: every subsidiary domain needs to be verified within the central platform to ensure proper routing. The platform needs logic to map inbound SAML assertions to the correct user profile regardless of which IdP issued them. JIT (Just-in-Time) provisioning — creating user records on first SSO authentication — may work for basic access but typically doesn't carry enough contextual data (department, role, subsidiary) from the SAML assertion to drive sophisticated provisioning logic. JIT handles the front door; it doesn't handle birthright access based on role and department.

Central IGA/orchestration layer means an identity governance platform sits above all subsidiary IdPs, normalizes their identity data, and presents a unified provisioning interface to the SaaS application. Each subsidiary still authenticates through their own IdP; the governance layer handles the attribute resolution, conflict detection, and provisioning logic centrally.

For a large multi-subsidiary deployment where lifecycle automation, access reviews, and compliance reporting matter, the orchestration layer approach scales significantly better than managing per-subsidiary configurations within the SaaS platform itself.

Resolving Identity Conflicts Across Multiple Sources

When the same person (or a person who has transferred between subsidiaries) exists in multiple HRIS and IdP systems, you need explicit logic for which source wins.

Precedence-based attribute resolution. Define a priority hierarchy for each attribute. If a user exists in both Subsidiary A's HRIS (P1) and a legacy IdP (P2), P1 data takes precedence for attributes like department and employment status. For attributes that should come from the local system — IdP-specific group memberships, local system roles — the local source may take precedence for those specific fields.

The implementation: configure which system is authoritative for each attribute rather than applying a single source for the entire user profile. Department from the HRIS, security group memberships from the local IdP, employment status from the HRIS, application roles from the IGA layer.

Static unique identifiers for transfers. Email addresses change when someone transfers between subsidiaries (their domain changes). If email is your only user identifier, a transferred user looks like a new user — creating a duplicate record and losing the access history. A static global employee ID (assigned at the enterprise level, not the subsidiary level) survives domain changes, subsidiary transfers, and name changes. Using global employee ID as the primary identity key is the architecture that makes transfers clean.

Conflict detection for duplicate accounts. When a user's email appears in multiple subsidiary systems, the governance layer should flag it for review rather than auto-merging — since not all duplicates are the same person. The alias matching logic (checking alternative email fields, not just primary email) catches cases where a person's profile was created slightly differently in different systems.

Provisioning Logic Across Different HRIS Sources

Each subsidiary having its own HRIS means provisioning triggers come from different systems with potentially different data formats, field names, and status conventions.

Birthright access by subsidiary, department, and role. The provisioning logic needs to be aware of subsidiary context — a Finance Analyst at Subsidiary A may need different default access than a Finance Analyst at Subsidiary B if the two subsidiaries use different tools or have different compliance requirements. Automation rules that evaluate subsidiary + department + role together allow you to define birthright access with the appropriate granularity.

Handling the mover scenario across subsidiaries. An internal transfer between subsidiaries is an identity event that needs to be handled explicitly rather than falling through as either a new user (if the new subsidiary creates a new account) or a profile update (if the attribute change is detected but not acted on). The mover workflow should simultaneously deprovision access specific to the previous subsidiary context and provision access appropriate for the new subsidiary context. Without this, transferred employees accumulate access from both subsidiaries.

Status mapping across different HRIS conventions. Different HRIS systems use different conventions for employment status — "Active," "LOA," "Terminated," "FT," "PT," and custom status values vary significantly. The transformation layer between HRIS source data and the IGA platform needs to normalize these into a consistent status taxonomy (Active, Suspended, Inactive) that the provisioning and deprovisioning logic can act on correctly.

Maintaining Governance Across Subsidiaries

The compliance and audit requirement is what typically drives the centralization effort in multi-subsidiary environments: when auditors ask for evidence that access was reviewed and that departed employees had access revoked, you need a centralized record rather than subsidiary-specific spreadsheets.

Centralized access reviews across all subsidiary populations. A single certification campaign should be able to include users from all subsidiaries, with appropriate reviewer routing — subsidiary-level managers review their own populations, a central compliance team reviews cross-subsidiary access. The campaign output is a single compliance record rather than separate reports per subsidiary.

Automated revocation triggered from any subsidiary HRIS. When any subsidiary HRIS records a termination, the offboarding workflow should trigger across all systems the user has access to — not just the applications provisioned through that subsidiary's own IdP. A contractor who had access provisioned through Subsidiary A's Okta and also had access provisioned through a central provisioning workflow needs both revoked, triggered by the termination event in Subsidiary A's HRIS.

Discovery for subsidiaries not yet integrated. In large multi-subsidiary deployments, some subsidiaries will be at different stages of integration. Browser and desktop agents deployed at the endpoint level surface application usage in systems where the subsidiary hasn't yet enforced SSO, providing governance visibility before the formal integration is complete.

Implementation Sequencing

For a multi-subsidiary deployment of this complexity, sequencing matters:

Start with the subsidiaries that have the cleanest data and the most straightforward IdP setups. Demonstrate that the architecture works end-to-end — SSO authentication through the subsidiary IdP, provisioning triggered from the HRIS, access reviews including that population, offboarding triggered by HRIS termination — before expanding to more complex subsidiary configurations.

The attribute mapping and precedence configuration for each subsidiary should be tested with actual data before go-live. The conflict detection logic for cross-subsidiary user records needs to be validated against real data that includes the edge cases (transfers, name changes, multi-role employees).

Budget the same two-month minimum for first-cycle access review readiness that applies to any IGA deployment. In a multi-subsidiary context, the data validation effort is multiplied by the number of subsidiary HRIS sources.

Frequently Asked Questions

How do you configure a SaaS application to accept multiple IdPs from different subsidiaries?

The standard approach is separate SAML configurations per subsidiary IdP, with verified subsidiary domains for routing logic. Each subsidiary IdP provides its own sign-on URL and X.509 certificate. JIT provisioning can create basic user records on first SSO login, but granular provisioning based on role and department typically requires a separate provisioning layer that pulls attribute data from the subsidiary HRIS rather than relying solely on SAML assertion data.

How do you handle identity conflicts when the same person exists in multiple subsidiary HRIS systems?

Define a precedence hierarchy that specifies which source is authoritative for each attribute, and use a static global employee ID as the primary identity key rather than email address. Email addresses change during subsidiary transfers; a global employee ID persists. The identity governance layer should flag potential duplicate records for review rather than auto-merging, since not all cross-subsidiary appearances of the same email represent the same person.

What is the "mover" problem in multi-subsidiary identity management?

When an employee transfers between subsidiaries, their old subsidiary may de-activate their account and the new subsidiary may create a new one. Without explicit mover workflow handling, the transfer either creates a duplicate account or loses access history — and the access associated with the previous subsidiary may remain active. A mover workflow that detects the cross-subsidiary transfer, deprovisions the old subsidiary access, and provisions the new subsidiary access prevents both privilege creep and orphaned access from transfers.

How do you maintain compliance evidence for access reviews across multiple subsidiaries?

A centralized access review campaign that includes users across all subsidiary populations produces a single compliance record rather than subsidiary-specific spreadsheets. The review campaign routes certification tasks to the appropriate subsidiary managers and a central compliance team, captures all decisions with timestamps, and generates a non-editable audit report covering the full multi-subsidiary population. This is the access review evidence format that SOC 2 and ISO 27001 auditors expect.