Notifications
Clear all
Topic starter
12/06/2026 9:48 pm
TL;DR: Per-tenant user isolation lets the same login ID become separate accounts with independent credentials, MFA state, profile, and history across tenants, according to Descope. That matters when white-label, franchise, regulated B2B2X, or acquisition-driven platforms need sovereign identity stores instead of shared-user models.
NHIMG editorial — based on content published by Descope: Per-Tenant Identity Isolation for B2B Platforms
Questions worth separating out
Q: How should B2B platforms decide between shared-user and tenant-level identity models?
A: Choose a shared-user model when people need to move fluidly between tenants with one identity record.
Q: Why does tenant-level identity isolation matter for regulated B2B products?
A: It matters because some regulated environments treat each downstream client as a separate control domain, so shared identity state can weaken accountability and evidence boundaries.
Q: What breaks when one user record is shared across tenants that need separation?
A: The main failure is that credentials, MFA enrolment, and history become portable across tenants even when the business expects them not to be.
Practitioner guidance
- Map tenant sovereignty requirements before choosing an identity model Document whether each tenant should share credentials, MFA state, and profile data or maintain fully isolated accounts.
- Review lifecycle workflows against tenant-specific records Test provisioning, offboarding, and recovery for users who belong to more than one tenant.
- Align delegated administration with the real control boundary Give each tenant admin authority only over the identities and policies inside that tenant.
What's in the full article
Descope's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration guidance for enabling tenant user isolation in the project settings.
- The specific enterprise-readiness features that continue to work when user records are isolated per tenant.
- Examples of which deployment patterns fit shared-user identity and which require sovereign tenant accounts.
- The product-side explanation of how delegated administration and the embeddable admin portal behave under the new model.
👉 Read Descope's analysis of per-tenant identity isolation for B2B platforms →
Per-tenant identity isolation for B2B platforms: when does it matter?
Explore further
13/06/2026 12:07 am
Tenant-level identity isolation is a governance boundary, not a convenience feature. The article shows that some B2B platforms cannot safely treat tenant membership as a simple authorization overlay because the same person must exist as two independent identities. That matters when downstream clients are sovereign from one another in practice, even if they share a codebase. Practitioners should read this as a signal that identity architecture has to follow the legal and operational boundary, not just the product hierarchy.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own tenant-level user governance in a multi-brand B2B platform?
A: Ownership should sit with the team responsible for tenant architecture, identity governance, and customer-domain boundaries, not just the application team. If tenant isolation is part of the control model, it needs explicit lifecycle ownership, delegated admin rules, and audit scope defined at design time, not after rollout.
👉 Read our full editorial: Per-tenant identity isolation changes B2B CIAM assumptions
