A tenant – called an organization throughout Versa’s interfaces – is an isolated organizational unit within Versa’s multitenant architecture: a customer, business unit, or enterprise with its own administrators, users, policies, routing instances, and services, running on platform infrastructure shared with other tenants.
Key takeaways
- A tenant is an isolated organization on shared Versa infrastructure.
- Isolation spans admins, policies, routing, logs, and licensing.
- Provider organizations administer customer tenants beneath them.
- One VersaONE system supports up to 256 tenants.
- Tenancy is the mechanism behind MSP services and enterprise segmentation.
On this page: Why it mattersHow it worksTypesTenants & VersaFAQ
Why are tenants important?
Multitenancy is what lets one platform serve many masters safely. A service provider can run hundreds of customers on shared gateways and headend systems, each customer seeing only its own network, policies, and data; a global enterprise can give business units or subsidiaries the same separation without buying separate infrastructure per unit. The economics of managed SD-WAN and SASE services depend on it.
Tenancy is also a security boundary. Each tenant’s traffic rides its own routing instances, its logs are scoped to it, its administrators cannot see or affect neighbors, and per-tenant limits keep one organization’s load from starving another. Getting this boundary right at the platform layer – rather than bolting isolation on with ad-hoc VLANs and firewall rules – is what makes shared infrastructure defensible to auditors and customers alike.
What is a tenant?
In Versa’s model, a tenant is the scoping unit almost everything else hangs from. Appliances serve one or more tenants; configuration templates, security policies, and traffic policies belong to a tenant; users and role-based administrators are defined within one; Analytics dashboards, reports, and logs are filtered by it. On a shared VOS device, each tenant gets its own virtual routing instances and services, so overlapping IP space between tenants is normal and safe.
Tenants are arranged hierarchically. A provider organization sits at the top, owns the infrastructure, and creates customer organizations beneath it – the multitenancy configuration guide covers the mechanics of building the hierarchy.
Types of tenants
Three roles recur in the hierarchy. The provider organization owns the platform: headend nodes, gateways, and licensing, plus the right to create and administer tenants. Customer organizations (tenant organizations) are the isolated units created beneath a provider – an MSP’s customer, or an enterprise’s business unit – each with its own admins and policy space. Where a deployment needs further subdivision, sub-tenants nest a hierarchy inside a customer, useful for franchises, subsidiaries, or departmental separation. In SASE deployments the same model applies to cloud gateways: shared gateways host many tenants, while dedicated tenant deployments reserve capacity for one.
Tenants & Versa
Tenancy runs through every layer of VersaONE: up to 256 tenants per system, per-tenant service enablement (which security and networking services each tenant may use), per-tenant organization limits on sessions and throughput, and tenant-scoped visibility across Analytics and logging. Providers activate multitenant gateway devices to host many customers on shared hardware, and Concerto’s SASE workflows create a full tenant – identity, gateways, client configuration, and policy – as one operation.
Frequently asked questions
Are “tenant” and “organization” the same thing in Versa?
Yes. The interfaces and documentation use organization for the configured object; tenant emphasizes its role in the multitenant architecture. A tenant organization is one isolated unit; the provider organization administers the hierarchy above it.
Can tenants share a single physical appliance?
Yes. A multitenant VOS device hosts several tenants at once, each with isolated routing instances, services, and policies. Overlapping IP addressing between tenants is supported because each tenant’s traffic stays inside its own virtual routing context.
How is one tenant kept from seeing another’s data?
Isolation is enforced at every layer: separate routing instances for traffic, tenant-scoped administrator roles for configuration, tenant-filtered logs and dashboards for visibility, and per-tenant limits for resources. A tenant administrator’s view simply contains nothing outside the tenant.
How many tenants does the platform support?
The VersaONE architecture supports up to 256 tenants per system. Practical designs size tenant count per gateway and per headend against throughput, session, and service-mix requirements rather than the ceiling alone.
What does a provider organization control that a tenant cannot?
The provider owns shared infrastructure: gateway and headend lifecycle, licensing, tenant creation, and cross-tenant capacity decisions. Tenant administrators manage what is theirs – users, policies, sites, services – but never the shared platform or neighboring tenants.
More on multitenancy
If you want to learn more, these are sources we trust.
| NIST SP 800-145: Cloud definition | Cloud Security Alliance research |
|---|---|
| The canonical definition of cloud service models, where resource pooling across tenants is a defining characteristic. | Vendor-neutral guidance on securing shared, multitenant cloud infrastructure. |
Related terms
If you’re reading about tenants, these are worth looking at next.
| Organization | Provider Organization | Multitenancy |
|---|---|---|
| The configured object that represents a tenant in Director, Concerto, and VOS. | The top of the tenancy hierarchy: owns infrastructure and creates customer organizations. | The architectural property that lets isolated tenants share one platform safely. |