Tenant isolation
By SealSec · July 30, 2026
Tenant isolation is the set of controls that keeps one customer's data and actions inside a multi-tenant SaaS application from reaching another customer. Every tenant shares the same codebase and often the same infrastructure, so the walls between them exist in code, configuration and policy rather than in physically separate systems.
Why it matters
For a SaaS business, a tenant isolation failure is close to the worst possible incident: customer A sees customer B's data. AWS calls tenant isolation "fundamental to the design and development of SaaS systems" in its SaaS Tenant Isolation Strategies whitepaper, and describes a crossed tenant boundary as "a significant and potentially un-recoverable event for a SaaS business." Enterprise buyers know this, which is why isolation questions appear in almost every security questionnaire.
Silo vs. pool
The AWS whitepaper groups isolation strategies into two broad models:
Silo: each tenant gets its own dedicated resources, sometimes a full separate stack. The walls are strong because they are structural, but cost and operational overhead grow with every tenant.
Pool: tenants share resources, and isolation is enforced by the application: tenant IDs on every query, scoped tokens, row-level security, per-tenant encryption keys. This is the model most SaaS products use, because it is efficient.
Most real systems mix the two: a pooled application tier with siloed storage for larger customers, for example.
How it is tested
Pooled isolation lives in application logic, so it fails the way application logic fails: a missing tenant check on one endpoint, an object ID that is accepted without verifying ownership, a background job that runs across tenants. Automated scanners rarely find these. A penetration test of a SaaS application therefore spends much of its time logged in as one tenant while trying to read or change another tenant's data, across the web app, the API and any export or reporting features.