Should tenant-specific access be handled with custom roles or private spaces?

Why custom roles and private spaces solve different access problems

Tenant-specific access usually fails when teams try to force one control to do both jobs. A custom role is about authority: it limits the actions a tenant user can perform. A private space is about visibility: it limits which objects, records, or work areas that user can even discover. If you blur those boundaries, you often end up with overreach in one direction and awkward workarounds in the other.

That distinction matters because tenants do not only need fewer permissions, they often need cleaner isolation boundaries. A well-designed role model can keep the action surface narrow while still allowing a shared workspace to remain discoverable where appropriate. A private-space model, by contrast, is the right tool when the shared system itself would be confusing or risky if tenant content were visible at all.

The practical test is simple: if the user should see the item but not edit, approve, export, or administer it, the problem is role design. If the user should not know the item exists unless they are a member of that tenant, the problem is space or visibility design. That is why the best implementations often combine both rather than treating them as substitutes.

How to think about privilege versus visibility in multi-tenant design

In multi-tenant systems, access control has two separate questions. First, what can the identity do once it has reached a resource? Second, what resources can that identity reach in the first place? Custom roles answer the first question. Private spaces answer the second. Good design keeps those answers independent so one tenant’s configuration does not leak into another tenant’s operational model.

That separation helps in day-to-day administration too. If you use roles for visibility boundaries, you often create role explosion because every tenant-specific view needs a custom permission combination. If you use private spaces for operational authority, you risk making the content structure do the work of an authorization policy. Neither pattern scales cleanly on its own when tenants have different staff, different workflows, or different data sensitivity.

IAM and IGA Basics is useful here because it reinforces the difference between authorization design and entitlement governance. Authorisation Models Guide also helps when you need to decide whether tenant logic belongs in roles, policies, or relationship-based access rules rather than in the workspace structure itself.

When the model breaks down in practice

Problems usually appear when a team assumes that hiding something is the same as restricting it, or that limiting actions automatically limits exposure. If a tenant can reach a shared object through search, links, API responses, or side panels, then private-space semantics are incomplete even if the visible UI looks clean. If a tenant can see nothing but still has overly broad role permissions, then the system may be one integration or misrouted request away from a boundary failure.

Another common failure is using roles to manage tenant-specific content segregation when the real requirement is contextual containment. That creates brittle exceptions, because every exception has to be expressed as a permission rule. The reverse mistake is using private spaces to represent business authority, which can make review, delegation, and escalation harder than they should be. The control model should match the question being asked of it.

IAM and IGA Basics is also relevant for lifecycle thinking, because tenant-specific access often changes as users move between accounts, teams, or customer relationships. When the tenancy boundary changes, visibility and privilege should both be rechecked, not assumed to stay aligned.

Practitioner Guidance

What to prioritise: Define the tenant boundary first, then map separate rules for visibility and action. If the business requirement says “must not see,” design a private-space or equivalent isolation boundary. If it says “may see, but may not do,” design a role or policy boundary.

What to verify: Test the boundary through every access path, not just the main UI. Search, APIs, links, exports, notifications, and embedded widgets are where “private” spaces often leak, while custom roles often fail to constrain an overlooked action.

Common mistake: Treating custom roles and private spaces as interchangeable. That usually produces either role sprawl or brittle visibility logic, and it makes audits harder because nobody can explain whether the control is limiting action, visibility, or both.

Practitioner takeaway: Use the simplest control that matches the security question, but do not force one control to carry both isolation and privilege if the tenant boundary matters operationally.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they try to manage tenant access and custom roles across multiple CIAM vendors?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?