Multi-Tenant Platforms Explained for Non-Engineers

When you log in to a cloud platform, you are almost never the only customer on it. The same application, and often the same databases, serve many organizations at once. Each organization is a tenant, and the platform is multi-tenant.

For agencies and resellers, there are usually two layers of tenancy. The platform serves many partners, and each partner serves many clients. Your clients may never think about this, but they are trusting you to make sure their customer lists, messages and reports stay theirs alone.

This guide explains multi-tenancy in plain language, using definitions from the National Institute of Standards and Technology (NIST), and offers questions to ask and a simple way to explain it to clients.

What multi-tenant means

NIST's definition of cloud computing lists resource pooling as one of five essential characteristics. It describes the provider's computing resources as "pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand."

An analogy many people find helpful is an apartment building. Tenants share the foundation, the plumbing and the electrical service, but each unit has its own lock, and residents should never be able to walk into a neighbor's apartment. The building is efficient because it is shared; it is livable because the units are separated.

NIST's guidance on public cloud security (SP 800-144) notes that software providers often go further than sharing hardware: "many SaaS providers rely on an infrastructure free of virtual machines, using instead a single logical instance of an application (i.e., a software technology stack) that can handle extremely large numbers of tenants."

Single-tenant versus multi-tenant

In a single-tenant setup, each customer gets a dedicated copy of the application, and sometimes dedicated infrastructure. In a multi-tenant setup, customers share one running application and are kept apart by software controls.

Neither is automatically better. NIST's cloud synopsis (SP 800-146) frames this as a tradeoff, titling one section "Isolation vs. Efficiency (Security vs. Cost Tradeoffs)." In general terms:

• Multi-tenant platforms tend to be less expensive per customer, and updates reach everyone at once.
• Single-tenant setups can allow more customization and stronger physical separation, usually at a higher cost and with more maintenance.

Shared infrastructure also means shared exposure. SP 800-144 observes that a uniform cloud infrastructure has benefits, but "homogeneity means that a single flaw will be manifested throughout the cloud, potentially impacting all tenants and services." The same is true of outages: when a shared platform has a problem, many tenants can feel it at the same time.

Isolation: what keeps tenants apart

Because tenants share so much, the walls between them are made of software. SP 800-144 explains that "rather than using physical separation of resources as a control, cloud computing places greater dependence on logical separation at multiple layers of the application stack." It also warns that "an attacker could pose as a consumer to exploit vulnerabilities from within the cloud environment, overcome the separation mechanisms, and gain unauthorized access."

SP 800-146 makes a similar point: tenants' workloads may be "separated only by access policies implemented by a provider's software," and "a flaw in the implementation or in the provider's management and operational policies and procedures could compromise the security of consumers."

In plain terms, isolation usually involves several layers working together:

• Identity and access: who can log in, and which accounts each login can reach
• Application logic: every screen, search, report and export limited to the right tenant's records
• Data storage: records tagged by tenant, or stored in separate databases or schemas
• Encryption: data protected in storage and in transit
• Logging: a record of who accessed what, so problems can be detected and investigated

You do not need to evaluate the code yourself, but you can ask your provider how each layer is handled and how it is tested.

Branding and access at the partner level

On a partner platform, your agency account typically sits above your clients' accounts. Your logo, domain and colors are applied across those client accounts, and your staff may be able to switch between them.

That convenience creates its own questions:

• Can you limit each staff member to specific client accounts, rather than all of them?
• Can a client's users ever see anything belonging to another client?
• Are any resources shared across your clients, such as sending domains, phone number pools or integrations, and what happens to the others if one client misuses them?
• Is multi-factor authentication available for every user, at both the agency and client level?

On that last point, CISA's Secure by Design initiative calls for products that are secure out of the box, with features such as "multi-factor authentication (MFA), logging, and single sign-on (SSO) available at no extra cost."

Data separation at the end of the relationship

Separation matters most when a client leaves, asks for their data, or asks you to delete it. SP 800-144 notes that in a SaaS database, data from one consumer may be "commingled" with the data of other consumers, "which can complicate matters" when data must be sanitized.

Ask your provider whether you can export a single client's data in full, without touching other clients, and whether you can delete a single client's data, including from backups, within a defined period. SP 800-144 lists "logical isolation techniques employed in the multi-tenant software architecture of the cloud" and "facilities for backup and recovery of data, and for sanitization of data" among the technology areas organizations should review.

Why it matters to your clients

For example, imagine you serve two plumbing companies that compete in the same town. Both trust you with their customer lists and job history. Neither should ever see the other's data, and neither should be harmed if the other has a security incident. That expectation is a promise you are making on the platform's behalf.

Clients also feel the shared nature of the platform during outages, during feature changes that roll out to everyone, and when they ask for their data back. Understanding multi-tenancy helps you set accurate expectations on all three.

Explaining it to a client in plain language

You might say something like: "Your account runs on a shared, professionally managed platform, much like an apartment in a secure building. Your data is kept in your own separate space, other businesses on the platform cannot see it, and access is limited to the people you approve. If you ever leave, we can export your data and have it deleted."

Only say what you have confirmed with your provider. If you are unsure about any part of that sentence, ask before you repeat it.

Key takeaways

• NIST describes multi-tenancy as pooling resources to serve multiple consumers, with resources assigned and reassigned according to demand.
• In multi-tenant software, the walls between tenants are logical, not physical, so the quality of those controls matters.
• Partner platforms add a second layer: your agency account above your clients' accounts, which raises questions about staff access and shared resources.
• Confirm you can export and delete one client's data without affecting others.
• Describe isolation to clients only in terms your provider has confirmed.

Sources

• National Institute of Standards and Technology, SP 800-145: The NIST Definition of Cloud Computing (September 2011)
• National Institute of Standards and Technology, SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing (December 2011)
• National Institute of Standards and Technology, SP 800-146: Cloud Computing Synopsis and Recommendations (May 2012)
• Cybersecurity and Infrastructure Security Agency, Secure by Design