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

At a glance

What this is: Omada Identity Cloud Private is a private-deployment option for its identity governance platform that keeps the application in a customer-selected Azure tenant while preserving the SaaS release rhythm.

Why it matters: For IAM and NHI teams, it matters because regulated environments often need cloud operating models without relaxing tenant ownership, audit boundaries, or data residency expectations.

👉 Read Omada Identity's overview of Cloud Private identity governance

Context

Cloud-private identity governance is a deployment model that keeps the service in the customer’s own cloud tenant instead of a shared vendor tenant. The governance gap it addresses is familiar to regulated enterprises: they want cloud cadence, but they also need clearer tenancy boundaries, data residency control, and auditor-friendly operating evidence. In NHI terms, that matters because service accounts, tokens, and automation workflows often inherit the same residency and separation requirements as human identity records.

Omada Identity Cloud Private is relevant because it reframes the question from whether identity governance can run in cloud to where the control plane and data actually live. For NHI programs, the operational issue is not only feature delivery. It is whether lifecycle controls, access reviews, and policy enforcement can occur inside a tenant boundary that satisfies DORA, NIS2, or comparable regulatory expectations without forcing teams back to fully on-premises delivery.

Key questions

Q: How should regulated teams evaluate cloud-private identity governance platforms?

A: Start with tenancy, evidence, and operational ownership. A cloud-private model only helps if the customer controls the environment boundary, can prove where identity data lives, and understands who handles logs, keys, updates, and incident response. If those responsibilities are unclear, the deployment shifts risk rather than reducing it.

Q: Why does tenant ownership matter for NHI governance?

A: Tenant ownership matters because NHI records, secrets, and lifecycle evidence often need the same audit boundaries as human identity data. When those assets sit in a shared tenant, it becomes harder to prove separation, residency, and control. A customer-owned tenant gives governance teams a clearer enforcement point.

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.

Q: When does a cloud identity platform create more governance risk than it reduces?

A: Risk rises when the platform is cloud-hosted but the team cannot explain tenancy, data residency, release drift, or operational ownership. In that case, the tool may improve workflow efficiency while weakening auditability. Governance fails when cloud convenience hides control ambiguity.

How it works in practice

How private tenant deployment changes identity governance architecture

A private tenant model keeps the application logically separate inside a customer-controlled Azure environment while the vendor continues to ship application updates and support. That differs from shared SaaS because the customer or its partner owns the cloud environment, which changes who controls networking, logging, data placement, and operational boundaries. For IGA and NHI workloads, this can preserve compliance evidence while still using cloud delivery patterns. The important architectural point is that tenancy, not just encryption, becomes part of the control design.

Practical implication: Treat tenant ownership as an architectural control and verify who controls logs, keys, retention, and environment administration.

Why release parity matters for regulated NHI and IGA programmes

Release parity means the private deployment receives the same application versioning and update cadence as the vendor’s SaaS offering. That matters because private cloud models often fail when they drift behind the hosted service, creating control gaps, compatibility issues, and delayed security fixes. For identity governance, version drift can also break workflows around provisioning, certification, or connector maintenance. When the release stream stays aligned, the trade-off shifts from feature lag to operational responsibility inside the customer tenant.

Practical implication: Confirm that the private deployment stays on a supported release path and that patching responsibilities are contractually clear.

Tenant boundaries as a control for audit, residency, and NHI data handling

In regulated identity programs, the tenant boundary is often the unit auditors care about because it maps to where identity records, access decisions, and evidence are stored. A private deployment can reduce ambiguity around co-mingled data and improve separation between customers, but only if the environment is configured accordingly. That does not remove governance work. It shifts it into cloud configuration, operational oversight, and continuous verification of where NHI data and automation artifacts reside.

Practical implication: Map each NHI data flow to its tenant, storage, and logging destination before you sign off on residency claims.

NHI Mgmt Group analysis

Private cloud tenancy is becoming a governance requirement, not a packaging preference. Regulated buyers are increasingly evaluating identity platforms on whether cloud delivery preserves tenant ownership, auditability, and data locality. That is especially true when identity governance now includes non-human identities, which can carry the same evidentiary and residency expectations as human identities. The market signal is clear: procurement is shifting from feature comparison to control-plane placement, and practitioners should demand that distinction up front.

