End-User Device Registration and Onboarding

Manufacturing the device and provisioning its cloud identity are factory operations. The moment a customer takes the product home, installs it, and opens your app, that's a different problem entirely.

The end-user onboarding flow, often called device registration, device claiming, or device activation, determines whether a customer successfully associates their device with their account, or gives up and calls support. It also determines whether your backend correctly enforces that each user can only access the devices they own.

The challenge​

The user onboarding flow for a connected product involves several steps that sound simple but have non-trivial backend requirements:

• Device identification: the user must prove they physically possess the device, typically by entering a serial number, scanning a QR code on the packaging, or triggering a physical interaction with the device itself. Each method has different security trade-offs.
• Ownership verification: before associating the device to the user's account, the system must confirm the device exists, has been legitimately manufactured, and hasn't already been claimed by someone else. Without this, a user could claim a device they don't own by guessing a serial number.
• Physical possession verification: for higher-security scenarios (preventing serial-number guessing or unauthorized device claiming), the device itself must send a confirmation signal during the activation window. If the device doesn't respond within the configured timeout, registration fails. This "physical presence" check is the standard pattern for secure device claiming in consumer IoT.
• Account association: once verified, the device is linked to the user's account and IAM policies are applied, the user can now access the device's data and controls through the app.
• Multi-user sharing: some products allow multiple users to access the same device (a household sharing a thermostat, for example). The ownership model must support one-to-many associations without losing accountability.
• Transfer of ownership: when a device is sold second-hand, re-deployed to a new site, or reassigned within a customer account, the previous owner's association must be cleanly removed before a new device claim is created. Without a formal transfer flow, re-registration creates edge cases in access control and data history that are frequently the source of unexpected bugs.

What it takes to get it right​

A production-grade device onboarding flow requires:

1. Pre-registration validation: before accepting a device claim, confirm the device exists in the system and is in a claimable state.
2. Configurable association modes: one-to-one for exclusive ownership, one-to-many for shared access, with the ability to define whether each additional user gets read-only or full control.
3. Protected verification option: a second factor that requires the physical device to respond during the registration window, preventing serial-number guessing attacks.
4. IAM integration: the moment ownership is established, the correct permissions are applied automatically; no separate permission-grant step for the developer to manage.
5. Historicized ownership records: a complete audit log of who owned what and when, important for warranty claims, GDPR data deletion requests, and support escalations.

How Connhex solves it​

Connhex Device Ownership is a dedicated service that handles the entire end-user registration flow.

The flow works as follows:

1. The user submits a device identifier (serial number or equivalent) through your app.
2. Connhex Device Ownership validates the identifier against Connhex Manufacturing, confirming the device exists and was legitimately produced.
3. If physical possession verification is enabled (the "protected activation" mode), the service waits for the device to send a registration-enable signal within the configured timeout. If the signal doesn't arrive, the device claim is rejected: the user must physically have the device to complete the activation.
4. In one-to-one mode, the service checks via Connhex Resources that the device has not already been claimed.
5. Ownership is created: a resource record is established linking user to device, and Connhex IAM automatically applies the correct access policies, the user can now interact with their device through the app.

The developer's job is to implement the app-side UI for the registration step and call the Device Ownership API. The backend validation, verification, and permission assignment happen automatically.

How this connects to the manufacturing flow​

Connhex Device Ownership depends on Connhex Manufacturing having a record for each device. This is why the provisioning and manufacturing steps matter: a device that wasn't registered in Manufacturing during production cannot be claimed by an end user. The chain, manufacturing record → provisioning → end-user registration, is what closes the loop from factory to customer.

See Secure Device Provisioning for how the earlier stages of this chain work.

Relevant verticals​

Device onboarding is critical wherever devices are sold directly to end users or through a channel that requires activation:

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

Read the technical docs​

• Device Ownership, Introduction
• Device Ownership, Internal Workflow
• Manufacturing, Introduction
• Device Registration Quickstart