Over-the-Air (OTA) Updates: How to Design Firmware for Remote Upgrades
Connected products rarely remain unchanged after they leave the factory. Bugs appear, security vulnerabilities are discovered, features evolve, and device behaviour may need to change as products mature.
For IoT devices deployed across homes, businesses, industrial sites, or remote locations, physically accessing every device to install new firmware is often impractical.
That is where over-the-air (OTA) firmware updates become essential.
OTA updates allow manufacturers to remotely deliver new firmware to connected devices. However, adding OTA capability involves more than downloading a file and restarting the device. A reliable OTA architecture must authenticate updates, protect firmware integrity, survive interrupted downloads, recover from failed installations, and support large device fleets.
This guide explains how OTA firmware updates work and the key design decisions engineering teams should consider when building remote upgrade capability into an IoT product.
What Is an Over-the-Air (OTA) Firmware Update?
An over-the-air (OTA) firmware update is a method of remotely delivering and installing new firmware on a connected device without requiring physical access to the product.
The device typically connects to an update service through Wi-Fi, cellular, Ethernet, or another communication network. When an authorised update becomes available, the device downloads the firmware, verifies it, installs it, and restarts using the new version.
OTA updates allow manufacturers to:
Fix firmware bugs
Patch security vulnerabilities
Add or improve features
Update device configurations
Improve performance
Maintain products after deployment
For connected products expected to remain in service for years, OTA capability should generally be considered during the initial firmware and hardware architecture rather than added after the product has already been deployed.
How Do OTA Firmware Updates Work?
A typical OTA firmware update moves through several controlled stages.
1. Update Detection
The device determines that a new firmware version is available. This may happen through periodic checks, a cloud notification, an IoT device management platform, or another command-and-control mechanism.
The device should verify that the update applies to its specific hardware model, configuration, and current firmware version before proceeding.
2. Firmware Download
The new firmware image is transferred to the device. Depending on the system architecture, the update may be delivered using HTTPS, MQTT, or another secure communication mechanism.
Devices with intermittent connectivity should be designed to handle interrupted transfers rather than assuming that the complete image will arrive in one session.
3. Verification
Before installation, the device verifies the downloaded firmware. This can include checking its cryptographic signature, integrity, version, hardware compatibility, and other metadata.
Verification is critical because the device must distinguish legitimate manufacturer firmware from corrupted or unauthorised software.
4. Installation
After verification, the new firmware is written to the appropriate flash memory region.
The exact process depends on the device architecture. Some devices overwrite an existing application image, while more resilient systems maintain separate active and inactive firmware partitions.
5. Reboot and Validation
The device restarts using the new firmware. The system then verifies that the updated firmware boots correctly and reaches an expected operational state.
6. Confirmation or Rollback
If the update operates correctly, the new firmware is marked as valid. If booting or validation fails, a properly designed OTA system can return the device to a known working firmware version instead of leaving it unusable.
Why OTA Updates Should Be Designed Into the Product Early
OTA capability affects more than firmware and should be considered early in the IoT device development process.
It can influence the microcontroller, flash memory requirements, bootloader, security architecture, connectivity strategy, cloud infrastructure, power budget, and even manufacturing processes.
For example, an A/B firmware strategy requires enough non-volatile memory to hold both the current firmware and a new image during installation. A product designed with only enough flash memory for the original application may make reliable OTA updates significantly more difficult later.
Engineering teams should therefore consider several questions early:
How large could the firmware become?
Where will downloaded updates be stored?
What happens if power is lost during installation?
How will firmware authenticity be verified?
Can the device recover from a failed update?
How will different hardware revisions be managed?
How will update status be monitored?
How long is the product expected to remain supported?
Treating OTA as part of the system architecture makes these requirements easier to accommodate before hardware reaches production.
Key Components of an OTA Firmware Architecture
A reliable OTA system requires cooperation between the device firmware, bootloader, connectivity layer, backend infrastructure, and deployment tools.
Bootloader
The bootloader executes before the main application firmware and plays a central role in the update process.
Depending on the architecture, it may:
Identify available firmware images
Verify firmware authenticity
Select which image to boot
Detect failed boot attempts
Activate new firmware
Restore a previous working image
Because the bootloader controls which firmware executes, its design is an important part of embedded firmware development and the device's security architecture.
Firmware Partitions
The device needs somewhere to store incoming firmware. A common approach is an A/B or dual-bank architecture.
One partition contains the currently running firmware while another receives the new version. After the new image has been verified, the bootloader switches to it.
If the new firmware fails, the system can return to the previous image. This requires additional flash memory, but it significantly improves recovery capability.
Update Manifest
An OTA package may include metadata describing the update rather than only the firmware binary. The manifest can identify information such as:
Firmware version
Target device model
Hardware revision
File size
Cryptographic hash
Signature
Minimum compatible version
Installation requirements
This helps devices determine whether an update is valid and appropriate before attempting installation.
Cloud or Device Management Platform
The backend manages firmware releases and determines which devices should receive them. For larger fleets, the system should provide visibility into update states such as downloaded, installed, successful, failed, pending, or rolled back.
How Do You Make OTA Firmware Updates Secure?
Secure OTA updates require the device to verify that firmware is authentic, unmodified, compatible, and authorised before executing it.
Encryption protects update data while it travels across a network, but encrypted transport alone does not establish that a firmware image should be trusted.
Digitally Sign Firmware
Firmware images should be cryptographically signed during the release process. The device verifies the signature using a trusted public key before accepting the image. If verification fails, the firmware should not be installed.
This protects against unauthorised or modified firmware being introduced into the device update process. AWS likewise recommends applying and verifying digital signatures on distributed firmware artifacts.
Use Secure Communication
Firmware should be transferred using appropriately secured communication channels. This protects update traffic against interception and manipulation while in transit.
Validate Firmware Versions
The device should verify that the firmware version is valid for its hardware and update path. Version controls can also prevent an attacker from deliberately installing an older firmware version containing a known vulnerability. AWS specifically recommends version checking alongside code signing and multiple non-volatile storage partitions.
Protect Signing Keys
Firmware signing is only trustworthy if the private signing keys remain protected. Production signing credentials should be carefully controlled and separated from normal development workflows.
How Should Firmware Handle a Failed OTA Update?
An OTA update system should assume that downloads, installations, or new firmware can fail and provide a path back to a known working state. Failures can happen because of interrupted connectivity, corrupted downloads, unexpected resets, low battery conditions, incompatible firmware, or software defects.
Use A/B Firmware Partitions
With an A/B architecture, the existing working firmware remains available while the new image is installed in a separate partition. The bootloader switches to the new image only when appropriate.
Validate After Reboot
Successfully downloading firmware does not prove that it works. After rebooting, the device can perform health checks before permanently confirming the new firmware.
If the device repeatedly crashes, fails a watchdog check, or cannot reach an expected operating state, the bootloader can restore the previous image.
Maintain a Known-Good Image
Keeping a known-good firmware image gives the system a recovery path if an update cannot run. AWS recommends controlled, reversible OTA updates and specifically identifies fallback firmware and multiple storage partitions as reliability practices.
The goal is simple: a failed firmware update should not turn a remotely deployed device into a product that requires physical recovery.
How Should OTA Updates Be Deployed Across an IoT Fleet?
Sending new firmware to every device simultaneously creates unnecessary risk. A defect that affects one test device is inconvenient. The same defect deployed simultaneously across thousands of devices can become a major operational problem.
A safer approach is a staged OTA rollout.
For example, deployment might progress through:
Internal devices → test fleet → small production group → larger groups → full fleet
After each stage, the engineering team monitors device health, update success rates, connectivity, crashes, battery behaviour, and other relevant metrics.
If abnormal behaviour appears, deployment can be stopped before the update reaches the rest of the fleet.
Both AWS and Microsoft recommend controlled deployment and rollback strategies for remote device updates.
Fleet segmentation can also account for:
Device model
Hardware revision
Geographic region
Customer group
Current firmware version
Connectivity type
Product configuration
This prevents firmware intended for one device configuration from being distributed indiscriminately.
What About OTA Updates on Battery-Powered or Low-Bandwidth Devices?
OTA updates can be more challenging on devices with limited power, storage, memory, or network bandwidth.
Downloading a large firmware image consumes energy and network resources. On battery-powered devices, the update strategy may need to consider battery level, charging state, network quality, and when the device is normally awake.
Low-bandwidth networks such as LoRaWAN and NB-IoT introduce additional constraints because transferring a complete firmware image may be slow or power-intensive. AWS notes that constrained networks can benefit from techniques that transmit only changed portions of firmware rather than an entire image.
Depending on the product, engineers may consider:
Delta or differential updates
Firmware compression
Resumable downloads
Scheduled update windows
Battery-level requirements
Smaller modular firmware components
The appropriate strategy depends on the device's hardware, connectivity, deployment environment, and expected product lifetime.
How Should OTA Updates Be Tested?
OTA functionality should be tested for failure conditions, not only successful installations. Testing should simulate real-world problems such as:
Power loss during download
Power loss during installation
Interrupted connectivity
Corrupted firmware
Invalid signatures
Incorrect firmware versions
Insufficient storage
Repeated reboot failures
Low battery conditions
Backend communication failures
Engineers should verify that the device either completes the update successfully or returns to a safe operational state.
OTA testing should also cover multiple hardware revisions and previous firmware versions when products remain deployed for long periods.
Common OTA Firmware Design Mistakes
Many OTA problems originate from architectural decisions made early in product development.
Adding OTA Too Late
If memory, bootloader behaviour, security, and backend requirements were not considered during initial design, adding OTA later may require significant firmware or hardware changes.
Updating Without Rollback
Installing firmware without maintaining a recovery path can leave devices unusable if the new image fails.
Trusting the Download Channel Alone
HTTPS or another encrypted transport protects data in transit, but firmware should still be cryptographically authenticated before execution.
Updating the Entire Fleet at Once
Large deployments should be staged and monitored so problems can be detected before they affect every device.
Ignoring Hardware Revisions
Products often evolve during their manufacturing lifetime. OTA infrastructure needs to know which firmware is compatible with each hardware revision.
Failing to Monitor Update Status
Manufacturers need visibility into which devices succeeded, failed, rolled back, or never received an update. Without fleet-level monitoring, firmware fragmentation can become increasingly difficult to manage.
OTA Firmware Update Checklist
Before deploying remote firmware updates, verify that the system can:
Authenticate firmware before installation
Verify firmware integrity and compatibility
Protect update communications
Recover from interrupted downloads
Recover from power loss
Roll back failed firmware
Prevent unauthorised downgrades
Distinguish device and hardware revisions
Stage updates across device groups
Report deployment status
Monitor device health after installation
Maintain appropriate firmware version records
These capabilities should be validated before large-scale deployment rather than after devices are already operating in the field.
Frequently Asked Questions About OTA Firmware Updates
What does OTA mean in firmware?
OTA means over the air. An OTA firmware update allows a connected device to receive and install new firmware remotely through a network connection instead of requiring physical access to the device.
Why are OTA updates important for IoT devices?
OTA updates allow manufacturers to fix bugs, patch security vulnerabilities, improve functionality, and maintain deployed IoT devices remotely. They become especially important when devices are distributed across many customers or difficult-to-access locations.
What happens if an OTA firmware update fails?
A well-designed OTA system should detect the failure and recover to a known working firmware image. A/B firmware partitions, boot validation, watchdog mechanisms, and rollback logic can help prevent a failed update from making the device unusable.
What is an A/B firmware update?
An A/B update architecture maintains two firmware partitions. The device runs the current firmware from one partition while downloading a new version to the other. If the new firmware fails after activation, the system can switch back to the previous working image.
Are OTA firmware updates secure?
OTA updates can be secure when the architecture uses controls such as encrypted communication, digitally signed firmware, secure boot, version validation, protected signing keys, and rollback or anti-rollback mechanisms. Security should be designed into both the device and update infrastructure.
Design OTA Capability for the Full Product Lifecycle
OTA firmware updates are more than a post-launch convenience. They are part of designing a connected product that can remain secure, maintainable, and functional throughout its deployed lifetime.
Reliable remote upgrades require coordination between hardware resources, bootloader architecture, embedded firmware, connectivity, cloud infrastructure, security, testing, and fleet management.
Tektos Ecosystems develops connected products across these disciplines, including embedded firmware, secure device connectivity, cloud infrastructure, device management, OTA update mechanisms, remote diagnostics, and manufacturing support. Tektos' existing connected-device architecture also includes OTA firmware update mechanisms and fleet monitoring as part of its cloud and application capabilities.