Over-the-Air (OTA) updates have changed the way modern embedded systems are maintained. A device no longer needs to be physically connected to a programmer every time its firmware needs an update. With a reliable OTA mechanism, thousands of deployed devices can receive new firmware remotely, making bug fixes, security patches, feature updates, and long-term maintenance significantly easier.
But the ability to remotely replace firmware also introduces a serious security responsibility.
Firmware is one of the most privileged pieces of software on an embedded device. It can access hardware peripherals, network credentials, sensors, actuators, stored data, and other security-sensitive resources. If an attacker can convince a device to install malicious firmware, the consequences can be much more severe than a compromised application.
That is why a production OTA system should not simply answer the question, "Can I download new firmware?"
It should answer a much more important question:
Can the device independently verify that this firmware is trusted before allowing it to execute?
A basic OTA implementation can look deceptively simple.
The device connects to a server, downloads a firmware binary, writes it to flash, and reboots.
That approach may work during development, but production systems need to consider what happens when the network is compromised, the update server is attacked, a firmware image is modified, power is lost during installation, or an attacker attempts to install an older vulnerable version.
A secure OTA architecture therefore needs several independent protections.
The most important ones include:
Each mechanism addresses a different threat.
TLS is an important part of OTA security. It protects the communication channel between the device and the update server and helps prevent attackers from simply intercepting and modifying traffic.
However, HTTPS should not be treated as the complete firmware security mechanism.
Imagine that an attacker gains access to the update infrastructure and replaces a legitimate firmware file with a malicious one. The device could still establish a perfectly valid HTTPS connection and download the malicious firmware through an encrypted channel.
The problem is no longer communication security.
The problem is firmware authenticity.
This is where digital signatures become important.
Instead of trusting a firmware file simply because it came from an HTTPS server, the device can verify a digital signature embedded with the firmware release.
The release process generally looks like this:
Source Code
↓
Build Firmware
↓
Run Tests
↓
Generate Firmware Image
↓
Sign Firmware
↓
Publish OTA Release
↓
Device Downloads Image
↓
Verify Signature
↓
Install Only If ValidThe private signing key remains on the trusted build or release infrastructure.
The device only needs the corresponding public key, or another trusted mechanism for validating the signature.
This creates an important security property: even if somebody modifies the firmware after it has been released, the device can detect that the signature is no longer valid.
The attacker may be able to modify the binary, but they should not be able to generate a valid signature without access to the private signing key.
Firmware integrity and authenticity are related, but they are not exactly the same.
A cryptographic hash can be used to determine whether firmware has changed.
For example, a SHA-256 digest can be calculated from a firmware image. If a single part of the image changes, the resulting digest will also change.
However, a hash alone does not tell the device who created the firmware.
An attacker could modify the firmware and calculate a new hash.
Digital signatures solve this problem by combining integrity verification with proof that the firmware was signed by a trusted authority.
In simplified terms:
Hashing answers:
Has this data changed?
Digital signatures answer:
Was this data authorized by a trusted signing key, and has it changed since it was signed?
That distinction is fundamental when designing a secure firmware update system.
One of the most important principles in secure OTA design is that the device should not blindly trust the update server.
The server can tell the device:
"Here is firmware version 2.5.0."
The device should still ask:
"Is this firmware actually authorized to run on me?"
That verification can include:
Only after these checks pass should the bootloader allow the new firmware to execute.
This creates a useful security boundary where the device itself becomes the final authority over what software it will run.
Consider a device running firmware version 3.2.0.
Months earlier, the manufacturer released version 2.1.0. That older version was correctly signed, but later discovered to contain a serious vulnerability.
If the device accepts any correctly signed firmware, an attacker may attempt to install version 2.1.0.
The signature would be valid.
The firmware would be authentic.
But the device would still become vulnerable.
This is known as a rollback or downgrade attack.
A secure OTA implementation can address this by maintaining a security version or monotonic firmware counter.
For example:
Installed security version: 32
Incoming firmware: 29
29 < 32
Update rejectedA newer release could contain:
Installed security version: 32
Incoming firmware: 35
35 > 32
Update allowedThis prevents an attacker from simply returning the device to an older, vulnerable firmware release.
Secure OTA and secure boot are closely related, but they solve different problems.
Secure OTA protects the update process.
Secure boot protects the execution process.
A secure bootloader can verify the firmware before transferring control to it. This means that even if somebody obtains physical access to the device and modifies the firmware stored in flash, the device can refuse to execute unauthorized code.
The resulting chain of trust can look conceptually like:
Hardware Root of Trust
↓
Trusted Bootloader
↓
Verified Firmware
↓
ApplicationThe security of the system depends on establishing this chain correctly.
If the bootloader blindly executes whatever happens to be stored in flash, firmware signing becomes much less useful because an attacker may simply bypass the OTA process entirely.
Security is only part of the OTA problem.
Reliability matters too.
What happens if the device loses power halfway through an update?
Suppose the device is currently running firmware from one flash partition. Instead of overwriting that partition directly, a safer approach is to maintain two firmware slots.
The active firmware continues running while the new firmware is written to the inactive slot.
Once the download and verification process is complete, the bootloader can attempt to boot the new image.
If the new firmware successfully starts and passes its health checks, it can be marked as valid.
If something goes wrong, the device can fall back to the previous firmware.
This approach provides a recovery path for problems such as:
For connected devices deployed in difficult-to-access locations, this can make the difference between a recoverable failure and a physically bricked device.
The firmware binary itself is not the only information an OTA system needs.
A release can include metadata describing the firmware and the devices it supports.
For example:
{
"version": "2.5.0",
"hardware": "rev-B",
"security_version": 35,
"release": "production"
}A device can use this information to determine whether the firmware is appropriate before starting the installation process.
This becomes particularly important when a product exists in multiple hardware revisions.
A firmware image designed for one board revision should not automatically be accepted by every device simply because the firmware signature is valid.
The firmware signing key is arguably one of the most sensitive assets in the entire OTA infrastructure.
If an attacker gains access to the production private signing key, they may be able to create firmware that appears legitimate to every device trusting that key.
That means secure OTA is not only an embedded systems problem.
It is also a software supply-chain and infrastructure security problem.
Production environments should consider protections such as:
The signing process should also be separated from normal development as much as practical.
A developer compiling firmware should not automatically have unrestricted access to the production signing key.
A production OTA system should be considered as a complete lifecycle.
The process can begin with source code and continue through automated builds, testing, signing, distribution, device verification, installation, boot validation, and monitoring.
A simplified lifecycle is:
Development → Build → Test → Sign → Publish → Download → Verify → Install → Boot → Validate
This approach also makes it easier to introduce security controls at every stage.
For example, automated tests can prevent known issues from reaching production. The signing stage can ensure that only authorized builds become official releases. The device can verify the signature and security version before installation. Finally, the backend can monitor deployment status across the fleet.
OTA therefore becomes part of the product's entire software supply chain rather than simply being another API endpoint.
The ESP32 ecosystem is a good example of how these concepts come together in a practical embedded platform.
Using ESP-IDF, an application can be designed around features such as secure boot, flash encryption, signed application images, OTA partitions, and rollback support.
These features should not be viewed as interchangeable.
For example:
TLS protects communication with the server.
Firmware signing helps establish firmware authenticity.
Secure boot helps ensure that only trusted firmware executes.
Flash encryption protects information stored in flash from certain forms of physical access.
Anti-rollback mechanisms help prevent vulnerable older firmware from being installed.
Together, these controls provide significantly stronger protection than relying on any single security mechanism.
The exact implementation should depend on the threat model, device capabilities, product requirements, and recovery strategy.
Several shortcuts can turn an otherwise functional OTA system into a security risk.
A file named firmware-final.bin does not tell the device whether the firmware is authentic.
Encrypted transport does not replace firmware authentication.
A device should never need the private key used to authorize production firmware.
An interrupted update should not permanently destroy the currently working system.
A correctly signed firmware image can still contain an old vulnerability.
Firmware compatibility should be explicitly verified.
One of the biggest lessons from designing secure OTA systems is that there is no single feature that makes OTA secure.
HTTPS alone is not enough.
Signing alone is not enough.
Secure boot alone is not enough.
A reliable architecture combines multiple layers so that compromising one component does not automatically compromise the entire device.
A useful way to think about the architecture is:
Communication security protects the connection.
Firmware authentication protects what is allowed to be installed.
Secure boot protects what is allowed to execute.
Anti-rollback protects against vulnerable older releases.
A/B partitions and rollback protect availability.
Key management protects the trust infrastructure behind the entire process.
Together, these mechanisms create a much stronger foundation for connected embedded systems.
OTA updates are essential for modern connected products, but remote firmware updates should always be treated as a security-critical operation.
The objective is not simply to make firmware updates convenient. It is to make them verifiable, controlled, recoverable, and resistant to unauthorized modification.
A well-designed OTA system should assume that networks can be attacked, servers can be compromised, downloads can fail, power can disappear, and devices can be physically accessed.
The device should still be able to make a trusted decision about the firmware it executes.
That is the core idea behind secure OTA:
The network can deliver firmware, the server can recommend an update, but the device must ultimately decide what it is willing to execute.
For embedded systems, this principle is especially important because firmware is not just another software component. It sits directly between the application and the hardware, making the integrity of that firmware fundamental to the security of the entire device.
Yasir Nawaz is an Embedded Systems and Cybersecurity professional focused on connected devices, firmware, IoT systems, Linux, and embedded security.
His work involves developing and integrating embedded systems, working with microcontrollers such as the ESP32 family and STM32, and exploring the security challenges involved in deploying and maintaining connected devices at scale.
He writes about embedded systems, cybersecurity, IoT, Linux, open-source technologies, and practical engineering.
Website: sudoyasir.com GitHub: github.com/sudoyasir LinkedIn: linkedin.com/in/sudoyasir
© 2026 Yasir Nawaz. All rights reserved.
This article represents personal technical research and experience and is intended for educational purposes.