If you run a security program across more than one organization, you eventually hit the same question. Should each client, business unit, or subsidiary get its own separate install, or can a single platform serve all of them at once without their data ever mixing? That question is the whole point of multi-tenancy.
Multi-tenancy is an architecture pattern, not a feature you toggle on. It shapes how a platform stores data, who can see what, and how isolation holds up when something goes wrong. This guide explains what multi-tenancy means, what a tenant actually is, how multi-tenant differs from single-tenant, and how isolation is enforced in practice. The goal is a clear mental model you can carry into any vendor conversation or architecture review.
What Is Multi-Tenancy?
Multi-tenancy is a software architecture where a single running instance of an application serves many independent customer groups at the same time. Each customer group is called a tenant. The tenants share the same code, the same infrastructure, and often the same database, yet each one sees only its own data and behaves as if it had the platform to itself.
The contrast is single-tenancy, where every customer gets a dedicated instance of the application with its own resources. Multi-tenancy trades that hard physical separation for logical separation enforced in software. One deployment, many tenants, strict boundaries between them.
The cloud computing literature treats multi-tenancy as a core property of shared services. NIST’s definition of cloud computing (SP 800-145) describes resource pooling that serves multiple consumers from the same physical and virtual resources, with isolation handled by the platform rather than the hardware. Multi-tenancy is the design that makes resource pooling safe.
For a security platform the stakes are higher than for a typical SaaS app. The data is sensitive by nature. Vulnerability findings, asset inventories, scan results, and remediation history are exactly the information an attacker would want. A multi-tenant security platform has to prove that one tenant can never read, change, or even infer another tenant’s data. Isolation is not a nice-to-have here. It is the product.
What Counts as a “Tenant”
A tenant is the unit of isolation. It is the boundary that the platform draws around one customer’s data and one customer’s users. Everything inside the boundary belongs together, and nothing crosses it without an explicit, audited reason.
In practice a tenant maps to an organization. For a managed security service provider that organization is a client. For a large enterprise it might be a business unit, a region, or a legal entity. For a holding company it is each subsidiary. The label changes, the concept does not. A tenant is a self-contained scope of data and access.
Under the hood a tenant needs a stable identifier that the platform can attach to every record. This identifier is usually called the tenant key. Every asset, every finding, every scan, and every report carries the tenant key of the tenant it belongs to. When the platform reads data, it filters on the tenant key so that a query can only ever return rows for tenants the caller is allowed to see.
PMAP follows this model directly. Each tenant is represented as a row in the companies table, and that company row is the multi-tenancy root of the platform. The company_id is the tenant key. Asset, project, scan, finding, campaign, team, report, and analytics records all reference company_id as their tenant key, so the company row becomes the effective tenant boundary across the entire system. There is no second concept of “tenant” floating around. The company is the tenant.
This single-key discipline matters. When one column is the tenant boundary everywhere, isolation becomes a property you can enforce in one place and reason about consistently. When tenancy is smeared across several inconsistent fields, gaps appear, and gaps in a security platform are exactly where data leaks.
Multi-Tenant vs Single-Tenant
The clearest way to understand multi-tenancy is to compare it with the alternative.
In a single-tenant deployment each customer gets a dedicated copy of the application. Separate database, separate compute, often separate networks. Isolation is physical. Two tenants cannot see each other’s data because they are not running in the same place. The cost is duplication. Every upgrade, every patch, every configuration change has to be applied to each instance. Running fifty single-tenant deployments means operating fifty platforms.
In a multi-tenant deployment all customers share one running instance. Isolation is logical. The platform stores everyone’s data together and uses the tenant key to keep queries inside the right boundary. Upgrades happen once. Patches happen once. A new feature ships to every tenant at the same time. The operational efficiency is the main reason multi-tenancy exists.
The trade is real. Single-tenancy gives you the strongest possible isolation at the highest operating cost. Multi-tenancy gives you efficient operation and consistent behavior, but it places the entire weight of isolation on the software. If the tenant filter has a bug, tenants can see each other. That is why a serious multi-tenant platform builds isolation as a default-deny system rather than something it remembers to apply.
There is also a middle ground worth naming. Some platforms are multi-tenant at the application layer but give each tenant a logically separate schema or database. That preserves a single codebase while adding a layer of storage separation. Whether you need it depends on your risk tolerance and your compliance obligations. The point is that “multi-tenant” is a spectrum of isolation strength, not a single fixed design.
How Tenant Isolation Is Enforced
Isolation in a multi-tenant platform comes down to one question asked on every single read. Which tenants is this caller allowed to see, and does this query stay inside that set?
The common pattern is a scope filter. When a user authenticates, the platform resolves the set of tenants that user belongs to and turns it into a filter that gets applied to every database query. The user never selects which tenant key to filter on. The platform derives it from who they are and attaches it automatically. A user cannot widen their own scope because the scope comes from their identity, not from their request.
PMAP implements this with a structure called the ScopeFilter. The authorization layer reads the company memberships from the authenticated user’s context and builds the filter, exposing the allowed set as AllowedCompanyIDs. Every domain’s repository then applies that filter as a SQL predicate of the form WHERE company_id = ANY(allowed_company_ids). Because the predicate is attached at the data-access layer rather than left to each individual query, the tenant boundary is enforced uniformly. A list of assets, a search for findings, a report query, all pass through the same gate.
Platform administrators are the deliberate exception. The ScopeFilter carries an Unrestricted flag, and when it is true the filter allows all companies. This is how a platform operator manages every tenant from one console without being a member of each one. The flag is explicit and auditable, which is the right way to handle a privileged cross-tenant view. The OWASP Access Control Cheat Sheet makes the same point in general terms. Enforce access decisions server-side, deny by default, and never trust the client to scope its own request.
The Default-Deny Safety Net
The most important property of a well-built scope filter is what happens when it is empty. A safe design fails closed, not open.
Consider a ScopeFilter where Unrestricted is false and AllowedCompanyIDs is empty. There are two ways a platform could interpret this. One is “no filter to apply, so return everything,” which would be a catastrophic data leak. The other is “this caller is allowed to see nothing, so return nothing.” A secure multi-tenant platform must choose the second.
PMAP treats an Unrestricted = false filter with an empty AllowedCompanyIDs as default-deny. Repositories return nothing. An empty allowed set is not an absent filter, it is an explicit instruction that the caller has no tenant access. This single rule turns a class of dangerous edge cases into harmless empty responses. If membership resolution fails, if a user belongs to no company yet, if something upstream returns an empty set, the result is an empty list rather than the entire database. Fail-closed isolation is the safety net that makes the rest of the model trustworthy.
Tenant Hierarchy: Holding and Subsidiaries
Real organizations are rarely flat. A holding company owns several subsidiaries. An enterprise has divisions under divisions. A multi-tenant platform that ignores this structure forces everything into one level and loses the relationships that matter for reporting and access.
A tenant hierarchy models parent-child relationships between tenants. The standard way to express it is a self-referencing pointer. Each tenant record can carry a parent reference. A tenant with no parent is a root, and a tenant with a parent is a child of that root. The same table holds both, and the parent pointer encodes the tree.
PMAP uses exactly this shape. A company carries an optional parent_id that points to its holding company. A company with parent_id = NULL is treated as a holding company, the root tenant. A company with a non-null parent_id is a subsidiary. To read the children of a holding company, the platform exposes GetSubsidiaries, which lists the direct children under a parent. The service layer guards the obvious mistake, blocking any update that would make a company its own parent, so the hierarchy stays a valid tree rather than a cycle.
This structure does practical work. A holding-level view can roll up findings and assets across all subsidiaries, while a subsidiary administrator stays scoped to their own organization. The hierarchy expresses ownership without collapsing isolation. A parent can be granted visibility into its children, but a subsidiary does not automatically gain visibility into its siblings or its parent. Hierarchy and isolation are separate concerns, and a good model keeps them separate.
Why MSSPs and Holdings Need Multi-Tenancy
The two organization types that lean hardest on multi-tenancy are managed security service providers and holding groups. Both manage security for many distinct organizations, and both need one operational view without ever merging the underlying data.
A managed security service provider runs vulnerability programs for dozens or hundreds of clients. Spinning up a separate single-tenant deployment for each client is slow, expensive, and a maintenance burden that scales linearly with the client count. Multi-tenancy lets the provider onboard a new client as a new tenant in an existing platform, manage all clients from one console, and still guarantee that each client’s findings, assets, and reports stay walled off from every other client. The provider gets operational leverage. The client gets isolation. Both requirements are satisfied by the same architecture.
Holding groups have a related but distinct need. A parent company wants a consolidated risk picture across its subsidiaries while each subsidiary runs its own security program with its own administrators. Multi-tenancy with a hierarchy gives them both. Each subsidiary is its own tenant with its own scoped users. The holding sits above them as a parent tenant that can roll up the consolidated view. One platform serves the whole group, and the boundaries between subsidiaries remain firm.
In both cases the value is the same. Many isolated organizations, one platform to operate, no data bleeding across boundaries. That is multi-tenancy doing the job it was designed for.
Multi-Tenancy and Access Control Work Together
Multi-tenancy and access control are often confused because they both decide what a user can see. They answer different questions, and a complete platform needs both.
Multi-tenancy answers “which tenants does this user belong to.” It draws the outer boundary. The scope filter ensures a user’s queries can only touch data inside their allowed tenants. It is a horizontal partition across the whole dataset.
Access control answers “within a tenant, what can this user do.” Role-based access control assigns permissions to roles and roles to users, so that inside a tenant one person can read findings while another can also approve risk acceptances or manage assets. It is a vertical partition by capability.
The two compose. The tenant scope decides which company’s data is in play, and the role decides what the user may do with it. A user might be a member of three tenants with read-only access in two and full administrative rights in the third. Tenant scope and role permissions stack to produce the effective access for any given action. Neither replaces the other. If you want the full treatment of how permissions are assigned within a tenant, see our explainer on what RBAC is and how role-based access control works. For the broader picture of running a vulnerability program across many tenants, the pillar on multi-tenant vulnerability management ties tenancy, scope, and remediation together. If you want to go deeper on how a parent-and-subsidiary tree resolves ownership of a given finding, the piece on tenant hierarchy and owner resolution walks through that logic, and the comparison of MSSP multi-tenant versus single-tenant weighs the two deployment models head to head.
Frequently Asked Questions
What is multi-tenancy in simple terms?
Multi-tenancy is when one running copy of an application serves many separate customers at the same time, with each customer seeing only its own data. The customers share the same code and infrastructure, but the platform keeps their data isolated using software rather than separate installations. It is the architecture that lets a single security platform manage many organizations at once.
What is a tenant?
A tenant is the unit of isolation in a multi-tenant platform. It is the boundary drawn around one customer’s data and users, usually mapping to one organization, client, business unit, or subsidiary. Every record carries a tenant key that ties it to its tenant, and the platform filters on that key so callers only ever see their own tenant’s data. In PMAP the tenant is a company row and the tenant key is company_id.
What is the difference between multi-tenant and single-tenant?
Single-tenant gives each customer a dedicated copy of the application with separate infrastructure, so isolation is physical and operating cost is high. Multi-tenant runs one shared instance for all customers and enforces isolation logically through a tenant filter, so operation is efficient but the software carries the full weight of keeping tenants apart. Single-tenant favors maximum separation, multi-tenant favors efficient, consistent operation.
How is tenant data kept isolated?
Isolation is enforced by a scope filter applied to every database read. When a user authenticates, the platform derives the set of tenants they belong to and attaches it to each query as a filter, so a query can only return rows for allowed tenants. A safe design also fails closed, meaning that if the allowed set is empty the platform returns nothing rather than everything. In PMAP this is the ScopeFilter with its AllowedCompanyIDs, applied as a SQL predicate and defaulting to deny when the set is empty.
Can a tenant ever see another tenant’s data?
Not through normal access. A user’s tenant scope comes from their identity, not from their request, so they cannot widen it to reach another tenant. The only intentional cross-tenant view is a platform administrator operating with an unrestricted scope flag, which is explicit and auditable. A correctly built multi-tenant platform treats any unexpected scope as no access rather than full access.
Why do MSSPs need multi-tenancy?
Managed security service providers run programs for many clients, and standing up a separate platform per client does not scale. Multi-tenancy lets a provider onboard each client as a tenant in one shared platform, manage every client from a single console, and still guarantee that each client’s data stays walled off from the others. It delivers operational leverage for the provider and isolation for the client at the same time.
How does a tenant hierarchy work?
A tenant hierarchy models parent-child relationships using a self-referencing pointer. A tenant with no parent is a root, and a tenant with a parent is a child of that root. This lets a holding company sit above its subsidiaries and roll up a consolidated view while each subsidiary stays scoped to its own program. In PMAP a company carries an optional parent_id, a null value marks a holding company, and GetSubsidiaries lists the direct children under a parent.
