Omada Identity Cloud Private
Omada Identity Cloud Private delivers the full Omada Identity Cloud platform inside your own Azure tenant, in the region you select. You get the same continuous innovation, release cadence, and cloud-native performance as our SaaS offering – with the added benefit of full tenant ownership and data boundaries that can be defended during audits that regulators, auditors, and internal risk teams require.
Omada Identity Cloud Private is based on Omada Identity Cloud, delivered into your own Azure tenant and operated by your organization or your implementation partner, with the same cloud innovation cadence as SaaS. Omada provides the application software, release packages, deployment artifacts, and product support. You own the infrastructure, security posture, and operational execution.
Omada Identity Cloud Private delivers the same functionality as Omada Identity Cloud. If features are not yet available or behave differently in this deployment model, this is noted on the relevant documentation pages.
Deployment model
Omada Identity Cloud Private is one of three deployment models available for Omada Identity, alongside Omada Identity Cloud (SaaS) and Omada Identity (on-premises). It is the recommended choice for organizations that require data residency control or full tenant ownership while retaining the same cloud innovation cadence as SaaS.
Deployment options
Within Omada Identity Cloud Private, two deployment options are available for provisioning the infrastructure:
- Installation script mode (recommended): Fully guided orchestration of Terraform and Ansible with preflight validation, toolchain installation, and phase checkpointing. Best for first-time deployments and standard configurations.
- Raw Infrastructure as Code (IaC) mode (advanced): Direct access to Terraform and Ansible scripts for users who require deep customization or integration with existing infrastructure.
Both options consume the same standardized release package and Azure infrastructure components. For detailed information, prerequisites, and step-by-step guides, see Deployment guide.
Operational responsibilities
In the Cloud Private model, operational responsibilities are shared between Omada, partners, and customers.
Azure platform layer
The table below outlines the shared responsibility model for the Azure platform layer.
| Area | Customer | Partner (optional) | Omada |
|---|---|---|---|
| Azure Tenant Governance Customer owns tenant, subscription, region selection. | ✓ | ✓ | |
| Network Configuration (VNet, NSG, Private Endpoints, Routing) All boundaries reside in customer tenant. | ✓ | ✓ | |
| Identity & RBAC (Azure / Entra ID) Managed identities, service principals, role assignments. | ✓ | ✓ | |
| Monitoring & Logging (Azure resources) Log Analytics, alerts, retention policies. | ✓ | ✓ | |
| Capacity & Scaling (AKS, SQL, Messaging) Scaling decisions and cost impact owned by customer. | ✓ | ✓ | |
| Backup & Disaster Recovery (Azure resources) Backup strategy, geo-redundancy decisions. | ✓ | ✓ | |
| Security Management (Platform) Includes OS patching, VM security, encryption at rest, Azure policies. | ✓ | ✓ | |
| Cryptographic Key & Secret Management (Key Vault) Keys and secrets stored and governed in customer tenant. | ✓ | ✓ | |
| Cost & Quota Management Budgeting, subscription quotas, optimization decisions. | ✓ | ✓ |
Omada application layer
The table below outlines the shared responsibility model for the Omada application layer. This includes the core product code, features, and application-level support.
| Area | Customer | Partner (optional) | Omada |
|---|---|---|---|
| Application Code Core product code and features. | ✓ | ||
| Product Security Fixes Security updates at application layer. | ✓ | ||
| Release Packaging Version-controlled release packages. | ✓ | ||
| Reference Architecture & Deployment Artifacts Terraform/Ansible scripts, automation framework. | ✓ | ||
| Product Roadmap & Innovation Same innovation cadence as SaaS. | ✓ | ||
| End user help desk | ✓ | ||
| Product-level support (Tier 2/3) Omada provides product support within contractual scope. | ✓ (Tier 1 optional) | ✓ | |
| Customer-Specific Configuration & Adjustments Customer manages tenant-specific configurations within product guidelines. | ✓ | ✓ |
Operational execution layer
The table below outlines the shared responsibility model for operational execution, including deployment, updates, monitoring, and support processes.
| Area | Customer | Partner (optional) | Omada |
|---|---|---|---|
| Deployment Execution Executed in customer tenant via IaC. | ✓ | ✓ | |
| Update Scheduling & Change Governance Customer aligns with internal CAB processes. | ✓ | ✓ | |
| Update Execution Using Omada release package. | ✓ | ✓ | |
| Release Validation & Promotion (Dev → QA → Prod) Customer’s internal governance. | ✓ | ✓ | |
| Environment Lifecycle Management Development, QA, and production environments. | ✓ | ✓ | |
| Operational Monitoring of Application Availability, responsiveness, performance. | ✓ | ✓ | |
| Support Escalation Customer initiates, Omada provides product support. | ✓ | ✓ | ✓ |
| Tenant Access Control No standing Omada access. Access must be initiated by the customer and can be revoked by the customer. | ✓ | ✓ |
For a technical overview of the infrastructure and what you need to prepare, see Infrastructure architecture and Prerequisites. For deployment instructions, see the Deployment guide.