An opened LoRaWAN sensor, a few connections to its circuit board, and access to information that should be secret. Trend Micro’s 2021 hardware study describes how an unprotected UART interface can make it possible to extract secrets from a sensor. It also examines how programming interfaces, memory protection and the storage of cryptographic keys affect security. The attacks require physical access, which matters when sensors are installed in public or unattended places.
That should influence how we buy and manage connected products.
We readily discuss encryption, range and ten-year battery life. But how well are the keys behind that encryption protected? And what happens if a weakness is discovered after a thousand sensors have already been installed at the customer’s sites?
For me, that is where the security discussion becomes interesting. It continues long after someone selected “encrypted communication” in the procurement requirements.
When physical access puts keys at risk
A programming interface is often needed during development and manufacturing. It may also be needed for servicing. But the ability to program a device, read its memory and access its keys must be treated as separate permissions. A legitimate service function should not automatically provide unrestricted access to a device’s secrets.
For example, Dragino documents firmware updates for several STM32-based products using UART or ST-Link. The documentation shows which service routes exist. It does not, by itself, prove a vulnerability. It does, however, give us reason to ask how the interfaces and memory are protected in the products being delivered.
Those are the questions I want answered with test results for the correct hardware revision. The presence of debug connections on a circuit board tells us too little. What matters is what an unauthorised person can actually do through them.
The question remains relevant, as Milesight’s 2026 security advisory shows. The manufacturer describes how unauthorised NFC access to certain sensor models and firmware versions can expose LoRaWAN session keys used with ABP, as well as keys for Milesight’s D2D communication. The attack requires physical proximity. Depending on how the devices are used, the consequences may include reading traffic, falsifying data or sending unauthorised D2D commands. Milesight states that devices operating in OTAA mode are not affected by this particular vulnerability.
A patch cannot make copied keys secret again
We need to keep two questions in mind at the same time: how do we close the weakness, and how do we restore trust in a device whose keys may have been exposed?
A firmware update can close an access route. It cannot make keys that have already been copied secret again. The response may therefore need to include new keys, changed configuration and a check of which devices should still be trusted. Some hardware weaknesses may also require physical intervention or replacement.
FUOTA has to work in the customer’s environment
That is why FUOTA belongs in the discussion about security maintenance. Firmware Update Over-the-Air can let us deliver fixes to installed devices without visiting every site. But the feature must be supported by the specific product and work with the infrastructure the customer uses.
Seeing LoRaWAN on a datasheet does not automatically mean the product supports FUOTA. The LoRa Alliance’s technical recommendation on FUOTA describes the mechanisms and steps involved in delivering firmware to end devices. The update itself must also be verified and installed securely.
OTA may still require work on site
Even the term OTA calls for follow-up questions. Dragino describes a wireless update method for the LHT65N/S and several other models. It uses a private LoRa protocol and an LA66 adapter connected to a computer or phone. The documented workflow also involves resetting the device or pressing a button on it. This is a useful service function, but the documentation does not show that a customer can distribute security updates centrally through an existing LoRaWAN network.
That distinction has practical consequences. I want to know whether the operations team can initiate an update, which devices it can reach and how we verify that installation succeeded. I also want to know what happens if power fails, a transfer is interrupted or the firmware file is wrong.
An update function that has never been tested in the customer’s environment is a shaky foundation for a security commitment lasting several years.
When every update requires a visit
Then there are products that have to be updated locally. Milesight, for example, documents updating the AM300 series through the ToolBox app or USB, while AM307 is listed without OTA support in the Milesight Development Platform. The latter describes the platform’s support for the model; it is not, by itself, a test of every conceivable update method.
USB is valuable for servicing and recovery. But when the practical response requires a visit to every sensor, someone has to plan, staff and pay for that work.
Take a thousand sensors and, purely as an example, fifteen minutes of work per device. That is 250 working hours before travel, access to premises or repeat visits have been counted. Meanwhile, the customer still has to manage the risk posed by devices that have not yet been fixed.
That cost should be visible at the purchasing stage. Long battery life tells us nothing about how much manual security maintenance the product will require.
What do a thousand home visits cost?
So what does a security update requiring home visits actually cost?
Suppose a property owner has a thousand sensors in a thousand apartments. Every update requires notifying residents, gaining access, doing the work on site and documenting the result. At one hour of total work per apartment, a labour cost of €65 per hour and €15 for a vehicle and parking, a single round of updates comes to €80,000.
The firmware transfer itself might take only a few minutes. The visit still costs money.
Three such rounds of updates over ten years add €240,000 in extra costs. Five rounds add €400,000. That is €400 per sensor, on top of purchase, installation and normal operation. These are illustrative figures in today’s money. Coordinating visits with other work reduces the cost, while failed access attempts and return visits increase it.
That puts the purchase price in a different light. A sensor with working remote updates that costs €30 more adds €30,000 to the initial cost of a thousand devices. In this example, avoiding just one round of home visits could cover that entire price difference and leave €50,000 for the work and infrastructure needed to update remotely.
I think that calculation belongs on the table when products are compared.
A security fix that needs a budget of nearly €100.000 may also have to wait for approval, staff and access to the premises. The problem remains in the meantime. The ability to update therefore affects both the total cost of ownership and how quickly a property owner can act when a vulnerability is discovered.
Ten-year battery life is attractive. But if the sensor needs five additional home visits over the same period, those visits also belong in the sales calculation.
Who can deliver the security fix?
Even the best update function depends on someone discovering the problem, analysing it and developing a fix.
That makes dependence on the manufacturer central. When importing from China, the development team, build environment, signing keys and knowledge of the product’s internal components may all sit with a company far from the Swedish customer. The importer therefore needs to assess the manufacturer’s actual ability to monitor vulnerabilities, respond to reports and maintain older products.
Country of manufacture is not a test result. But the supplier’s jurisdiction, visibility into the development process and the ability to enforce agreements are relevant parts of the risk assessment. A Swedish brand name on an invoice does not automatically move technical control to Sweden.
The CRA and the ability to act
The Cyber Resilience Act makes that question more concrete. According to the European Commission’s guidance on reporting obligations, since 11 September 2026 manufacturers have had to report actively exploited vulnerabilities and severe security incidents affecting their products when they become aware of them. Most of the regulation’s other requirements start to apply on 11 December 2027. These are separate stages, and discovering any bug does not automatically trigger a reporting duty.
Manufacturers have central obligations, while importers and distributors have obligations of their own according to their roles. The requirements also cover products from manufacturers outside the EU when those products are placed on the EU market. Compliance is therefore not optional. The European Commission’s summary of the CRA explains how the responsibilities are divided.
My concern is the gap between legal responsibility and the technical ability to act.
If a manufacturer stops responding, the importer does not suddenly gain access to a working build environment or the ability to create signed security updates. Stopping further sales does not automatically help customers who have already installed the products, either.
Show how a security issue is actually handled
That is why I want more than a promise to “comply with the CRA”. I want to see how the supplier has handled previous security issues: how quickly reports were answered, how affected versions were identified, how fixes were distributed and how customers were informed. I also want to know when maintenance ends and what we can do if the supplier disappears.
A published vulnerability can be a sign that someone is examining the product and that the manufacturer is handling findings openly. An empty list of security issues may just as easily mean that nobody has looked closely enough. Milesight publishes information about vulnerabilities and planned fixes. Dragino openly documents how several of its products can be updated. I consider that good IoT hygiene, provided we also check what can actually be done with the model and firmware version the customer uses.
Those of us who sell, integrate and recommend IoT products need to be able to have that conversation about our own suppliers as well. Customers need to know the limitations that come with a product and what a future fix might involve.
I want the next sensor procurement to include a demonstration of how a security issue is actually handled. Start with an identified device and affected firmware, then show the installed fix, any necessary key replacement and a verified result.
Because on the day someone can read the keys from a sensor, knowing who sold it is not enough. We need to know who can restore its security – and how.