Omada Identity Cloud Private reframes regulated IGA deployment

At a glance

What this is: Omada Identity Cloud Private is a new deployment option that keeps the full IGA platform inside a customer-owned Azure tenant while preserving cloud update cadence.

Why it matters: It matters because regulated IAM and IGA teams now have to weigh tenant boundary, data residency, and audit expectations alongside functional coverage and operating model.

Context

Regulated IGA programmes often have to choose between cloud delivery and tenant control. In practice, that choice affects where identity data lives, who operates the environment, and how clearly auditors can see the boundary of responsibility.

Omada Identity Cloud Private is positioned as a way to keep the application in the customer’s own Microsoft Azure tenant and selected region while preserving the vendor’s release cadence. That places deployment architecture inside the governance discussion, especially for teams that must satisfy residency and control expectations without giving up cloud operating patterns.

Key questions

Q: How should regulated teams evaluate cloud IGA when tenant control matters?

A: They should assess whether the deployment model preserves residency, operator accountability, and audit evidence, not just feature coverage. A platform that runs inside a customer-owned tenant may better fit regulated environments if the team can clearly document who operates the environment, who manages releases, and how controls are evidenced.

Q: Why does tenant ownership matter for identity governance platforms?

A: Tenant ownership matters because auditors and regulators often care about where identity data resides and who can operate the environment. When the tenant boundary is customer-controlled, governance teams can align the platform more closely with their existing cloud control model, but they still need explicit operating responsibilities and evidence paths.

Q: What control gaps can appear in customer-operated cloud IGA?

A: The main gap is ambiguity between application ownership and environment ownership. If the vendor supplies software while the customer or partner runs the Azure tenant, teams can lose clarity on patching, change control, support, and evidence collection unless those responsibilities are documented and tested.

Q: What should teams document before moving IGA into a regulated cloud tenant?

A: Teams should document the tenant boundary, regional data location, release ownership, support responsibilities, and the evidence required for audits. That record helps prove that cloud delivery still meets the organisation’s governance model and does not weaken regulatory accountability.

How it works in practice

Tenant-owned cloud IGA deployment model

A tenant-owned cloud model moves the application into a customer-controlled Azure tenant instead of a shared vendor tenancy. The software remains cloud delivered, but the customer or partner operates the hosting environment, which changes who owns the infrastructure boundary, where data resides, and how much environmental control the customer retains. For IGA, that distinction matters because the control plane for identity governance is no longer separated from the tenant boundary the enterprise already uses for cloud oversight.

Practical implication: map IGA hosting responsibility to the same tenant governance model used for other regulated workloads.

Release cadence without shared tenancy

Running the same application on the same release cadence as SaaS while keeping tenant separation creates a hybrid operating model. The vendor still ships application software, release packages, deployment guidance, and support, but the customer retains the Azure environment itself. That means patching, configuration, and service ownership are split across different parties, so change control and accountability need to be explicit rather than assumed from a standard SaaS operating model.

Practical implication: define which release, change, and support tasks sit with the vendor and which remain with the tenant operator.

Why regulated IGA is a deployment question

For regulated enterprises, identity governance is not only about features such as access reviews, lifecycle controls, or risk scoring. It is also about whether the operating model can satisfy data residency, tenant boundary, and auditability expectations without introducing unnecessary friction. When auditors or regulators care about where identity data sits and who controls the environment, deployment architecture becomes part of the control design rather than a technical afterthought.

Practical implication: evaluate IGA platforms against residency, boundary, and operator-control requirements before comparing feature lists.

NHI Mgmt Group analysis

Deployment model has become an identity governance control surface: The boundary between SaaS and customer-operated cloud tenancy now carries governance weight, not just infrastructure meaning. When regulated teams must prove where identity data resides and who can operate the environment, the hosting model becomes part of the assurance story. Practitioners should treat tenancy choice as a control decision that shapes auditability and accountability.