Identity governance for NHI has outgrown the shared-SaaS default. Service accounts, API keys, certificates, and agent credentials are often embedded in workflows that regulators expect to be traceable and revocable. A shared vendor tenant can be operationally efficient, but it can also complicate evidence collection and boundary assurance for high-regulation environments. Practitioners should treat deployment topology as part of NHI governance design, not as an afterthought.

Release parity in a private tenant reduces one class of drift while exposing another. If the private environment stays on the same release train as SaaS, teams avoid the usual stale-version problem. But the customer inherits more responsibility for cloud operations, identity data placement, and environment hardening. That means the governance burden does not disappear, it moves inward. The practical conclusion is to evaluate who owns operational failure, not just who owns software delivery.

Cloud-private IGA is a signal that the market is converging on controlled autonomy. Regulators and critical infrastructure buyers want modern automation, but only inside a clearly bounded operating model. That same demand is likely to shape adjacent NHI and agentic AI controls, where execution authority and identity evidence must stay inside defensible boundaries. Practitioners should expect future tooling to compete on containment and governance proofs as much as on workflow features.

For NHI programs, the real question is whether the control plane can move without weakening the control model. This announcement suggests buyers are no longer willing to accept a binary choice between cloud convenience and governance rigidity. The stronger pattern is managed cloud locality with explicit tenant control, and that will increasingly be the benchmark for regulated identity and NHI tooling.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For deeper context on lifecycle control, see Ultimate Guide to NHIs and Top 10 NHI Issues.

What this signals

Cloud-private identity governance will push more teams to treat tenancy as a security control. That matters because the deployment model now influences where evidence lives, who can administer the environment, and how cleanly NHI records can be separated from shared service estates. Regulated programs should align this choice with NIST Cybersecurity Framework 2.0 governance and protection functions, then validate the evidence trail before rollout.

Tenant-bound IGA will also sharpen the control expectations around secrets and lifecycle operations. If identity data moves into a customer-owned Azure tenant, then offboarding, rotation, and access review discipline need to follow it. The operational risk is not just misconfiguration, but delay, because the control environment can look compliant while stale credentials remain active. That is where Top 10 NHI Issues becomes a useful checklist for programme design.

For practitioners

• Validate tenant ownership and boundary controls Confirm who administers the Azure environment, who controls logging and retention, and where identity data and workflow artifacts are stored. Document those responsibilities before using the deployment for regulated NHI or IGA workloads.
• Map regulatory requirements to deployment topology Translate DORA, NIS2, FINMA, or similar obligations into concrete requirements for residency, audit evidence, and operational separation. Use the tenant model to prove compliance, not to assume it.
• Test release parity and change management Check whether the private deployment follows the same release cadence as the SaaS service and how emergency fixes are applied. Make sure connector updates, approval workflows, and policy changes do not drift between environments.
• Review NHI evidence handling inside the tenant Identify where service account records, API key inventories, certificate data, and access review evidence are stored. Tie each of those objects to the Azure tenant boundary and your retention policy.

Key takeaways

• Cloud-private identity governance is a response to a real regulatory problem, not a packaging preference.
• The key control question is whether the customer owns the tenant boundary, the evidence trail, and the operational responsibilities.
• For NHI programmes, private deployment only helps if lifecycle controls, secrets handling, and audit proof all remain enforceable inside the tenant.

Key terms

• Cloud-private identity governance: A deployment model that runs identity governance software inside a customer-owned cloud tenant rather than a shared vendor tenant. It preserves cloud operating patterns while giving security and audit teams a clearer boundary for data residency, environment administration, and evidence collection.
• 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.
• Release parity: A condition where a private deployment receives the same functional release cadence as the vendor’s SaaS service. It reduces version drift and helps regulated teams avoid falling behind on security fixes, but it also requires clear operational ownership inside the customer environment.
• Identity evidence trail: The records that show how identities were created, granted access, reviewed, rotated, and removed. For NHI governance, this includes service accounts, tokens, certificates, and related audit logs that prove controls were enforced over time.

Deepen your knowledge

Cloud-private identity governance and NHI lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building regulated identity controls in a customer-owned tenant, it is worth exploring.

This post draws on content published by Omada Identity: Omada Identity Cloud Private for regulated environments. Read the original.