Cloud-private IGA changes the governance trade-off for regulated identity

At a glance

What this is: Omada Identity Cloud Private is a cloud-private IGA deployment model that keeps the platform in a customer-owned Azure tenant while preserving the SaaS release rhythm.

Why it matters: It matters because regulated IAM and IGA teams must balance auditability, data residency, and operating model control against the delivery pace of cloud services.

Context

Cloud-private IGA is a deployment pattern where the application remains cloud-delivered but the customer controls the tenant boundary and hosting environment. For regulated identity programmes, that boundary often matters as much as the feature set because audit expectations, residency requirements, and third-party risk review all attach to where identity data lives.

Omada Identity frames Cloud Private as a way to remove the trade-off between cloud-native IGA and tenant ownership. The practical question for practitioners is not whether cloud delivery is useful, but whether the operating model preserves enough control to satisfy regulators, auditors, and internal risk teams without falling back to fully self-managed software.

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 should identity teams check before moving regulated workloads to cloud-private IGA?

A: They should check data residency, administrative ownership, logging retention, and whether the deployment model still supports access review and change evidence. The key question is whether the cloud model preserves control clarity or simply relocates operational responsibility.

Q: What is the difference between private IGA deployment and on-premises identity governance?

A: Private IGA in a customer cloud tenant keeps cloud operating patterns while preserving a controlled boundary, whereas on-premises deployment places the full stack inside customer-managed infrastructure. The practical difference is speed and operations versus maximum local control. Regulated teams should choose based on evidence requirements, not terminology.

How it works in practice

Tenant-owned cloud deployment for IGA

Cloud-private IGA shifts the hosting boundary without changing the application delivery model. The customer owns the Microsoft Azure tenant, while the vendor provides the software, release packages, deployment guidance, and support. That matters because control over tenant configuration, data placement, and administrative scope remains with the customer, even though the application is still consumed as a cloud service. For regulated environments, the governance question is whether the tenant boundary is defensible enough to satisfy evidence requests without forcing a return to on-premises operations.

Practical implication: verify whether your tenant, not the vendor, remains the authoritative control boundary for data residency, access administration, and audit evidence.

SaaS cadence with customer-controlled residency

The technical distinction here is between delivery cadence and control plane ownership. Omada Identity says the same application is delivered in the customer-selected Azure environment on the same release rhythm as the SaaS service. That means teams can keep pace with functional updates while changing where identity data is processed and stored. The key governance issue is that release velocity and residency are no longer tightly coupled, which changes how risk, change management, and validation are handled in regulated identity programmes.

Practical implication: separate release governance from residency governance so that faster updates do not weaken your control over environment selection.

Regulated identity data and audit boundaries

Identity data in regulated environments is not just operational data. It is evidence-bearing data that supports access reviews, compliance reporting, and supervisory scrutiny. A customer-owned Azure tenant can make the audit boundary easier to explain because the organisation can point to a clearly bounded environment rather than a multi-tenant shared service. That does not remove governance burden, but it does change where accountability sits and how traceability is demonstrated across the identity lifecycle.

Practical implication: map audit evidence, logging, and data residency obligations to the specific tenant boundary before adopting the cloud-private model.

NHI Mgmt Group analysis

Cloud-private IGA is really a governance architecture choice, not a product feature. The important change is that regulated teams can keep cloud delivery while preserving a tenant boundary they can explain to auditors and supervisors. That matters because many identity programmes fail not on technical capability but on evidenceability, residency, and ownership ambiguity. The practitioner conclusion is simple: deployment model is now a governance decision, not just an infrastructure decision.

Tenant ownership changes the accountability model for identity data. When the customer owns the Azure tenant, the organisation retains more control over configuration, data location, and access administration than it would in a shared multi-tenant model. That makes the environment easier to align to DORA, NIS2, and similar obligations where control clarity matters. The implication is that IAM and IGA teams should treat tenancy as part of control design, not an afterthought.

Cloud velocity no longer has to be purchased with shared-tenant compromise. The article’s core market signal is that regulated buyers are no longer forced into a binary choice between SaaS pace and deployment ownership. That shifts the decision criterion for IGA programmes from feature parity alone to control boundary, supervisory evidence, and operating model fit. The practitioner conclusion is to re-evaluate whether the current deployment model still matches the organisation’s regulatory posture.

Cloud-private IGA will widen the gap between governance claims and governance proof. A tenant-owned deployment can strengthen the story, but only if the organisation can actually demonstrate who controls the environment, where the data resides, and how changes are managed. The lesson for identity leaders is that cloud-private architecture reduces one class of objection while increasing the need for explicit evidence mapping. The practitioner conclusion is to validate proof points before you buy the narrative.

Regulated identity programmes should stop treating residency and delivery as the same problem. The article separates where the platform runs from how quickly it ships. That is the right mental model for modern identity governance, because regulatory scrutiny usually lands on environment ownership and data handling, not on whether delivery is cloud-based. The practitioner conclusion is to design procurement and control reviews around the actual governance question being answered.

What this signals

Tenant ownership is becoming a procurement control, not a deployment preference. For regulated identity programmes, the question is increasingly whether the operating model preserves a reviewable control boundary across data residency, administrative scope, and audit evidence. Cloud-private models will appeal when the organisation needs cloud delivery but cannot accept a shared-tenant accountability story.

Cloud-private IGA narrows one governance objection while leaving the burden of proof intact. The architecture may satisfy residency expectations, but teams still need to show who controls the environment, how evidence is retained, and where responsibility sits for change and access administration. That means procurement, security architecture, and audit readiness have to move together.

For practitioners

• Define the tenant boundary as a control boundary Document who owns the Azure tenant, who administers it, and which controls remain under customer authority before any deployment decision is made.
• Map residency requirements to the deployment model Trace DORA, NIS2, FINMA, and internal residency obligations to the specific environment where identity data will be processed and stored.
• Separate release governance from hosting governance Review change management so that SaaS cadence does not blur decisions about where the platform runs or which tenant controls apply.
• Validate audit evidence paths before adoption Confirm that logging, access review evidence, and administrative records remain accessible in the customer-owned tenant for assurance and supervision.

Key takeaways

• Cloud-private IGA changes the deployment debate by separating cloud delivery from shared-tenant ownership concerns.
• For regulated programmes, the main value is clearer residency, evidence, and accountability boundaries rather than new identity functionality.
• Identity teams should validate tenant control, auditability, and residency mapping before treating cloud-private as a governance solution.

Key terms

• Cloud-private IGA: A cloud deployment model where the identity governance platform runs in a customer-owned cloud tenant rather than a shared vendor tenant. It preserves cloud delivery while shifting control over environment ownership, data residency, and administrative scope back to the customer.
• 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.
• Data residency: The requirement that data remain in a specific jurisdiction or region for storage, processing, or both. In regulated identity programmes, residency is part of the assurance model because it influences legal exposure, audit scope, and the set of controls needed to prove compliance.
• Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.