Case study · Enterprise identity
Zuora OneID: built for change
How an identity layer keeps enterprise customers operating through acquisitions, splits and expansion, and gets new products live in days.
- Role
- Product leader; created OneID
- Company
- Zuora
- Domain
- Enterprise IAM, multi-organization identity
- Status
- In production for 2+ years
- 80K+
- monthly active users
- 10+
- products and services authorized across the Zuora suite
- $6–10M
- annual licensing avoided
Estimate, list-price basis
The bet
OneID is the identity and access layer for the Zuora product suite. I made the case internally that it is a strategic product asset rather than infrastructure spend, on two grounds.
First
Customers reorganize constantly, and OneID absorbs it
Enterprises acquire, get acquired, split and carve out business units continuously. Each event is a moment when a subscription platform either absorbs the change quietly or becomes the reason it is painful, and painful reorganizations invite competitive re-evaluation.
Second
New products and acquisitions onboard in days, not quarters
OneID was built with a pluggable authentication layer from its first release. When an acquired product arrives with a non-standard stack, the platform extends to meet it instead of the product being retrofitted.
Both properties come from one architectural decision, made before OneID went live: model organizations, environments and services as first-class, re-parentable entities, and make the authentication handoff extensible. Commercial platforms model tenants for steady-state operation and support a fixed set of protocols, so neither property can be purchased.
The problem: customers do not hold still
Enterprise customers acquire and are acquired, split into multiple entities, consolidate subsidiaries and expand into new regions and legal structures. It is a continuous condition of serving large enterprises, not an edge case. After each event, a customer's tenants, users, roles, permissions and audit history must end up under the correct new boundary, and billing cannot stop while it happens. Handled badly, it becomes a re-implementation project, which is when an incumbent vendor gets re-evaluated.
Representative events, de-identified
Three-way corporate separation
Tenants and user populations re-parented across three independently operating companies.
Two-way separation
A single customer structure divided into two organizations, with users, roles and audit history following to the correct entity.
Consolidation of two entities
Two previously separate organizations merged into one without interrupting billing operations.
Why this is a product and retention argument
Revenue protection
A customer being acquired is the highest-risk churn moment in an enterprise relationship, because the acquirer consolidates vendors. Absorbing the reorganization cleanly is how the account survives the event.
Deal enablement
"What happens to our instance when we divest a business unit?" is a real procurement question in enterprise cycles. Most vendors have no credible answer.
Zero-disruption expectation
The customer experiences a corporate restructuring without a migration project attached to it, which is precisely when goodwill is won or lost.
Four decisions that make onboarding take days
New products onboard without re-architecture
The minimum integration is four steps: register an application type, register the target service, choose a redirect strategy, and configure authentication. Roles, permissions, user synchronization, audit events and event streaming are optional and deferrable, so a product team ships authentication in its first sprint and adds governance when the roadmap allows.
The platform adapts to the product, not the reverse
OneID shipped with five authentication handoff methods at general availability, two of them proprietary, supporting session propagation and nested in-product experiences. When none fit, a new handoff method is a new component plus a registration entry. Extensibility was designed in from the first release, not retrofitted after an integration proved difficult.
Product teams keep their own permission models
OneID synchronizes with each product's native role and permission model rather than imposing a single central schema. Teams are not asked to re-model their authorization design to satisfy the identity layer.
No vendor in the launch path
Adding a product to OneID is a configuration and deployment change on our own release cadence. There is no procurement cycle, connector request queue or per-application licensing negotiation between a product being ready and being launchable.
Build versus buy
The financial case is favorable: an estimated $6M to $10M in annual external licensing avoided at our scale, based on list-price analysis. But cost is not the reason to keep OneID. Retention and roadmap control are. What buying would cost is measured less in dollars than in launch speed and customer risk.
| Capability | OneID | Typical commercial platform |
|---|---|---|
| Onboard an acquisition with a non-standard auth stack | Extend the platform | Retrofit the product, or build a bespoke bridge |
| Re-parent a customer's tenants after a split or merger | Supported operation | Migration project with a services engagement |
| Product keeps its own role model | Yes | Central mapping required |
| Marginal cost of the next product | Engineering hours | Licence expansion or per-connection fees |
Migrating would also consume six to twelve months of platform roadmap capacity, permanently give up the proprietary handoff methods that several products depend on, and turn customer reorganizations from a supported operation back into a migration project.
Seven years of compounding investment
OneID was not a single project. Each era built on the last, and the capabilities that differentiate the platform today were established early and extended deliberately.
Customer structure
- 2022Multi-organization support at general availability
- 2024Multi-organization provisioning
- 2025Extended multi-organization support
Enterprise readiness
- 2023MFA and key management
- 2024Authenticator apps, Entra ID provisioning, Global Audit Trail GA
Agent and AI identity
- 2025Authorization for remote MCP servers
- 2026Unified authorization system and MCP enhancements
Now: authorization for AI agents
Remote MCP server authorization is live in production, supporting statically registered clients and Client ID Metadata Documents (CIMD). OneID is becoming the authorization layer the AI roadmap depends on, built on the same foundation: a model that treats change as a first-class case.
Working on identity or authorization?
I'm always glad to compare notes on multi-organization identity, platform strategy and agent authorization.
Get in touch