IoT Provisioning: Onboarding Devices Without a Support Ticket

The single biggest source of IoT support cost we see across products is device onboarding. The factory works. The cloud works. The customer cannot get the device on the network. The pattern is so common that improving onboarding is often the highest-ROI investment a connected-product team can make.

What good onboarding looks like

A reasonable benchmark, achievable on most product types in 2026:

• Time to onboarding completion: under two minutes for 90% of customers.
• Manual steps: scan a code, confirm one screen, done.
• Failure recovery: every failure has a specific message and a specific next step. No “something went wrong, try again.”
• Connectivity: works in customer’s home environment, not just on engineering Wi-Fi.

A team that hits these has effectively eliminated the largest source of support tickets new customers generate.

The patterns that get there

Three patterns dominate, depending on the device.

BLE-then-Wi-Fi (consumer connected devices)

The classic pattern: the device advertises over BLE, the phone app discovers it, the user picks their Wi-Fi network in the app, the app sends credentials to the device over BLE, the device connects to Wi-Fi.

Variations:

• Apple HomeKit / Matter standardize this flow. If the product supports Matter, use the Matter onboarding flow. The OS handles the awkward parts.
• SoftAP fallback for devices that do not have Bluetooth or for users whose phone Bluetooth has been disabled. The device exposes a temporary Wi-Fi network the phone connects to; credentials transfer over HTTP. Works, but fights with phone OS heuristics that try to drop networks without internet.

The trap: pairing flows that assume permissive defaults. Modern iOS and Android require explicit Bluetooth, location, and local-network permissions. Each denial breaks the flow. The recovery for each denial must be designed, not improvised.

QR-code preprovisioning (industrial / commercial)

The device ships with a unique QR code. The user scans it during installation. The QR encodes:

• A device ID that the cloud already knows.
• A short-lived setup token.
• The Wi-Fi or LoRa network ID for the customer site, if known at manufacturing.

The first time the device powers on, it tries known credentials. If they match, it joins. If they do not, the user enters the actual credentials in the app once, and they propagate to the device.

This pattern works well when the product is installed by a technician at a known site. It works less well for consumer use cases where the customer’s network is not known until purchase.

Zero-touch provisioning (managed deployments)

For fleets where the customer’s network is centrally managed, the device receives credentials over a secure provisioning channel — typically a managed Wi-Fi profile, a cellular APN, or an IoT hub claiming flow.

AWS IoT, Azure IoT Hub, and Google Cloud IoT all support variants of this. The device ships with a manufacturing certificate; on first boot, it presents the certificate to the cloud, the cloud authenticates and provisions the device into the customer’s account based on supply-chain metadata.

This pattern is the right choice for B2B fleets — utilities, smart buildings, industrial deployments — where IT controls the network and the device is delivered to a known account.

The infrastructure behind a smooth flow

Underneath any of these patterns, the supporting work makes or breaks reliability:

• Per-device certificates, written at manufacturing, never reused. Every device has its own identity from the moment it leaves the factory.
• A claiming flow that binds the device to a customer account. Either explicit (the customer enters a code) or implicit (the certificate maps to known customer metadata). The decision is which trust assumption you can defend.
• Atomic state transitions. Half-onboarded devices are a permanent support burden. Either the device is fully onboarded and visible in the customer’s account, or it is in a recoverable state. No middle ground.
• A factory reset that works. Customers will hand devices to other customers, return them, or simply move them. Reset must clear credentials, certificates, and state cleanly.

Where most teams stumble

Common failure modes:

• Optimizing for the engineering office. Engineering Wi-Fi is unique — strong signal, no captive portal, modern hardware. Customer environments include weak Wi-Fi, captive portals, mesh networks, and 2.4-vs-5 GHz confusion. Test in real environments.
• No diagnostic mode. A device that fails to onboard is silent by default. Build a diagnostic mode that reports specifically why it failed — wrong credentials, no DHCP lease, DNS failure, certificate verification failure — over BLE so the app can surface the actual problem.
• Treating onboarding as a one-time event. Devices change networks. Customers move. Routers get replaced. The flow needs a “re-onboard” path that is as smooth as the first onboarding.
• No timeout on partial failures. A device that hangs forever waiting for a step it will never receive is worse than a device that gives up and tells the user. Aggressive timeouts with clear messages.

What we hand over

A provisioning system shipped well includes:

• The end-to-end flow, tested in three environments (engineering Wi-Fi, a typical home network, a difficult network with captive portal or weak signal).
• A factory provisioning step, scripted and verifiable, that produces measurable test results per unit.
• Per-error documentation: what it means, what the user sees, what the support team should ask.
• A “watch onboarding” diagnostic mode for the support team.

If your product has an onboarding flow and you are still seeing support tickets about it, we have measurable patterns for fixing this.