There is a familiar pattern in IoT procurement. We spend a lot of time comparing devices, connectivity, features and price, then gradually assume that the important decisions have been made.
They haven’t.
A connected device is rarely just a device. It is a long-term commitment to a particular hardware design, firmware, supplier and way of maintaining an installed fleet. The consequences of choosing the wrong product often don’t appear when the purchase order is signed. They appear a few years later, when something needs to be fixed.
Security is a good example.
While preparing for a session at IoT-dagen I recently looked more closely at what can happen when a LoRaWAN sensor exposes interfaces that provide access to memory or other sensitive information. A Trend Micro study showed how an unprotected UART interface can potentially be used to extract secrets from a Dragino sensor. More recently, vulnerabilities involving physical access and exposed keys have shown that this is not merely a theoretical discussion.
I go into the technical details in this article
What interests me beyond the vulnerability itself is what happens afterwards. A firmware update may close the vulnerability, but it cannot make a key secret again if that key has already been copied. Depending on the incident, restoring trust can require new keys, new configuration or even replacement of hardware.
That is where the original purchase decision suddenly becomes much more relevant.
Does OTA really mean OTA?
Firmware updates are often presented as an obvious answer. And they can be. A well-designed FUOTA process can make a huge difference when you have thousands of connected devices in the field.
But “supports firmware updates” is not enough information for me.
Can the customer actually update the installed fleet remotely? Can updates be initiated centrally and verified afterwards? What happens when a device is offline or an update is interrupted? And is this a capability of the actual product and firmware version, or simply a feature described somewhere in the manufacturer’s documentation?
Those distinctions matter.
A service procedure that requires an adapter, an application and physical access to the device may be perfectly reasonable for a technician working on one sensor. It becomes something quite different when the same procedure has to be repeated across 1,000 installations.
That is when the cost of a security update starts looking very different from the cost of the firmware itself.
The expensive part may be the visit
Take a property owner with 1,000 sensors installed in 1,000 apartments.
If every update requires notifying residents, arranging access, travelling to the apartment, doing the work and documenting the result, even a relatively modest cost per visit quickly adds up. At €65 per hour for labour and €15 for vehicle and parking, one hour per apartment means €80,000 for a single update round.
Three such rounds would mean €240,000. Five would be €400,000. These are illustrative figures, but they make the point: the economics of an IoT product do not stop at the purchase price.
A sensor that costs €30 more but can genuinely be maintained remotely adds €30,000 to a fleet of 1,000 units.
Avoiding one round of manual visits could more than pay for that difference.
This is why I think maintainability deserves to be treated as part of the product specification, rather than something to consider after deployment.
You are also choosing a supplier
The same applies to the manufacturer. When you buy an IoT product, you are implicitly depending on somebody to keep that product secure for years. Who develops the firmware? Who can produce a signed update? Who handles vulnerability reports? How long will the product actually be maintained?
A local distributor or a European brand does not necessarily mean that those capabilities are local. The organisation selling the product may be very different from the organisation that can actually modify the firmware or manufacture a new release. That does not make a product insecure, and country of manufacture is certainly not a security test. But it is a dependency worth understanding before a product becomes embedded in an installation that is expected to run for ten years.
The Cyber Resilience Act makes some of these responsibilities more explicit, but regulation cannot create engineering capability where it does not exist. A supplier still needs the people, knowledge and technical control required to respond when something goes wrong.
The wrong choice gets expensive later
This is perhaps the broader lesson. In IoT, the cheapest product at the time of purchase is not necessarily the cheapest product to own. Nor is the product with the longest battery life necessarily the one with the longest useful life. If maintaining security requires repeated physical intervention, the labour may ultimately cost much more than the hardware ever did.
That is why I increasingly want to know less about what a supplier says the device can do, and more about what happens when something goes wrong.
How is a security issue handled? How are affected devices identified? How are they updated? Can credentials be replaced? What happens when a device cannot be reached remotely? And what happens when the product is five or eight years old?
Those questions may not make a product look better in a spreadsheet.
They may, however, keep a seemingly inexpensive IoT deployment from becoming a very expensive one later.
The wrong product can be difficult to replace.
The wrong supplier can be even harder.