Provisioning Connected Devices: From Factory to First Setup

What provisioning covers

Microsoft's overview of the Device Provisioning Service describes provisioning in the cloud context as a two-part process: first registering the device, which establishes its initial connection to the IoT solution, then applying the configuration that solution needs. Only when both are done is the device "fully provisioned".

In practice, three parties take part:

• The factory, which puts credentials and the provisioning service's address on each unit.
• Your cloud, which decides which devices are allowed in and what records to create for them. Our guide to IoT cloud platforms explains the device registry this feeds.
• The person setting it up, through your app or a smart-home app, who gives the device its Wi-Fi details and links it to their account. The setup screens themselves are covered in our guide on connecting a device to a mobile app.

This guide is about the first two, and how they hand over to the third.

The factory step: giving each device an identity

Devices on the major IoT clouds prove who they are with credentials, and the way those credentials reach the device is the first decision. Microsoft's security practices for device manufacturers name three widely used types:

• X.509 certificates: each device holds a certificate and a private key, with the certificate signed by a certificate authority (CA) you trust.
• A Trusted Platform Module (TPM): a security chip whose endorsement key identifies the device. Microsoft says TPM attestation "is easier to secure" than symmetric keys.
• Symmetric keys: the same secret is known to the device and the service. Microsoft calls this "the simplest, lowest cost way to get started", but says it "requires significant owner responsibility to secure the keys", and recommends protecting them with a hardware security module.

Microsoft's DPS overview notes that provisioning does not add a new step to manufacturing. It ties into the existing step that installs the first software and, ideally, the hardware security module. The manufacturer then hands the device operator the identifying information, which can be as simple as confirming that all devices carry certificates generated from a signing certificate the operator supplied.

Whichever type you choose, each unit should end up with its own credential, never one shared secret for the whole product line. Why that matters, and which laws now require it, is covered in our IoT device security guide.

AWS IoT: three routes to a device certificate

On AWS IoT a device connects with an X.509 certificate attached to a "thing" in the registry, and an IoT policy attached to the certificate sets what the device may do. AWS's device provisioning page sorts the options by one question: can you install a unique certificate on each device before it ships?

• Yes: just-in-time provisioning (JITP) or registration (JITR). You register the CA that signs your device certificates with AWS IoT. When a device first connects, AWS IoT recognises the CA and creates the device's resources from a provisioning template, as the JITP documentation describes.
• No, but an installer or end user can run an app: provisioning by trusted user. The signed-in user's app requests a temporary claim certificate and passes it to the device along with settings such as Wi-Fi details. AWS says this temporary certificate expires after five minutes, and within that window the device must obtain its permanent certificate.
• No app is involved: provisioning by claim. Every device ships with the same claim certificate. On first connection, AWS IoT registers the device and issues its own certificate. AWS warns that this "could present a larger risk in the event of a compromised claim certificate": you can deactivate a leaked claim certificate so no new devices register with it, but that "does not block devices that have already been provisioned".

The two claim-based routes are what AWS calls fleet provisioning. The device either asks AWS to create a new key and certificate, or sends a certificate signing request (CSR) so its private key never leaves the device. It then calls RegisterThing, reconnects with the permanent certificate and uses it from then on. AWS asks you to keep claim private keys secured at all times, including on the device, and to watch its CloudWatch metrics and logs for misuse.

Azure: the Device Provisioning Service

On Azure, the IoT Hub Device Provisioning Service (DPS) sits in front of your IoT hubs. Microsoft describes the flow in its overview: the manufacturer preconfigures each device with its credentials and the DPS endpoint, and you add enrollments that list the valid devices. When a device powers on for the first time, it connects to DPS, which checks it against the enrollment list. DPS then assigns the device to a hub and registers it there, after which the device connects to that hub directly.

Microsoft's DPS concepts page explains the two kinds of enrollment:

• Enrollment groups for devices that share an attestation mechanism: X.509 certificates signed by the same CA, or symmetric keys derived from a group key. Microsoft recommends them for large numbers of devices with the same initial configuration.
• Individual enrollments for single devices, using an X.509 certificate or a TPM. Microsoft recommends them for devices that need a unique initial configuration, or that can only use TPM attestation.

DPS also decides which hub each device goes to. The allocation policies are evenly weighted distribution (the default), lowest latency, a static hub set in the enrollment, or your own logic in an Azure Function. That lets you spread devices across regions or send each customer's devices to their own hub, without hard-coding a hub address at the factory.

Matter: commissioning in the home

Smart-home devices built on Matter, the Connectivity Standards Alliance standard, follow a defined setup process called commissioning. Google's Matter primer describes it as "the process of assigning Fabric credentials to a new device". A commissioner, such as a phone or hub, does the work in stages:

1. The new device advertises itself and provides an onboarding payload. The commissioner uses the passcode in that payload to open a secure session (PASE).
2. The commissioner reads the device's details: vendor ID, product ID, product name and serial number.
3. It checks the device's attestation certificate to confirm it is a genuine, certified Matter product.
4. The device creates its own operational key pair and returns a CSR. The commissioner installs a root certificate and a Node Operational Certificate on it.
5. For Wi-Fi or Thread devices, the commissioner gives it the network details. It then finds the device on the network, opens a certificate-based session (CASE) and completes commissioning.

A fail-safe timer runs throughout, so a failed setup rolls the device back to its original state.

The factory side matters here too. Google's attestation primer says the Device Attestation Certificate "is unique per device" and is issued by a CA associated with the manufacturer. The chain leads up to authorities whose certificates are kept in a central trusted database, the Distributed Compliance Ledger. So a Matter product needs per-unit attestation credentials loaded in production and has to pass certification through the Alliance.

What to decide before production

• Credential type and where it lives: X.509, TPM or symmetric key, and whether a secure chip stores it.
• Who loads it: your factory, the chip vendor, or the device itself on first connection by claim.
• The first-connection route: AWS JITP, claim or trusted user; Azure DPS individual or group enrollment; Matter commissioning; or a mix.
• How a device is tied to its owner: through a signed-in app at setup, or through sales data, which Microsoft lists as one DPS use case.
• How a device is blocked or replaced: what happens when a unit is stolen, resold, factory-reset or swapped under warranty.
• How credentials are renewed over the product's life, alongside your firmware update plan.

Test the whole path with real units from a pilot production run, not just development boards. Mistakes here show up in the factory or at first setup, where they are hardest to fix.

Frequently asked questions

What is IoT device provisioning?

It is getting a device from the factory to a working, trusted connection: giving it its own credentials, registering it in your cloud and applying its configuration. Microsoft describes it as registering the device and then configuring it for the solution it joined.

Can every device ship with the same certificate?

AWS allows a shared claim certificate that each device exchanges for its own certificate on first connection, but warns this carries a larger risk if the claim certificate leaks. Each device should end up with its own credential.

What is the difference between AWS fleet provisioning and Azure DPS?

Both register devices automatically on first connection. AWS fleet provisioning swaps a claim certificate for a unique one and creates the device's resources from a template. Azure DPS checks the device against an enrollment list and assigns it to one of your IoT hubs.

Does a Matter device still need provisioning?

Yes. Each Matter device carries a unique Device Attestation Certificate from production, and during commissioning the phone or hub checks it, installs operational credentials and gives the device its network details.

Planning a connected product and want the factory, cloud and app sides designed together? See our IoT development service and all our services, or email [email protected].