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).

In addition, it’s crucial to choose a platform provider with a full-featured and robust over-the-air upgrade capability. They should support managed firmware upgrades at scale, with fine-grained device selection, staggered update deployments, and clear success/failure reporting. If brands need to deploy updates across all devices of different models, they must be able to monitor progress and verify successful completion.

Retain Firmware Development Capability

Ayla executes over 2,500 each year across more than 15 million connected devices and seven instances across its customer footprint. If, however, a brand is fortunate (or the engineers behind a device are especially talented), it may be years before a firmware update is needed. That’s both a blessing and a curse: The expertise and ability to build a new firmware release can be lost over time unless steps are taken to preserve it.

Company reporting structures can change, leaving support ownership of products unclear. Subject matter experts may leave or transition to new roles in the company. If parts of firmware development were outsourced to external companies, they may be unwilling to support it years later. All of these factors can render a team or organization unable to build and test a new version of firmware for a product in the field.

On completion of any firmware release for a connected product, steps must be taken to archive the source material. Maintaining the firmware source code in a version control system is necessary, but far from sufficient. The engineering team should archive everything needed to build the product, potentially including:

• The system build environment, including OS version and packages
• Specific versions of toolchains for compiling to specific chip architectures
• makefiles or scripts for packaging, signing, and versioning the release
• IDEs used to modify code or automate parts of the development process
• Test plans and test scripts, and the environments needed to run them
• Access to online documentation, including user-facing information and internal build instructions

One way to help prepare for this activity is to use virtual machines (VMs) or containerized environments for development (Fig. 2). The entire container can then be archived, preserving all of the relevant versions of the toolchain, OS, and dependent software for later use.

Care must be taken that all external source code is fetched and included in the container before it’s archived. If the build process draws from external resources, those resources may not be accessible by the time a new firmware version is needed.

If development of device firmware was outsourced to a third party, that development environment should be preserved as well – either by the third party, as part of an ongoing support agreement, or transferred to your organization at the conclusion of the contract.

Building Robust OTA From the Beginning

OTA update capability is a lifecycle commitment made at the design table. A device without rollback, delta imaging, and signed images is in constant danger of a support crisis, and a team without an archived build environment is one departure or reorg away from being unable to ship a fix.

Both failure modes can lie dormant for years, making them easy to defer. As regulatory requirements from the EU Cyber Resilience Act and the U.S. Cyber Trust Mark push OTA capability from best practice to compliance obligation. And as customer expectations for post-purchase support continue to rise, design teams must shift to integrate robust OTA capabilities tightly into initial product design.

Design for failure. Preserve the ability to build. And choose a platform provider with staged rollouts, fine-grained device targeting, and clear success/failure reporting, so that individual incidents never cascade into fleet-wide disasters. Firmware updates are inevitable. These best practices will ensure deployed devices weather them smoothly.