Multitenancy

Multitenancy is an architectural model in which a single instance of software and a shared pool of infrastructure serve multiple independent customers. These customers are called tenants — usually an organization or a customer account. Each tenant sees its own data and settings as if they were its own, even though it actually shares compute, storage, and databases with others. The separation between tenants is kept by the software itself (the application and data layers), not by a separate deployment for each customer. Most SaaS products and public cloud services are built on this model.

What is a tenant and how does multitenancy work?

A tenant is one logically separate customer of the system — for example a company, a department, or a customer account — together with its users, data, and settings. In a multi-tenant model, many such customers use the same application instance. At the heart of it all is tenant context: an identifier (tenant_id) that travels through the whole system and decides which data a given request may reach. Every database query, every storage read, and every API call has to be limited to the resources of the current tenant.

Multitenancy should not be confused with simply sharing a server. Many applications can run on one machine and still not be multi-tenant. We only talk about multitenancy when a single application instance deliberately and safely serves many customers while keeping their data apart.

How does multitenancy differ from single-tenancy?

In a single-tenant model, each customer gets its own separate copy of the application and its own stack of resources (an instance, a database, sometimes the entire infrastructure). In a multi-tenant model, one instance serves many customers on shared resources, and their data is separated logically.

• Isolation: single-tenancy gives physical, hardware isolation; multitenancy relies mainly on logical isolation kept by software.
• Resource utilization: in multitenancy one stack serves many tenants, so the hardware is used better and the cost per customer is lower. In single-tenancy more resources sit idle.
• Maintenance and updates: in a multi-tenant model one update covers all tenants at once. In single-tenancy each copy has to be updated separately.
• Customization: single-tenancy allows deeper customization (separate versions, your own update schedule). Multitenancy limits changes to configuration within shared code.
• Blast radius: in single-tenancy a failure or breach hits one customer. In multitenancy an isolation flaw or a shared-component outage can hit many tenants at once.

What are the tenant isolation models?

Isolation is not one technique but a whole spectrum — from full sharing to a fully dedicated stack. It is often described with three levels: silo (resources assigned to one tenant), pool (shared resources separated logically), and bridge (a mixed model where some components are shared and others dedicated).

Isolation at the database layer

At the data layer there are three main patterns. They differ in how strong the isolation is, how much they cost, and how much day-to-day work they take:

1. Shared database, shared schema: all tenants use the same tables, with data separated by a tenant_id column and query filtering. The cheapest and simplest variant, but the most exposed to data leakage when someone gets the filter wrong or forgets it — and to the noisy-neighbor effect.
2. Shared database, separate schemas: each tenant has its own schema within a single database. Separation is better than with shared tables, but every schema change has to be applied separately to each tenant, and backups become more complex.
3. Database per tenant: each tenant gets its own database. This gives the strongest isolation and the easiest way to meet rules about where data is stored, but it costs the most and is the hardest to operate (you have to manage hundreds or even thousands of databases).

Isolation at the compute and network layer

When tenant code actually runs, tenants are kept apart through approaches such as a namespace per tenant in Kubernetes, dedicated VPCs or subnets, network policies, RBAC, and mutual service authentication (mTLS) in a service mesh. In mixed models, ordinary customers share infrastructure, while customers with stricter requirements (compliance, enterprise contracts) get a stack of their own.

How does isolation work, and why isn’t authentication enough?

Tenant isolation is something different from authentication and authorization. The fact that a user is logged in and holds the right role does not mean they cannot reach another tenant’s data — ordinary login and permissions have no concept of a „tenant boundary” at all. Isolation is an extra layer that, based on tenant context, limits resource access for all users of a given tenant. In practice this is done through:

• passing tenant_id from the token (e.g. a field in a JWT) across the entire request path;
• mandatory scoping of queries to the current tenant — ideally with row-level security in the database, not just a WHERE filter in application code;
• access policies (IAM, RBAC) and network rules that bind resources to tenants;
• separate encryption keys or secrets per tenant where the threat model calls for it.

What security risks does multitenancy introduce?

Sharing resources piles up risk: a single isolation flaw can affect many tenants. The main threats are:

• Cross-tenant leakage: one tenant’s data becomes reachable by another — through a missing tenant_id filter, an authorization bug, a context-mapping mistake, or an IDOR-type vulnerability.
• Escalation and isolation escape: attempts to cross the tenant boundary by swapping identifiers, flaws in a shared layer (cache, queues, a shared database), or misconfigured namespaces or VPCs.
• Noisy neighbor: one tenant uses a disproportionate share of shared resources (CPU, I/O operations, database connections) and degrades performance or availability for others. This is eased with resource limits, quotas, and rate limiting.
• Shared blast radius: an outage or breach of a shared component (database, node, cluster) can affect many tenants at once.
• Compliance and where data is stored: regimes such as PCI DSS, HIPAA, or data-localization rules may force stronger isolation (a separate schema, a separate database, or a dedicated stack) for specific tenants.

Why does multitenancy matter for monitoring and threat detection?

In a multi-tenant environment, visibility and telemetry have to know which tenant they belong to. For SOC teams, network monitoring, and NDR-class systems this creates several concrete challenges:

• Per-tenant attribution: logs, metrics, network flows (e.g. NetFlow/IPFIX), and security events should carry tenant context. That way an incident can be attributed to the right customer and analyzed apart from the rest.
• Lateral-movement detection: communication crossing a tenant boundary where it shouldn’t (or unusual access to a shared database) is a signal of possible cross-tenant leakage or an isolation breach.
• Noisy-neighbor detection: sudden spikes in one tenant’s use of shared resources may mean abuse, misconfiguration, or an attack (e.g. a DoS against a shared component).
• Separation of visibility: reports and dashboards must make sure one tenant cannot see another’s telemetry — isolation applies to the monitoring layer too, not only to production data.
• Configuration hygiene: constant review of network policies, RBAC rules, and namespace/VPC boundaries lowers the chance that a misconfiguration opens a path between tenants.

Learn more

• SaaS / IaaS / PaaS — Multitenancy is common in SaaS, and can also appear in IaaS and PaaS designs.
• Cloud Security Posture Management (CSPM) — CSPM helps identify misconfigurations that can expose shared multitenant cloud resources.
• On-premise / Cloud / Hybrid — Multitenancy is usually associated with cloud deployments, not traditional on-premise environments.
• Microsegmentation — Microsegmentation limits lateral movement and helps isolate tenants in shared environments.
• Cloud Access Security Broker (CASB) — CASB enforces access and data controls across multitenant cloud services.
• Secure Access Service Edge (SASE) — SASE secures access to multitenant cloud applications from distributed users and sites.