Notifications
Clear all
Topic starter
17/05/2026 9:44 am
TL;DR: Omada Identity Cloud Private lets regulated enterprises run the full Omada Identity Cloud platform inside their own Microsoft Azure tenant, preserving tenant ownership while keeping the same release cadence as SaaS, according to Omada Identity. The move sharpens the governance question for IAM teams: deployment model now matters as much as feature set when auditors, regulators, and risk teams are involved.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
A: Choose the model that best matches your audit, residency, and operational control requirements.
Q: What is the difference between tenant ownership and data residency in identity governance?
A: Tenant ownership describes who controls the environment, while data residency describes where the data is stored and processed.
Q: When does private cloud deployment reduce risk in IAM programmes?
A: Private cloud deployment reduces risk when the main concern is shared tenancy, regulatory evidence, or strict boundary control.
Practitioner guidance
- Define tenant ownership in the control model Document who administers the Azure tenant, who approves changes, and who can evidence control ownership for auditors.
- Map residency requirements to deployment decisions Tie data residency, region selection, and tenant placement to the specific regulatory obligations driving the deployment.
- Review identity workflows for control drift Test whether entitlement reviews, approvals, logging, and access recertification still meet policy when the release cadence matches SaaS but the tenant is customer operated.
That is where the identity risk picture becomes operational instead of theoretical?
👉 Read Omada Identity's announcement of Omada Identity Cloud Private →
Explore further
17/05/2026 9:44 am
Tenant control is becoming a first-class governance requirement for identity platforms. The article reflects a broader market reality: regulated buyers are no longer evaluating identity tools only by features or delivery model. They are asking whether the operating environment itself supports auditability, residency, and clear administrative boundaries. For NHI programmes, that is the right question because identity controls fail most often at the seams between application, tenant, and infrastructure ownership. The practitioner conclusion is straightforward: deployment topology belongs in the control design, not the procurement footnote.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
A question worth separating out:
Q: How should security teams evaluate cloud identity tools in regulated environments?
A: Evaluate whether the tool can be operated inside the organisation’s control perimeter, whether release cadence can coexist with change management, and whether audit evidence is easy to produce. The key test is whether the operating model supports compliance without forcing manual workarounds or weakening visibility.
👉 Read our full editorial: Omada Identity Cloud Private reframes regulated IGA deployment
