Designing OTA Firmware Updates for a Lifetime of Reliability

OTA firmware update capability is table stakes for today’s consumer IoT devices: It’s central to the promise that a device will remain smart and safe after it leaves the shelf. Because consumer IoT devices are usually deployed on home networks with weak segmentation, OTA updates are the best (and often, only) way short of a recall to fix critical security vulnerabilities.

They’re also critical to maintaining compatibility with evolving connectivity standards (e.g., Matter, Bluetooth, and Wi-Fi). In the era of the EU Cyber Resilience Act and the U.S. Cyber Trust Mark, OTA updates are a requirement.

In addition to all of the factors that can lead to mandatory updates of firmware on deployed devices, OTA updates allow brands to fix issues, add product features, improve product behavior, and enhance their customers’ experience. In the world of social media, any customer with an online following can influence the reputation of a device or brand.

The aggregate of online reviews and ratings, even for older models no longer being manufactured, directly affects a brand’s sales. The ability to upgrade devices well into their deployed lifecycle enables a tangible response to changes in customer sentiment.

Building a reliable OTA update process is crucial: A failed update that bricks the device is worse than no update at all. Decisions made during the product design phase can make or break the update cycle, reverberating throughout the product lifecycle. In managing OTA updates across over 60 smart-home brands, here are Ayla’s best practices to ensure robust and secure firmware updates for an IoT fleet.

OTA Infrastructure

Design for failure — everything else flows from this principle. Every firmware update encounters some issues, often entirely out of the device manufacturer’s control: lost connectivity, power outages or surges, dense network traffic. The following design phase recommendations will help ensure that setbacks don’t become catastrophes.

• Headroom: Future SDK, certificate, or security updates may require more memory or larger keys. Design your firmware with headroom and RAM and storage to accommodate these eventualities.
• Partition schemes: A firmware update should not risk interrupting device operations or bricking the device. A dual-partition scheme allows you to roll back to the previous firmware version if anything goes wrong.
• Delta firmware images: Firmware updates can be several megabytes, but many smart-home devices operate on bandwidth-constrained protocols. For these devices, applying a full firmware image is unreliable and frequently infeasible. The device agent should instead be designed to apply delta firmware images, with sufficient memory headroom to apply them.
• Failure state reporting: Similarly, if power is lost or network connectivity interrupted during the firmware update download, the device firmware should either recognize the failure and resume the download when it can or notify failure to the cloud service providing the image so that the upgrade operation can be retried.
• Device agent configuration: For any connected product line, multiple hardware revisions, firmware versions, and chipset variants exist in the field. The device agent must be designed to confirm successful updates and regularly report firmware version states. That way, the IoT platform can identify failed updates and unreachable devices.
• Digital signatures appended to upgrade images ensure only updates from authorized parties are accepted and run on devices. These signatures should use standard algorithms, generated from a hash of the update image and a private key with very restricted access. A corresponding public key is loaded onto the device during manufacturing and used to validate the signature before applying it.

None of these design features can be reverse engineered: Every connected device should be designed for a lifetime of OTA updates (Fig. 1).