The Multi-Tenant “Blast Radius” Controller: Implementing Identity Segregation with Hexnode UEM MSP

1. Executive Summary

The “Blast Radius” Controller is a security architecture used by large enterprises and Managed Service Providers (MSPs) to enforce the Principle of Least Privilege (PoLP). In expansive organizations with multiple subsidiaries, granting global administrative rights creates a catastrophic single point of failure. If a Global Admin’s credentials are compromised, the entire corporate fleet is at risk.

Hexnode UEM MSP acts as a secure switchboard, utilizing a Multi-Tenant Identity Architecture. By treating each client or business unit as an independent “Node” (Tenant), it provides strict data isolation, localized Identity Provider (IdP) integration, and precise Role-Based Access Control (RBAC). If a threat compromises one tenant, the multi-tenant architecture ensures the blast radius is hard-stopped at that specific node’s perimeter.

2. The Pillars of Multi-Tenant Segregation

Hexnode’s MSP architecture relies on three foundational pillars to separate environments:

• The “Node” Concept (Directory Isolation): Instead of one massive portal, the MSP spins up separate Hexnode UEM portals (Nodes) for each client (e.g., client-a.hexnodemdm.com and client-b.hexnodemdm.com). Each node connects only to that specific client’s directory (e.g., Microsoft Entra ID or Google Workspace), ensuring no cross-tenant identity collision.
• Top-Down RBAC & Scope Sandboxing: The central Hexnode MSP portal acts as a “Manager of Managers.” MSP technicians are assigned scopes limiting their access to specific tenant portals. A technician may hold Admin rights in one node, but zero visibility in another node.
• Data Sovereignty & Compliance: Because each node is a standalone database, device logs, user Personally Identifiable Information (PII), and security credentials remain strictly isolated. Organizations can even select specific regional data centers for specific nodes to comply with laws like GDPR or HIPAA.

3. Implementation Workflow: Configuring Segregation

Step A: Provisioning the Client Node

1. Log in to the global Hexnode MSP Portal.
2. Navigate to the Customers tab and click Add Customer.
3. Enter the client’s details and define the specific Data Center region for compliance.
4. Result: A dedicated, isolated Hexnode UEM portal is instantly generated for the client.

Step B: Segregating the Identity Provider (IdP)

The Identity Anchor must be established inside the isolated node, not at the global MSP level.

1. From the MSP dashboard, jump into the specific Client Tenant Portal.
2. Navigate to Admin > Integrations (e.g., select Microsoft Entra ID or Google Workspace).
3. Authenticate using the Client’s specific Global Admin credentials.
4. Result: The client’s users and groups are synced exclusively to this node. Users from Client A will never appear in Client B’s directory.

Step C: Mapping Technician Scopes

1. Return to the Hexnode MSP Portal and navigate to Admin > Technicians.
2. When creating or editing an MSP Technician, assign their Role (e.g., Admin, Reports Manager).
3. Under the Scope settings, explicitly select the Customer Tenants (Nodes) this technician is authorized to manage.
4. Result: Upon login, the technician only sees the pooled data and dashboards for their assigned clients.

4. Directory Sync Logic & Security Impact

5. Troubleshooting & Validation

• Identity Sync Failures: If directory synchronization fails for a specific tenant, verify that the Client’s Azure/Google Administrator has not revoked the API consent permissions for the “Hexnode Azure Directory Services” app within their own IdP environment.
• Global vs. Local Roles: If an MSP technician needs highly granular custom permissions (e.g., “Can only view iOS devices for Client A”), the standard MSP-level scope might be too broad. Use the MSP portal to grant access to the tenant, then log into the Client Tenant Portal to configure a Custom Technician Role specifically for that user.