Tenant ownership can reduce one governance trade-off while creating another: Keeping IGA inside a customer Azure tenant may satisfy residency and boundary expectations, but it also splits operational responsibility across application vendor and tenant operator. That arrangement can simplify regulator conversations while complicating change management, support demarcation, and evidence collection. The practical question is whether the operating model is documented well enough to survive scrutiny, not whether cloud or on-premises sounds cleaner.

Regulated identity programmes are moving toward controlled cloud, not generic cloud adoption: The article reflects a market shift where cloud delivery remains desirable, but only if the deployment model preserves the control boundaries regulators expect. That aligns with broader governance pressure in sectors such as financial services and government, where auditability and residency requirements shape platform selection. Practitioners should expect deployment architecture to be evaluated alongside entitlement management and lifecycle coverage.

Full governance, no shared tenancy is the emerging procurement lens: The useful distinction is not cloud versus non-cloud, but shared tenancy versus tenant-owned control. That concept captures why regulated buyers are asking for deployment options that preserve SaaS cadence without surrendering boundary control. Practitioners should assess whether a platform’s operating model supports the assurance narrative they will need to defend under DORA, NIS2, or similar scrutiny.

Deployment flexibility does not remove the need for lifecycle discipline: A different tenancy model does not change the underlying need to govern joiner-mover-leaver events, recertification, and privileged access. The deployment choice only changes where those controls are operated and how evidence is produced. Practitioners should avoid treating infrastructure placement as a substitute for identity lifecycle governance.

What this signals

Cloud IGA is converging on controlled tenancy: Regulated buyers are no longer asking only whether identity governance is cloud delivered. They are asking whether cloud delivery preserves the tenant boundary, evidence chain, and regional control they need for audit and risk management.

This shifts IGA evaluation from a feature-led conversation to an operating-model conversation. Teams should expect procurement, architecture review, and compliance sign-off to focus more heavily on residency, support demarcation, and who can prove the control environment to auditors.

For practitioners

• Define the tenancy control boundary Document which party operates the Azure environment, which party owns the IGA application layer, and how evidence is produced for audits and risk reviews.
• Map residency requirements to deployment choices Validate whether the selected Azure region and tenant ownership model satisfy the organisation’s regulatory data residency and operational oversight obligations.
• Separate release management from environment management Write down who handles application releases, deployment guidance, support, patching, and tenant-level configuration so accountability does not blur in operations.
• Re-test governance controls in the chosen operating model Reconfirm that access reviews, lifecycle controls, and privileged administration still generate the evidence regulators expect when the platform runs in customer-controlled cloud tenancy.
• Align procurement criteria with control evidence Ask vendors to show how their deployment model preserves tenant visibility, operator accountability, and audit-ready evidence without shifting the burden onto the compliance team.

Key takeaways

• The core issue is not cloud versus on-premises, but whether the IGA deployment model preserves the control boundary regulated teams must defend.
• Omada Identity Cloud Private keeps the application in a customer-owned Azure tenant while maintaining SaaS release cadence, which changes how responsibility and evidence are split.
• Practitioners should test tenancy ownership, residency, and operating responsibility together before treating deployment choice as a secondary architecture detail.

Key terms

• Customer-Managed Tenant: A customer-managed tenant is a cloud environment operated within the buyer’s own administrative boundary rather than a shared vendor tenancy. For regulated identity governance, it gives the organisation stronger control over residency, administration, and evidence generation while still relying on cloud-delivered application software.
• Deployment Model: The deployment model is the operating location and ownership structure of a platform, such as SaaS, on-prem, air-gapped, or hybrid. It determines where data is processed, who administers the environment, and how much control the customer retains over access, logging, and recovery.
• Tenant boundary: The administrative and technical separation that defines where customer data, logs, and controls live in a cloud environment. In identity governance, it matters because auditors and security teams often need to prove that access decisions and identity records are isolated from other tenants.
• Operating Model: An operating model is the practical way a governance programme is run, including decision ownership, workflow design, integrations, and control boundaries. For identity security, the operating model determines whether policy intent survives real execution across human, NHI, and AI-assisted processes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.