Notifications
Clear all
Topic starter
18/08/2026 2:16 pm
TL;DR: Multi-tenancy concentrates scale and risk in the same shared application layer: one Tenant ID, one authorization failure, and one cross-customer breach. According to Ory, identity and access management is the enforcement layer that keeps pooled SaaS safe, while OWASP ranks broken access control as the number one web application risk.
NHIMG editorial — based on content published by Ory: What Is Multi-Tenancy in SaaS Applications
Questions worth separating out
Q: How should security teams enforce tenant boundaries in multi-tenant SaaS?
A: They should require tenant context to travel with every authentication event, API call, and database query, then deny any request that cannot be tied to a known tenant.
Q: What breaks when authorization is not tenant-aware?
A: Global authorization models break when the same user needs different permissions in different customer contexts.
Q: When should organisations choose silo isolation over pooled multi-tenancy?
A: Choose silo isolation when compliance, residency, or customer assurance requires stronger separation than software-only boundaries can credibly provide.
Practitioner guidance
- Make tenant context mandatory in every access decision Require Tenant ID propagation through authentication, API middleware, database queries, and admin workflows so no request can execute without a tenant-scoped identity check.
- Test for missing tenant filters before release Add negative tests that attempt cross-tenant reads, writes, and admin actions across shared schemas and pooled databases, then block release if any path escapes its tenant boundary.
- Align delegated admin with tenant lifecycle controls Scope SCIM provisioning, role assignment, and offboarding to the customer tenant so identity changes cannot bleed across organizations or persist after account changes.
What's in the full article
Ory's full article covers the implementation detail this post intentionally leaves for the source:
- Tenant-by-tenant auth patterns for SSO, OIDC, SAML, and passkeys across B2B SaaS
- Schema-level and database-level isolation trade-offs for shared, hybrid, and dedicated deployments
- Delegated administration and SCIM lifecycle examples for customer-managed user provisioning
- Practical mapping of tenant-aware authorization to Ory Kratos and Ory Keto
👉 Read Ory's guide to multi-tenancy and tenant-scoped identity controls →
Multi-tenancy and tenant boundaries: are your identity controls enough?
Explore further
18/08/2026 3:07 pm
Tenant-scoped identity is the real control plane in multi-tenant SaaS. Shared infrastructure only works when every identity, session, and request is bound to the correct tenant before authorization runs. That makes identity not a supporting control but the mechanism that prevents cross-customer exposure. The practitioner conclusion is simple: multi-tenancy succeeds or fails in the identity layer, not the database alone.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
A question worth separating out:
Q: Who is accountable when a tenant boundary failure exposes customer data?
A: Accountability sits with the teams that own identity, authorization, and application architecture together, because tenant separation is enforced across all three. Security reviews should map that responsibility explicitly, especially where delegated administration and self-service provisioning are in scope.
👉 Read our full editorial: Multi-tenancy in SaaS depends on tenant-scoped identity controls
