What an over-the-air update is
An over-the-air (OTA) update delivers new software to a device through a wireless or network connection, with no cable and no visit from a technician. The software may be the device’s firmware, which is the low-level program stored on the device and controls its hardware, or a smaller piece such as an application, a configuration file or a set of security certificates. Phones are the familiar example, and connected sensors, thermostats and vehicles increasingly work the same way.
OTA matters because devices are often hard to reach. A sensor on a pole, in a field or inside a wall cannot practically be collected for a software fix. And since flaws are inevitably found after products ship, the ability to repair them remotely is a major reason why the topic keeps coming up in security guidance on firmware updates.
Why updates are needed
- Security fixes. Weaknesses are discovered over time. Without updates, they remain, which contributes to the device vulnerabilities seen in the wild.
- Bug fixes. Problems with connectivity, power use or data handling can be corrected.
- New features and improved behavior.
- Compatibility. Networks, services and standards change, and devices may need to follow.
- Credential changes. Certificates and keys have lifetimes and need replacing.
Whether and for how long a maker supports a product with updates is also a consumer concern, touched on in the discussion of long-term device support and right to repair.
How an update travels
The details vary, but the typical stages are:
- Publishing. The maker builds a new software version and uploads it to an update service, often with a description of which devices it applies to.
- Notification or check. Devices either learn that an update exists (a message is pushed to them) or ask periodically whether one is available. Polling is simple and works through firewalls, though it takes the device some energy.
- Download. The device fetches the update file. Large files may be split into chunks, so that an interrupted download can resume rather than start again. Some systems send only the difference between the old and new versions, called a delta update, to save bandwidth. This is especially valuable on slow, metered links such as low-power networks or cellular IoT.
- Verification. Before installing anything, the device checks the package (see the next section).
- Installation. The new software is written to storage and the device restarts into it.
- Confirmation. The device checks that it started properly and reports the result to the update service.
Some devices cannot be reached directly and are updated through a nearby intermediary. A gateway may download the file and pass it along to simpler devices on a local radio network. This works but adds another step where things can go wrong.
Making sure the update is genuine
Accepting software from the network without checks would be dangerous: an attacker could install their own code. The usual protection is a digital signature. The maker signs the update with a private key that they keep secret. The device holds the matching public key and checks the signature before accepting the file. If anything was altered, or the update came from someone else, the check fails and the update is refused. A device should also check that the update is meant for its hardware model and is not an older version being forced onto it, since replaying an old release with known flaws is itself an attack. Encrypting the connection protects the file in transit, but the signature is what proves where it came from.
Protecting the signing key is therefore critical. It is generally a task for tightly controlled processes, not for ordinary developer computers.
Installing safely: the problem of half-finished updates
The most feared failure is a device that loses power or connection in the middle of installing and ends up unable to start, sometimes called “bricked.” Common protections include:
- Two software slots (A/B). The device keeps two copies of its software. The update is written to the inactive slot while the device keeps running from the active one. Only after the new copy is fully written and verified does the device switch over. If the new version fails to start, it can switch back.
- A protected bootloader. A small, rarely changed piece of code that starts the device and decides which version to run. It stays intact even if the main software is damaged.
- Watchdogs and health checks. After an update, the device must prove it is working, for instance by connecting to the service within a set time. If it does not, it reverts automatically.
- Power and storage checks. The device may refuse to begin an update when its battery is low or storage is insufficient. Battery devices need to budget the energy an update takes, which is one more factor in battery life.
Not all devices can afford two software copies, because small chips have limited storage. In those cases, designers use other techniques, and the risk is higher.
Rollback
Rollback means going back to the previous working version. It can happen on the device itself, as described above, or be triggered centrally if problems appear after release. A rollback plan should be in place before an update is sent, including what happens to data or settings that the new version changed. Some updates alter stored data formats, which can make a clean rollback harder, so this deserves thought during design.
Rolling out gradually
Updating every device at once is risky. A common practice is a staged rollout: release to a small group, watch for errors, expand to a larger group, and continue only if things look healthy. Monitoring of crash rates, reconnection and battery drain during the rollout can catch problems early. A control to pause or halt the rollout is just as important as the ability to start it. These habits belong to the broader practice of managing fleets of connected devices.
Practical cautions
- Test updates on real hardware, including with interrupted power and poor connections.
- Keep updates small and infrequent enough to be manageable, but do not postpone important security fixes.
- Tell users what is changing and when, where devices are in homes or workplaces.
- Plan for devices that never update because they stay offline, and decide how long old versions will be tolerated.
Done carefully, OTA updates are one of the most valuable features of a connected product. Done carelessly, they can become a risk of their own, so verification, safe installation and the ability to recover are the key elements.