Notifications
Clear all
Topic starter
11/06/2026 10:55 pm
TL;DR: Static RBAC breaks down in multitenant SaaS because one user can need different permissions across tenants, and role explosion quickly turns permissions into an unmanageable matrix, according to Cerbos. Dynamic, tenant-aware roles plus ABAC shift authorization from brittle code checks to policy-driven decisions that scale with context.
NHIMG editorial — based on content published by Cerbos: scaling multitenant authorization beyond static RBAC
Questions worth separating out
Q: How should security teams scale authorization in multitenant SaaS applications?
A: Security teams should make tenant context a first-class input to authorization decisions.
Q: Why does role explosion happen in multitenant applications?
A: Role explosion happens when teams try to encode every tenant-specific exception as a new role instead of expressing scope in policy.
Q: What breaks when authorization logic is hardcoded into application code?
A: Hardcoded authorization breaks consistency because each service can end up enforcing rules differently.
Practitioner guidance
- Map every decision to tenant context Inventory where your application authorizes by user role alone and identify the requests that also depend on tenant, workspace, or project scope.
- Collapse tenant-specific role variants Find role names that exist only to encode customer differences, then move those differences into attributes or policy rules.
- Externalize authorization to a policy engine Remove scattered if and else checks from application services and centralise decisions in one policy layer.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- A worked multitenant SaaS authorization blueprint showing how tenant-aware roles are structured in practice.
- Concrete policy examples for attribute based access control, including tenant, ownership, and region-based rules.
- A walkthrough of externalized policy decision points and how they simplify enforcement across services.
- The demo flow and ebook context that show how the model behaves in a real application.
👉 Read Cerbos' guide to scaling multitenant authorization without role explosion →
Multitenant authorization and role explosion: what IAM teams need?
Explore further
12/06/2026 7:20 am
Static RBAC becomes a governance liability when tenant scope matters. The model assumes that a role has one stable meaning across the system, but multitenant applications need the same identity to behave differently depending on tenant context. That is not just an implementation inconvenience, it is a governance mismatch between coarse roles and contextual access. Practitioners should treat role proliferation as a signal that the authorization model has outgrown its original assumptions.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should own tenant-specific permission changes in a policy-driven model?
A: Ownership should sit with the platform or IAM team for the global policy foundation, while tenant administrators can manage only the scoped exceptions they are allowed to control. That balance preserves isolation, keeps the governance model coherent, and prevents local flexibility from undermining system-wide access rules.
👉 Read our full editorial: Scaling multitenant authorization beyond static RBAC
