Simplifying multi-tenant device management with the Service Provider tenant

Managing fleets of embedded devices at scale is not a simple task especially when considering multiple customers, diverse environments, and varied security requirements. To address these concerns, multi-tenancy has long been a feature of Mender Enterprise, allowing operations teams to create and manage isolated tenants within a single Mender Server instance.

The release of Mender Server 4.0 overhauled multi-tenancy with the new Service Provider capability. The Service Provider tenant elevates multi-tenancy with an easy-to-manage approach across complex, multi-environment deployments through a dedicated management interface. 

The Service Provider tenant 

At its core, the Service Provider tenant introduces a two-level hierarchy:

• The Service Provider tenant acts as the top-level entity creates and manages multiple child tenants.
• Each child tenant remains securely isolated, with its own devices, users, and update workflows.

The main focus of the Service Provider tenant is scale, governance, and control without sacrificing the autonomy of individual environments. With easy-to-configure prompts in the management interface, administrators can set device limits, assign admins, and maintain visibility across tenants without risking data leakage or cross-tenant interference. Whether supporting multiple clients, segmenting enterprise development, or managing staging and production environments, Service Provider tenants simplify management and enhance security.

Common use case #1: Isolating customers or clients

Customer isolation plays a key role in managing device fleets across large customer ecosystems and ensuring all devices remain operational. For example, a system integrator in commercial buildings could isolate customer cases across building owners, guaranteeing each subsidy receives the proper update packages. A misconfigured device update for one building should never affect another building; by isolating each customer tenant, audit logs and update schedules are siloed to ensure security and privacy. Another application of customer isolation exists in automotive OEMs providing updates for several car brands under its umbrella. The luxury and economy lines both need updates, but might use different versions, update cadences, and regional compliance rules. Isolating customer tenants ensures brand-specific strategies remain operational without overlap.

Customer isolation is often non-negotiable for managed service providers, system integrators, or platform vendors. Whether for security, compliance, or risk containment, it's essential to ensure the operations of one device or customer don’t interfere with another. The Service Provider tenant gives each child tenant a dedicated, isolated environment within the overall structure. This means:

• No shared device data or update artifacts. 
• No risk of one client’s actions impacting another.
• Clear audit and access boundaries across tenants for compliance.  

The Service Provider admin then has the flexibility to either manage tenants directly, handling updates, devices, and troubleshooting on behalf of the client, or simply provision the tenant, assign an admin user, and let the client self-manage. In both cases, the Service Provider tenant structure ensures clean separation and controlled access. 

Common use case #2: Isolating development environments

Isolated development environments are especially important for software-focused OEMs like smart home IoT developers or consumer wearables. In the smart home OEMs, different teams may be working on separate update branches. If a beta update is prematurely released, bricked devices and security flaws could harm operations and the overall brand reputation. To protect brand reputation and operational continuity, each production line should work within its own development tenant with dedicated QC/QA processes and staging to allow full update simulation and ensure any updates will keep devices fully operational. Or, for consumer wearables OEMs, new features require user testing but cannot reach the public until they’re fully operational. Creating a beta testing environment isolates a select group of devices to test in a realistic but controlled environment before rolling an update out to the general population.

While developing embedded software, development, staging, and production environments must be kept strictly separate. Pushing a test update to live devices can cause costly disruptions, outages, and even permanent device bricks. The Service Provider tenant allows the creation of distinct environments, each as its own tenant with:

• Dedicated devices and deployment logic.
• Environment-specific access controls.
• Full separation of update history and artifacts.

Separation of different development environments is key for operational success and regulatory compliance. In regions with specific data sovereignty laws, it’s possible to allocate regional tenants that conform to local regulations while maintaining centralized oversight. 

Common use case #3: Isolating business divisions or product lines

Isolating business divisions is especially important for multinational industrial corporations, dealing with energy or manufacturing that are subject to differing regulatory requirements depending on the location of operations or products. For large enterprises with diverse product portfolios or decentralized divisions, a one-size fits-all approach can cause operational inefficiencies, outages, or security risks. For example, smart energy devices in energy grids must follow strict uptime and security policies, but could have differing compliance laws by country. By creating tenants for different business divisions across the globe, OEMs can ensure all smart energy products receive necessary updates while complying with location-specific regulations or standards. Different teams need autonomy, yet central leadership still requires visibility and governance. In this case, the Service Provider tenant allows enterprises to mirror internal structure, assigning each vertical or product line its own tenant. Each group operates environments independently, while the Service Provider admin can monitor usage, manage resources, and ensure across the board compliance.  

Service Provider tenant structure and management

The Service Provider tenant provides a structured, scalable approach to multi-tenant management to efficiently oversee multiple isolated environments. Through the new management interface, secure and streamlined hierarchy allows separation of multiple environments and tenants. The management interface comprises a two-level tree structure with the ability to create child tenants while seamlessly switching between tenant environments.

Two-level tree structure

At the core of the Service Provider tenant is the two-tier hierarchy:

• Parent tenant: The top-level entity that creates and manages child tenants. It has control over tenant creation, resource allocation, and initial user assignments. 
• Child tenants: Independently managed environments, each with its own devices, users, and update workflows. These tenants remain completely isolated from one another. 

This structured approach ensures that admins can organize and manage multiple tenants effectively while maintaining boundaries for security and compliance across the differences of the tenant environments. 

Child tenant creation

An admin has full control over creating and configuring new tenants. This process includes three critical steps:

1. Setting device limits: Each child tenant operates within a predefined device allocation, ensuring resources are distributed according to operational needs. The admin assigns these limits, which are carved from the overall device pool. For example, if a Service Provider has a total allocation of 1,000 devices, they may assign 300 devices to one child tenant, 500 to another, and keep 200 in reserve for future tenants.
   
   
2. Assigning the initial admin user: When a new child tenant is created, the admin designates an initial admin user. This user becomes the first point of access for managing the tenant. If needed, the Service Provider admin can add themselves as an admin, allowing direct management of the child tenant. The Service Provider admin cannot access a child tenant unless explicitly added as a user inside that tenant to ensure strict isolation between environments.
   
   
3. Seamless tenant switching: Managing multiple tenants shouldn’t also create the burden of juggling multiple logins. The Service Provider tenant enables seamless tenant-switching, allowing users who have access to multiple tenants to move between them instantly without re-authinticating through SSO. The user-friendly interface ensures that admins overseeing multiple environments can navigate between tenants effortlessly, improving overall operational efficiency. 

Unlocking scalable, secure multi-tenancy with Mender 

The Service Provider tenant in Mender Server 4.0 provides streamlined groundwork for multi-tenancy management. The two-level hierarchy, managed through its own interface, provides an easy-to-use, robust framework for securely managing multiple tenants, whether they are customers, environments, or business verticals. This model provides stronger security and compliance through strict tenant isolation, greater operational efficiency with centralized oversight, and overall scalability to further accommodate growing device fleets and operational concerns.

Read more about Mender’s multi-tenancy capabilities in the documentation.