How to Configure IoT Devices: A Step-by-Step Guide

Setting up one connected device on your desk takes ten minutes, maybe less. You plug it in, pair it with the app and move on. Do the same thing with 4,000 units scattered across warehouses and customer homes, each with its own quirks, and it’s a different story.

If you’re working out how to configure IoT devices for a product that’s already in the field, or about to be, start with one idea: configuration is data that lives in your backend, with a version number and a way to roll back. Most of this guide flows from there. We’ll go through the seven steps we use on client projects, from the identity a device gets on the production line to the day it’s retired, and then look at the configuration mistakes we run into most often.

What Configuring an IoT Device Actually Covers

A lot of teams file everything under “setup.” It’s worth pulling that apart, because the pieces don’t move at the same speed.

Provisioning is about identity: the device gets a unique ID and certificate and is registered in your backend, so it’s allowed to talk to your cloud. In most products that happens once. Firmware, the code itself, changes a few times a year and goes out as a signed binary after QA (we cover that side in our guide to updating device firmware from a mobile app).

Configuration is what this article is about. It’s everything the firmware reads at runtime to decide how to behave, like the reporting interval, alert thresholds, time zone, which sensors are on and which features the customer paid for. On some products it changes weekly, sometimes even hourly.

Where we see teams get burned is when configuration ends up baked into firmware. You want to move one temperature threshold? That’s now a full release and an over-the-air push to every unit in the field. Kept separate, it would have been a single write in the database.

How to Configure IoT Devices in 7 Steps

The first two steps happen before a single unit leaves the factory, which is exactly why they get dropped when a deadline gets tight. Fixing them later costs far more.

Step 1: Write the configuration schema before the first device ships

List every parameter the device can read, with its type, unit, allowed range and default value. Then put a version number on the whole thing. For example, the reporting interval is an integer in seconds, between 10 and 86,400, with 300 as the default.

It feels like paperwork, but this schema is the contract that firmware and mobile developers both code against. Without it, sooner or later the app sends "interval": "5m" while the firmware expects 300. The device keeps its old value without complaining, and nobody notices for weeks.

Firmware 2.1 will add parameters that firmware 1.8 has never heard of, and both versions will run side by side in your fleet for years, so leave the schema room to evolve. Have each device report the schema version it understands, so the backend never sends it something it can’t parse.

Step 2: Give every device its own identity at the factory

Each unit needs an identity that can’t be copied onto another unit, usually a serial number tied to a private key. Ideally that key is generated inside a secure element on the board and never leaves it. Shared credentials across a product line turn one compromised device into a problem for the whole fleet. For consumer products, ETSI EN 303 645 requires passwords to be unique per device or set by the user (provision 5.1-1). The broader picture is in our IoT security guide.

Injecting a key per unit on the production line can be too expensive at low volume. AWS IoT offers a middle path called provisioning by claim: devices ship with a claim certificate shared across the fleet and receive their own unique certificate the first time they connect. AWS’s own documentation flags the downside, which is that a compromised claim certificate exposes more than one device.

Step 3: Organize configuration in layers

In practice, the configuration a device runs is a stack rather than a single file: factory defaults at the bottom, then settings for a model or region, then a customer or site profile, with the end user’s own changes on top. For any given parameter, the device uses the highest layer that defines it.

This pays off the first time a client with a few hundred sensors over several sites asks to change an alert threshold everywhere except one building. You edit one profile instead of 250 devices. A “reset to defaults” button also stops being ambiguous, because you know exactly which layer it clears.

Step 4: Hand over network settings during first setup

On consumer and small-business products, getting the device onto a network usually goes through the mobile app over Bluetooth Low Energy: the phone passes the Wi-Fi credentials to the device, then confirms it reached the cloud. Until that’s done, nothing can be configured remotely. We’ve written a separate piece on the first connection between a device and its app, so we’ll keep it short here.

Industrial fleets often get their network settings at the factory or from an installer’s tool, since the person on site isn’t the one who owns the configuration. Either way, store network settings apart from everything else. A bad config push should never be able to knock a device offline, or you’ll be sending someone out in a truck.

Step 5: Push changes remotely with desired and reported state

The model we come back to on nearly every project, and the one that keeps a fleet manageable, stores two copies of each device’s configuration in the backend: the desired state, which is what you want the device to run, and the reported state, which the device sends back to say what it’s actually running. Wherever they differ, a change is still waiting to be applied.

[IMAGE À INSÉRER : iot-device-configuration-mobile-app.webp, 1600 px. Alt : Smartphone app used to configure IoT devices remotely. Title : Configuring IoT devices from a mobile app. Crédit : à confirmer. Supprimer ce paragraphe une fois l’image ajoutée.]

AWS IoT Device Shadow is built on this exact model and computes the difference for you as a delta. Azure IoT Hub does the same through the desired and reported properties of its device twins. You can also build it yourself over MQTT, with retained messages so a device that was offline for three days picks up the latest desired state when it reconnects. Whatever the tooling, wait for the device’s confirmation before you show a change as done.

Versioning every change helps too, so a device can ignore an older update that shows up late (it happens more than you’d think on flaky networks). And make updates idempotent: applying the same configuration twice shouldn’t do anything different from applying it once.

Step 6: Validate on the device and keep a way back

Check every change against the schema in the backend before it goes out, then check it again on the device before applying it. A value that passes in the cloud can still be wrong for one specific hardware revision.

