Notifications
Clear all
Topic starter
07/06/2026 8:43 pm
TL;DR: Multi-tenant SaaS RBAC breaks when teams treat roles as global, skip tenant scoping in authorization checks, or let custom roles and caches blur tenant boundaries, according to WorkOS. The practical issue is not RBAC itself but enforcing predictable, debuggable tenant-aware access at every layer.
NHIMG editorial — based on content published by WorkOS: How to design an RBAC model for multi-tenant SaaS
Questions worth separating out
Q: How should security teams implement RBAC for multi-tenant SaaS?
A: They should scope roles, permissions, and assignments to tenant context, then enforce tenant membership and resource ownership again at runtime.
Q: What breaks when tenant_id is missing from RBAC checks?
A: A missing tenant_id turns a local permission into a global one.
Q: How do you know if a multi-tenant RBAC model is actually working?
A: You know it is working when you can explain every allow or deny with tenant-scoped evidence: membership, role assignment, permission mapping, and resource ownership.
Practitioner guidance
- Enforce tenant context at every authorization boundary Require tenant_id in role assignments, permission lookups, cache keys, and resource checks.
- Use role templates with explicit override limits Allow tenants to customise roles through a bounded template model instead of unrestricted custom role creation.
- Cache effective permissions, not global decisions Key authorization caches by user, tenant, action, resource type, and policy version.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Concrete schema patterns for global, tenant-scoped, and hybrid RBAC models.
- Example SQL table structures for role, permission, and assignment relationships.
- Implementation notes on index design, query predicates, and permission resolution joins.
- WorkOS-specific guidance on tenant-aware RBAC with Organizations, SSO, Directory Sync, and Audit Logs.
👉 Read WorkOS's guide to designing multi-tenant RBAC for SaaS →
Multi-tenant RBAC and tenant isolation: where do teams get it wrong?
Explore further
08/06/2026 8:22 am
Tenant-scoped authorization is the only RBAC model that can preserve tenant isolation under enterprise customisation. Global roles are attractive because they look simple, but they force every customer into the same access worldview. That breaks as soon as billing, compliance, and delegated administration needs diverge across tenants. The implication is that product teams should stop treating multi-tenant RBAC as a flat permission list and recognise tenant context as part of the identity boundary.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming one and 26% suspecting one.
A question worth separating out:
Q: What should teams do when enterprise customers need custom roles?
A: Give them controlled extensibility through templates, not unlimited freedom. Let tenants clone or override approved base roles within explicit limits, then keep the backend authoritative so the customisation layer cannot bypass tenant isolation or create unreviewed privilege paths.
👉 Read our full editorial: Multi-tenant RBAC needs tenant scope, not global roles
