How to Plan Secure OTA Firmware Updates for a Connected Product?

Most connected products ship with bugs that they don’t yet know about. What decides the cost of fixing them is whether you can reach the device once it’s deployed. For manufacturers with thousands of units in the field, over-the-air (OTA) firmware updates are now a core part of the product architecture, not an optional feature.

This guide covers how OTA updates compare with traditional methods, what to plan before your first rollout, and where an IoT platform can help.

What are OTA firmware updates?

An OTA firmware update delivers new software to a deployed device over its existing network connection (Wi-Fi, cellular, LoRaWAN, or BLE through a gateway) instead of through a cable or a site visit. The device downloads the new image, verifies it, installs it, and reports back.

Good OTA starts in the firmware: the bootloader, partition layout, and verification logic all have to be designed for updates from day one.

An example: one vulnerability, 2,000 devices

Imagine a manufacturer with 2,000 cold-chain temperature sensors installed across 120 warehouses in three countries. A security researcher reports a flaw in the TLS library the firmware uses. (The numbers are illustrative.)

Without OTA: The team prepares a patched build, then schedules technician visits. Each visit needs travel, site access, and a laptop-and-cable flashing procedure. At 15 devices per visit, that’s roughly 130 visits. The fleet stays exposed for weeks, and some units are never reached.

With OTA: The team signs the patched build and pushes it to a pilot group of about 20 devices. They watch for failed installs and reboot loops, then expand to 10%, then to the full fleet. Devices that are offline pick up the update when they reconnect. The whole process takes days, and the dashboard shows which devices run which version.

Traditional updates vs OTA updates

Pros and cons of OTA

Advantages

• Faster security patches and bug fixes
• Lower long-term service costs
• New features after sale, which extends product life
• Fleet-wide version visibility
• Helps meet growing regulatory expectations for security updates, such as the EU Cyber Resilience Act and the UK PSTI regime

Limitations

• OTA is a new attack surface if it isn’t designed securely
• A faulty release can reach every device quickly
• Constrained devices need enough flash memory for a second image
• Battery-powered and low-bandwidth devices need careful scheduling
• Upfront engineering work in the bootloader and backend

Six checkpoints for a secure OTA plan

1. Sign every firmware image. The device should only accept images signed with your private key, verified against a public key stored on the device. Keep the signing key in a hardware security module or an equivalent protected system, never on a developer laptop.
2. Verify before you boot. Use secure boot so the bootloader checks the image’s integrity and authenticity at every startup, not just at download time.
3. Encrypt the channel. Deliver updates over TLS or an equivalent encrypted transport with authenticated devices, so images can’t be intercepted or swapped.
4. Design for failure. Use a dual-partition (A/B) layout or similar fallback, so a power cut mid-update, or a build that fails to boot, rolls back to the last working version automatically.
5. Roll out in stages. Start with a small pilot group, monitor, then widen. Define in advance what counts as a failure signal (install failures, reboot rates, missing telemetry) and who has the authority to halt the rollout.
6. Track versions and prevent downgrades. Know exactly which firmware each device runs, and block rollback to versions with known vulnerabilities (anti-rollback protection).

Plan the operational side too: update windows for battery devices, data limits on cellular plans, and communication for customers whose devices will restart. These points matter most for large fleets, such as IoT asset tracking deployments, where devices are spread across many sites and connection types.

OTA is a downlink, and downlink can do more

An OTA update is a downlink message: data travelling from the cloud to the device. The same channel can carry commands, such as switching a relay on or off when a sensor value crosses a threshold. For example, a platform might turn on a pump when soil moisture drops below a set level.

Two cautions apply. First, commands should be authenticated and acknowledged by the device, just like firmware. Second, safety-critical logic should run locally on the device, with the cloud supplying configuration and overrides. That way, a lost connection can’t leave equipment in an unsafe state.

Where an IoT platform fits

You can build OTA infrastructure yourself, and many teams do. The trade-off is that signing, rollout control, device tracking, and monitoring all become software you maintain. Some manufacturers prefer a platform that already covers the device-management side. This is a common theme in IoT strategy for sensor manufacturers, where the goal is to offer complete connected solutions, not just hardware.

SensorVision, our white-label IoT platform, is one example. It includes:

• OTA firmware updates pushed to deployed devices remotely
• Downlink commands to trigger relays, change settings, or control hardware from the dashboard
• Threshold-based alerts that fire when a sensor metric crosses a defined limit
• Device management with live connection status, last-seen time, and telemetry history
• Protocol support for MQTT (via VerneMQ), HTTP/REST, and UDP, working with ESP32, LoRaWAN, and BLE-based hardware
• Multi-tenant architecture with role-based access, so integrators and manufacturers can keep clients separate
• White-label branding and cloud or on-premises deployment

Whichever route you choose, test any platform against the six checkpoints above. Ask specifically how signing, staged rollout, rollback, and version tracking are handled.

Key takeaways

• Plan OTA before launch. Retrofitting it into shipped hardware is far harder.
• Signing, secure boot, and rollback protection matter more than download speed.
• Staged rollouts limit the damage of a bad release.
• Downlink commands share the same trust model as updates, so secure them the same way.
• Whether you build or buy, evaluate against the same checklist.