Next, keep a last-known-good configuration on the device. If a new configuration leaves it unable to reach the cloud, or failing a basic health check within a set window, the device reverts by itself and reports what happened. That mechanism usually turns a bad push into a few automatic rollbacks and a note in the incident log.

On a large fleet, don’t push to everyone at once. We usually start with around 1% of devices and leave it for a day while we watch reported states and error rates before going wider.

Step 7: Track every change until the device is retired

Every configuration change should leave a trace showing who made it and on which devices, with a timestamp. When a client calls because their sensors stopped alerting last Tuesday, that log lets you answer in minutes.

Drift is the other thing to watch. When a device’s reported state stays out of line with its desired state for days, it usually points to a firmware bug or a unit stuck offline.

People tend to forget that retirement is a configuration step. Once a device leaves a customer’s hands, whether it’s resold or recycled, revoke its certificate and wipe the customer’s settings and Wi-Fi credentials, then mark it as retired in the backend. If nobody does this, the next owner will struggle to set it up, and there’s an open door in the meantime.

Where Fleet Configuration Breaks in Real Projects

When a connected product reaches us after launch, we tend to find the same handful of configuration problems.

The most frequent one: the mobile app is the only way to change a setting. That holds up until a customer with 80 devices asks for a bulk change. And if the app writes straight to the device over Bluetooth without telling the backend, the cloud record is wrong from that moment on. We’d make the app one client of the configuration system among others.

Then there’s the single giant JSON blob. All settings live in one document that’s sent whole on every change, so two people editing different settings at the same moment can overwrite each other. Splitting the configuration into groups (network, sampling, alerts, features) and versioning each group solves most of it.

Anything that runs on a schedule needs a reliable clock and the right time zone. Hardcode the zone at the factory and the 6 a.m. routine starts firing at the wrong hour after the first daylight saving change. We’d store the time zone as a configuration value and sync the clock at every connection.

Finally, the quiet failure. A device rejects a value because it’s out of range, writes the error to a local log and never mentions it to anyone. On the dashboard, the change looks applied. Rejections need to travel back to the backend just like confirmations do.

Should You Use a Managed IoT Platform or Build Your Own?

You don’t need to build the configuration layer from scratch. Still, this choice will stay with the product for years, so it’s worth weighing properly.

Option	How configuration works	Good fit	Watch out for
AWS IoT Device Shadow	JSON document with desired and reported state, plus a computed delta	Teams already on AWS	Business logic spread across several AWS services
Azure IoT Hub device twins	Desired and reported properties, plus tags to group devices	Microsoft-centric organizations, industrial clients	Costs tied to the IoT Hub tier and message volume
LwM2M (OMA SpecWorks)	Standard object model over CoAP, with a bootstrap server	Cellular devices on constrained networks	Smaller pool of developers who know it
Custom backend on MQTT	Your own schema and storage, retained messages for offline devices	Specific requirements, data residency, avoiding lock-in	Versioning and rollback are yours to build

Google retired Cloud IoT Core on August 16, 2023 and gave its customers a year to migrate, a good reminder that platforms can disappear. Whichever option you choose, keep the configuration schema and business rules in your own code so the platform underneath can be replaced.

For the other layers of the product, our walkthrough of the full architecture of an IoT application shows how they fit together.

What This Means for Your Mobile App

For most connected products, the app is the only place a person ever sees configuration, so it’s worth getting a few things right there.

The app should write to the desired state in the backend, then display the reported state as it comes back. A toggle that flips instantly while the device hasn’t confirmed anything misleads the user, and people notice. A short “applying” state followed by a clear confirmation or error message earns far more trust.

It also needs a plan for moments without cloud access, like a technician in a basement or a plant floor on a locked-down network. In those cases the app can talk to the device directly over Bluetooth and sync the change to the backend once it’s back online. The version numbers from step 5 are what let device and backend reconcile afterwards, without ending up with two sources of truth.

We ran into this on the companion app we built for ABB’s emergency lighting line, which manages dozens of BLE devices from a single interface. In commercial buildings full of RF noise, a stable connection is never a given, and the app has to cope with that every day.

An installer and an end customer don’t need to see the same settings. Hiding a calibration offset from someone who only wants to rename a sensor prevents a fair number of support calls.

This is daily work for our team in Montreal: native iOS and Android apps that talk to hardware. We also build the backend and APIs that keep thousands of devices in sync. You’ll find more on how we approach IoT projects on our industry page.

If your product is about to ship, or already struggling with configuration in the field, talk to our team about your fleet.

FAQ

What is the difference between provisioning and configuring an IoT device?

Provisioning gives a device its identity and its right to connect to your cloud, usually once. Configuration covers the runtime settings that tell it how to behave, and those can change many times over the device’s life.

How do you configure IoT devices remotely?

The backend stores a desired configuration for each device and pushes changes over MQTT or through a managed service such as AWS IoT Device Shadow or Azure IoT Hub device twins. Each device then reports back what it actually applied.

Can you configure an IoT device without internet access?

Yes. A mobile app can send settings directly over Bluetooth Low Energy or the local network. The change should sync to the backend once a connection is available, so the cloud record stays accurate.

How do you roll out a configuration change to thousands of devices safely?

Start with a small group, around 1% of the fleet, and watch reported states and errors before widening. Devices should also keep a last-known-good configuration and revert on their own if something breaks.