Definition
Provisioning (Device Network Configuration) refers to binding the device with the platform and user, completing the initial access, and issuing Device Credentials. It supports various methods such as QR Code Provisioning scanning, ZeroConf zero-configuration, and Device User Binding user binding.
Network Access Methods
QR Code Provisioning: The device or its packaging has a printed QR code; after the user scans it, the App parses the WiFi/platform information and configures the network, suitable for consumer devices. ZeroConf: The device and phone are on the same network segment, allowing automatic discovery and network configuration without scanning. Dynamic Registration: In the one-device-one-secret scenario, the device applies for credentials from the platform using ProductKey + DeviceName + signature. Pre-burned on production line: one-device-one-secret, the production line pre-writes Device Credentials, ready to use out of the box.
Relationship with Device Onboarding
Provisioning focuses on "configuration and binding," while Device Onboarding focuses on "the complete process of initial device access." The two are often combined in descriptions: from device unboxing, network configuration, obtaining credentials, initial connection, activation, to full usability. The platform needs to support batch import, integration with production line tools, and user self-binding, meeting the networking efficiency requirements of different scenarios.
Security Considerations
Credential issuance must be transmitted in encrypted form; QR code content can be encrypted to prevent leakage; dynamic registration must verify the device's unique identifier (such as MAC, IMEI) to prevent replay; credential rotation and revocation should be supported. Provisioning is the starting point of the device lifecycle, and security design directly impacts subsequent Device Authentication and platform security.
Where credential issue ends and account binding begins
Provisioning does two jobs that are easy to collapse into one step: it gives the device a credential that can pass authentication, and it records that device under a user or an organization. The credential answers which device this is. The binding answers who may manage it. Factory pre-burn usually finishes only the first job. Out of the box the device can reach the platform, but it still has no user. QR and zero-configuration often do both jobs on site. Writing the binding into the credential itself means a transfer between accounts requires a new key, so later certificate rotation and key revocation get dragged along by every account change.
Dynamic registration sits between the two. The device holds only product-level material and its own unique identifier, and it asks for a device-level credential on the first connection. That holds only when the platform can check that the identifier has not already been registered, and when the request window expires. If the identifier can be copied, dynamic registration issues a valid credential to a clone. Provisioning is finished when the credential is stored on the device, the platform state is ready to connect, and the binding can be queried. It is not finished when a key has merely been received. A record written only halfway should stay inactive, and it must not appear in monitoring or in batch tasks.
When factory pre-provisioning and field completion each apply
One-device-one-secret pre-burn fits devices whose identity is fixed at the factory and whose burn result can be reported back to the platform. The fixture and the platform must share one device list, and a failed unit must be reworked instead of leaving with a half-written key. Field completion fits consumer devices, or any device whose owner must confirm possession in person: an app is at hand, and the network lets the device or the phone return a token to the platform. An industrial device with no screen, no phone to pair, and a need to come online within seconds of power-up is a poor fit for an on-site scan.
A bulk imported list and single-device self-binding can coexist, but the identifier on the list must match the identifier on the chassis. If the import uses a serial number and the device reports a module identity, the platform treats the arrival as a new device, and the old binding waits forever for a connection. When onboarding also drives later state, put not-issued, issued-but-unbound, bound, and revoked under the state machine. An API must not write an arbitrary state straight to activated.
When the same device is provisioned more than once
A repeated open usually comes from three actions stacked together: the line burned the device again, the warehouse scanned the package code, and the user provisioned it once more on site. If each pass issues a new credential and does not revoke the old one, the device keeps only the latest, while an old key may still be accepted by the platform. A cloned or captured old key can then connect. Keep one current credential for a given device identity. When the new credential takes effect, the old one stops immediately, and record which open triggered the rotation.
Another mistake is to treat "joined the network" as "provisioned." The device has joined the home router but never received a platform credential, and the app already says the job is done. The device then never appears on the platform, and the user resets it again and again. The app should separate local-network reachability from the platform registration receipt. Do not end the flow without confirmation of a device-level credential. Unbinding is not finished by clearing an account field either. If the credential is still valid, the device keeps reporting after the original user has left. Decide at the same time whether the credential stays for the next owner or is revoked immediately.
A provisioning record should answer three questions: which operation issued the credential, which account or organization it was bound to, and whether that operation revoked the previous credential. Miss any one of them and support can see a device that is online only some of the time, without knowing which key to trust. In a batch open, list failed units with their own reasons. Do not mark a failed row complete because most of the batch succeeded. When a reworked device returns to the station, keep the original identity and rotate the credential. Do not mint a new identity and cut the warranty and the history in two.