Once your project involves multiple devices, the ability to manage configuration settings, credentials, and firmware updates at the device level becomes your greatest challenge. Unsurprisingly, many services provide an administration panel as well as a REST API for configuring and maintaining your Things.
On smaller projects, you might use the administration features to set everything up manually, registering each device in the admin panel, and then copying a device ID or private key to each device. Compare this to a commercial product, where you’d want users to be able to unbox their device and register it from your website. For this, you’d need to produce and deliver access credentials to the device in a more automated way, and then publish these access credentials to the service via its REST device configuration interface.
Once your devices are registered and connected, some services also provide a channel for remotely pushing configuration data to your devices. Usually, this is just a built-in way to push a developer-defined blob of data to the device, and it’s up to the developer to sort out the specific details of what the device does with it. It could be something as simple as updating configuration metadata, or as complicated as pushing over-the-air firmware updates. This kind of service-activity should not be taken lightly. Updating devices with pushed data is a massive security and operations risk. If your update procedure is hackable, your sensor network could be turned into a distributed botnet. If you make a mistake in deployment, every one of your devices turns into a brick.
This is an example of how over-the-air updates might happen: