Updating firmware over LoRaWAN without trusting the network

The Cyber Resilience Act requires that a product can be fixed after it is placed on the market, and that the manufacturer distributes its updates securely. On a server, that is an HTTPS download. On a LoRaWAN sensor sitting on top of a pole for ten years, receiving a few dozen bytes per frame and almost never listening, it is a different trade.

We made it the sixth episode of CRA & Dev, our freely accessible technical wiki: A thousand fragments, one signature: updating firmware over LoRaWAN.

What you will find there

The idea fits in one sentence: the network carries, the bootloader decides.

• Transport: the three LoRa Alliance FUOTA building blocks (clock sync, multicast, redundant fragments), and what they cost in airtime before you write a single line of code.
• Trust: why the LoRaWAN group key does not authenticate firmware, and how an image signed and verified by MCUboot at boot settles the question, whatever path it took.
• Planned failure: an image booted on trial, confirmed only once it has proven itself, otherwise replaced by the previous one; and old vulnerable versions refused.

Everything is checked on a real bench, two Heltec boards (ESP32, SX1276 radio) running Zephyr: a forged image, an image with one flipped bit, an older version and an update unable to join the network are all refused or rolled back. The full firmware and the end-to-end simulation are in the repository, under an open licence.

Who it is for

Teams shipping a LoRaWAN sensor, gateway or device that must stay fixable for its whole lifetime. It is also a good starting point for any update over a constrained link: separating transport from trust applies just as well to NB-IoT, Bluetooth or a serial line.

If the question is no longer “how” but “what to do for our product, and in which order”, that is what our CRA compliance service is for.

➡️ Check whether your product is in scope: 3 minutes, no email required