Notifications
Clear all
Topic starter
12/06/2026 12:32 am
TL;DR: Multi-tenant SaaS authorization needs hierarchical scopes, role policies, and scoped resource policies to keep tenant data isolated while still allowing tenant-specific role customisation and auditable access decisions, according to Cerbos. The key issue is not just control design, but whether platform guardrails can survive tenant-level flexibility without creating cross-tenant exposure.
NHIMG editorial — based on content published by Cerbos: multi-tenancy in SaaS applications with scoped resource policies and role policies
Questions worth separating out
Q: How should teams design multi-tenant authorization so tenant data stays isolated?
A: Start with explicit tenant boundaries in policy data, then require principal and resource tenant matching before any allow can resolve.
Q: When does tenant-specific role customisation become a security problem?
A: It becomes a problem when the tenant role can exceed the platform's intended maximum privilege or when inheritance is not constrained by a clear parent role.
Q: What breaks when scoped resource policies can override parent scope rules freely?
A: Free override lets local policy become the source of truth for access, which can create privileges the platform never intended to permit.
Practitioner guidance
- Define tenant-match conditions as a hard gate Require every tenant-scoped allow to prove that principal and resource share the same tenantId before the decision can resolve to allow.
- Set platform-wide maximum roles first Create parent roles that represent the highest permissible access, then let tenant-specific roles narrow those capabilities without introducing new action paths.
- Use parental-consent modes for delegated policy Choose a scope permission mode that forces child-scope allows to remain inside parent scope boundaries when tenants can author local resource rules.
What's in the full article
Cerbos's full guide covers the implementation detail this post intentionally leaves for the source:
- Complete YAML examples for root, scoped role, and scoped resource policies
- Step-by-step evaluation flow showing how scope matching and inheritance produce a final decision
- Concrete examples of tenant-specific HR policies for leave requests and salary records
- The exact behaviour of scope permission modes when child and parent scopes disagree
👉 Read Cerbos's guide to multi-tenant access control with scope permissions →
Multi-tenant access control in SaaS: are scope permissions enough?
Explore further
12/06/2026 9:48 am
Scope-based multi-tenant control is a governance boundary problem, not just an application feature. The article shows that tenant isolation depends on whether policy evaluation can prove contextual separation before access is granted. That matters because multi-tenant SaaS often fails when application logic assumes the tenant boundary is already trustworthy. Practitioners should treat tenant scope as an access-control primitive, not a UI or routing convenience.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who should own the top-level access boundary in a shared SaaS platform?
A: The platform owner should own the top-level boundary, because tenants need flexibility inside a governed envelope, not the ability to redefine it. Tenant teams can manage local roles and resource rules, but the final access ceiling must stay with the central policy layer and its audit trail.
👉 Read our full editorial: Cerbos scope permissions and tenant isolation in multi-tenant SaaS
