User and Installer Role Management for Connected Products

A connected product doesn't have one type of user, it has at least three. The manufacturer's operations team needs visibility into the entire fleet. Field installers commission, configure, and maintain devices at customer sites, they need access to the devices they manage and nothing else. End users own specific devices and interact with them through a consumer app.

Each of these actors needs a different view of the data and a different set of permissions.

The challenge​

Permission models in IoT products tend to start simple and accumulate complexity over time:

• Flat access models break at scale: a single admin role that grants access to everything works for three employees; it becomes a liability with 50 installers across multiple customers.
• Data isolation between customers: an installer serving customer A must never see data from customer B, even though both are in the same system. Enforcing this at the application layer is fragile and error-prone.
• Installer-specific tools: installers need commissioning tools, diagnostic views, and configuration access that end users should never see. These must be gated by role, not by building a separate application.
• Manufacturer back-office: the manufacturer needs cross-fleet visibility, which they cannot grant to anyone else, plus the ability to delegate specific fleets to service partners without exposing everything.
• Audit requirements: regulated industries and enterprise customers require a complete record of who accessed what, and what they changed.
• App-level feature gating: features that are only available to certain roles (e.g. "configure thermostat schedule" is available to installers but not end users) must be enforced at the API level, not just in the UI.

What it takes to get it right​

A production-grade role and permission system for IoT requires:

1. Hierarchical data model: devices belong to sites; sites belong to customers; customers belong to the manufacturer. Permissions propagate down this hierarchy but can be scoped to any level.
2. Role-based access control (RBAC): predefined roles (manufacturer admin, installer, end user) with configurable permission sets attached to each.
3. Attribute-based access control (ABAC): for fine-grained cases, permissions based on resource attributes (e.g. "installer can configure, but not delete, any device in their assigned site").
4. Multi-tenant data isolation: enforced at the data layer, not the application layer. A query from an installer's session cannot return data outside their scope, regardless of the API call.
5. Delegated administration: a manufacturer can grant an installer company admin rights over their subset of the fleet, and that installer admin can manage their own users, without touching anything outside their scope.
6. Audit log: every access and modification is recorded with actor, timestamp, resource, and outcome.

How Connhex solves it​

Connhex was built from day one around a multi-tenant, role-aware architecture, because every manufacturer we work with has this exact problem.

Connhex Auth handles user identity across all app types: mobile, web, and back-office. Registration, login, session management, and token lifecycle are all handled by Auth, which integrates with any frontend via standard OAuth 2.0 / OIDC flows.

The IAM system provides the permission model:

• Roles and policies: define what each role can do (read telemetry, push commands, manage users, view billing) and assign roles to users or groups.
• Resource scoping: every permission is scoped to a specific part of the device hierarchy, a policy can grant an installer read access to all devices in their assigned sites, and nothing else.
• Multi-tenant isolation: each organization's data is isolated at the data layer. An installer's API calls cannot return data outside their scope, regardless of how the query is constructed.
• Delegated administration: manufacturer admins can grant sub-admin rights to installer companies, allowing them to manage their own users without manufacturer involvement in every change.

Device Ownership formalizes the end-user relationship: a user claims ownership of their specific device, and that ownership is enforced at the API level: their app session can only access their own devices.

How the three-actor model works in practice​

A typical manufacturer deployment has three actor types with strictly separated access:

Importantly, this isolation is enforced at the data layer, not the application layer. An installer's API session cannot return data outside their assigned scope, regardless of what parameters they pass. The application doesn't need to implement filtering logic; the platform enforces it.

See it in practice​

User and role management is critical across all verticals where Connhex operates. It is particularly prominent in the HVAC and smart home use cases, where the installer-manufacturer-end-user relationship is the core operating model:

Connhex for HVAC · Connhex for the Smart Home · Connhex for the Spa and Swimming Pool · Connhex for Vending Machines

Read the technical docs​

• IAM, Introduction
• IAM, Key Concepts
• Device Ownership, Introduction
• Connhex Auth, Overview