In the rapidly evolving world of embedded systems, firmware serves as the fundamental software layer that controls hardware behavior, manages communication protocols, and enables device functionality. From smart home thermostats and wearable health monitors to industrial controllers and automotive electronic control units (ECUs), firmware directly determines how a device operates, responds to inputs, and interacts with networks. As these devices become more interconnected and integral to critical infrastructure, the need to keep firmware up to date has never been more pressing. Firmware Over-the-Air (FOTA) updates address this need by allowing manufacturers to remotely deploy firmware patches, feature enhancements, and security fixes over wireless networks, eliminating the requirement for physical access. This capability not only reduces operational costs and downtime but also provides a rapid response mechanism to emerging cyber threats. FOTA has evolved from a convenience feature into a foundational requirement for secure, resilient, and long-lived embedded systems across industries.

What Are FOTA Updates?

Firmware Over-the-Air (FOTA) refers to the method of delivering firmware updates to embedded devices through wireless communication channels such as Wi-Fi, cellular networks (4G/5G), Bluetooth Low Energy (BLE), LoRaWAN, or satellite links. Unlike Over-the-Air (OTA) updates that encompass broader software components including applications and operating system patches, FOTA specifically targets the low-level firmware that initializes hardware, manages boot processes, and provides core system services. The update process typically involves a remote server that packages the new firmware image, a secure transmission protocol to deliver the image to the device, and an update agent on the device that verifies, installs, and activates the new firmware. FOTA updates can be classified into full image updates, where the entire firmware is replaced, and incremental or delta updates, where only changed parts of the firmware are transmitted to conserve bandwidth and reduce update time. The adoption of FOTA has grown rapidly with the expansion of the Internet of Things (IoT), where millions of geographically distributed devices require consistent maintenance without manual intervention.

The Critical Role of FOTA in Embedded Security

Embedded devices operate in increasingly hostile environments where attackers continuously probe for vulnerabilities. Many of these devices have limited processing power, memory, and energy budgets, which constrain the complexity of security measures that can be implemented at design time. FOTA updates directly address this asymmetry by enabling manufacturers to respond to discovered vulnerabilities with patches that can be deployed globally in a matter of hours or days, rather than weeks or months. Below, we examine the key security functions that FOTA fulfills.

Addressing Vulnerabilities Rapidly

When a security flaw is discovered in a device's firmware—whether a buffer overflow in a network stack, a weak cryptographic implementation, or a backdoor in a third-party library—the manufacturer must produce a fix and distribute it to every affected device. Without FOTA, this process typically involves recall campaigns, field technician visits, or requiring end users to manually download and install updates via USB or SD card. These approaches are slow, expensive, and often fail to achieve high adoption rates, leaving devices vulnerable for extended periods. FOTA shortens the window of exposure dramatically by allowing direct, remote delivery of patched firmware. For example, in 2020, a critical vulnerability in the Texas Instruments BLE stack (CVE-2020-13528) affected millions of IoT devices; manufacturers with FOTA capabilities were able to push patches within days, while those without were forced to rely on physical updates, leaving devices exposed for months. Learn more about this vulnerability in the Texas Instruments BLE vulnerability report.

Ensuring Compliance with Security Standards

Regulatory frameworks and industry standards increasingly mandate that embedded devices support secure update mechanisms. The European Union's Cybersecurity Act, the UK's Product Security and Telecommunications Infrastructure (PSTI) Act, and the U.S. Executive Order on Cybersecurity all emphasize the need for devices to be updatable throughout their lifecycle. Similarly, standards such as IEC 62443 for industrial control systems, UL 2900 for IoT security, and ISO/SAE 21434 for automotive cybersecurity explicitly require manufacturers to provide secure firmware update capabilities. FOTA serves as the primary means to meet these compliance obligations. Without it, devices cannot be patched after deployment, effectively violating the security lifecycle requirements that regulators now enforce. For a deeper understanding of how the PSTI Act impacts device manufacturers, refer to the UK PSTI Act guidelines.

Protecting Sensitive Data

Embedded devices often handle sensitive data: medical records on health monitors, payment information on point-of-sale terminals, authentication credentials in access control systems, and proprietary data on industrial controllers. When firmware vulnerabilities are left unpatched, attackers can exploit them to extract or modify this data, leading to identity theft, financial fraud, or industrial espionage. FOTA updates allow manufacturers to deploy cryptographic improvements, fix data handling flaws, and update key management protocols without requiring device replacement. For instance, a smart meter that stores consumption data and communicates with the utility grid can receive a firmware update that strengthens the encryption algorithm used for data transmission, ensuring that customer privacy is protected even as cryptographic standards evolve. An excellent reference on securing firmware updates for IoT devices is the NIST SP 800-213 guidance on IoT firmware updates.

Maintaining Device Integrity and Preventing Tampering

Attackers may attempt to replace legitimate firmware with malicious versions to gain control over devices, turn them into bots for distributed denial-of-service attacks, or alter their behavior for fraudulent purposes. FOTA systems that incorporate secure boot, code signing, and cryptographic verification ensure that only authentic firmware from the manufacturer can be installed. When a vulnerability is discovered that allows privilege escalation or unauthorized code execution, a FOTA update can include patches that close these holes and restore device integrity. Additionally, FOTA can be used to revoke compromised cryptographic keys and rotate them out, effectively invalidating any tampered firmware that was signed with those keys. This chain of trust, from the update server to the boot loader, forms the backbone of device integrity in the field.

The FOTA Update Process: From Development to Deployment

Understanding the end-to-end FOTA lifecycle helps manufacturers design systems that are both secure and reliable. The process consists of several stages, each with its own security and operational considerations.

Building a Secure Firmware Image

The update begins on the manufacturing side, where the new firmware image is compiled, tested, and cryptographically signed. The build process must ensure that the firmware includes the correct dependencies, configuration settings, and security patches. Testing should cover functional verification, regression testing, and security validation to minimize the risk of introducing new vulnerabilities. Once built, the image is signed with a private key that the device can verify using a corresponding public key embedded in its boot loader. The signature ensures that the firmware has not been modified and that it originates from a trusted source. Some implementations also include a version number or monotonic counter to prevent rollback attacks, where an attacker tricks the device into installing an older, vulnerable version of the firmware.

Transmission and Authentication

The signed firmware image is uploaded to an update server, which manages distribution policy, device authentication, and delivery scheduling. When a device checks for updates—either on a schedule, triggered by a server push, or upon receiving a notification—the server authenticates the device using credentials such as device certificates, pre-shared keys, or token-based authentication. The firmware image is then transmitted over a secure channel, typically using TLS 1.3 or DTLS for encrypted transfer. The transmission must be resilient to network interruptions, especially for devices on unreliable connections such as cellular IoT or LoRaWAN. Techniques like chunked transfer, resumable downloads, and error-correcting codes help ensure that the image arrives intact. The update agent on the device verifies the digital signature of the received image before proceeding with installation. This step is non-negotiable, as it prevents the installation of tampered or counterfeit firmware.

Installation and Verification

After authentication, the device's update agent writes the new firmware to a dedicated storage partition. Many devices implement an A/B update scheme, also known as dual-bank or dual-image updates, where two copies of the firmware are maintained: one active partition and one inactive partition. The update is written to the inactive partition while the device continues to run on the active partition. Once the write is complete and verified, the device sets a flag to boot from the updated partition on the next restart. This approach minimizes downtime and provides a fallback in case the update fails. The boot loader then checks the signature and integrity of the newly active firmware before handing control to it. If any verification step fails, the boot loader can revert to the previous firmware, ensuring that the device remains operational and secure. After successful boot, the device reports the update status back to the server, completing the lifecycle.

Key Challenges in FOTA Implementation

While FOTA offers substantial benefits, implementing it in embedded systems comes with significant challenges that must be addressed to avoid introducing new risks.

Security Risks During Update Delivery

FOTA systems themselves can become attack vectors if not designed carefully. Attackers may attempt to intercept update transmissions, substitute malicious firmware, impersonate update servers, or exploit vulnerabilities in the update client. Without proper authentication and encryption, an attacker could push a modified firmware image that installs malware, turns the device into a botnet member, or renders it inoperable. Even with strong cryptography, implementation flaws such as weak random number generation, improper certificate validation, or buffer overflows in the update agent can be exploited. To mitigate these risks, manufacturers must follow security best practices throughout the FOTA pipeline, including code signing, mutual TLS authentication, certificate pinning, and rigorous code reviews. Regular penetration testing of the update mechanism is essential to uncover vulnerabilities before attackers do.

Bandwidth and Power Constraints

Many embedded devices operate on constrained networks with limited bandwidth, high latency, or intermittent connectivity. For example, devices in agricultural sensors using LoRaWAN may have a maximum payload size of just 250 bytes and a data rate of a few kilobits per second. Transmitting a full firmware image of 1 MB or more over such a link would take hours or days and drain the device's battery rapidly. Delta updates address this by transmitting only the differences between the current and new firmware versions. Techniques like binary differencing (e.g., bsdiff) or block-level patching can reduce update sizes by 70-95% in many cases. However, delta updates introduce complexity in terms of generating the patch, ensuring the base version is known, and verifying the patched image. For devices with extreme power constraints, the update agent must also manage energy consumption, potentially pausing the download if the battery level drops below a threshold.

Update Failure and Device Bricking

Bricking refers to the state where a device becomes completely non-functional due to a failed firmware update, typically caused by a corrupted image, hardware failure during write, or a power loss in the middle of the process. Without recovery mechanisms, a bricked device must be replaced or manually reflashed, which defeats the purpose of remote updates. To prevent bricking, manufacturers implement fail-safe mechanisms such as A/B dual-bank updates, watchdog timers, and recovery boot loaders. The A/B scheme, as described earlier, allows the device to revert to the previous firmware if the new one fails to boot. Additionally, a recovery mode that accepts updates via alternative channels (e.g., USB or serial) provides a last-resort recovery path. Even with these safeguards, the update agent itself must be robust against errors, including flash wear, corrupt storage, and unexpected power cycles.

Regulatory and Compliance Issues

FOTA updates must comply with a growing body of regulations that govern data privacy, device security, and software lifecycle management. The European Union's General Data Protection Regulation (GDPR) imposes strict requirements on how personal data is handled, and firmware updates that process or transmit such data must be designed with privacy in mind. Similarly, the Medical Device Regulation (MDR) in Europe requires that software updates for medical devices undergo risk assessments and potentially new conformity assessments. In the automotive sector, UN Regulation No. 156 mandates that vehicles sold in the EU must support over-the-air updates and that manufacturers must have a certified software update management system. Navigating these regulations requires careful planning, documentation, and sometimes third-party certification. Manufacturers must also consider long-term support obligations: regulators may require that devices receive security updates for a defined period, often up to 10 years for industrial or automotive systems.

Best Practices for Secure FOTA

To maximize the security and reliability of FOTA updates, manufacturers should adopt the following best practices across their embedded systems.

Implement Secure Boot and Signed Updates

Every firmware image must be digitally signed using a strong cryptographic algorithm, such as ECDSA with a 256-bit curve or RSA with 2048-bit keys. The device's boot loader must verify this signature before executing the firmware. This establishes a chain of trust from the boot loader to the application. The signing keys should be managed in a hardware security module (HSM) and never exposed to the build environment in plaintext. Additionally, use a monotonic version counter to prevent rollback attacks. The boot loader should reject any firmware with a version lower than or equal to the currently installed version, unless authorized by a manufacturer-signed override.

Encrypt Firmware in Transit and at Rest

Use TLS 1.3 or DTLS 1.3 for all communication between the update server and the device. The server certificate should be pinned or validated against a trusted certificate store on the device. For highly sensitive devices, consider encrypting the firmware image itself (in addition to the transport encryption) so that even if the image is extracted from the device's storage, it remains protected. This is especially important for devices that may be reverse-engineered after disposal or theft.

Deploy Fallback and Recovery Mechanisms

Every FOTA implementation must include a reliable fallback mechanism. The A/B dual-bank scheme is the industry standard for devices with sufficient storage. For deeply constrained devices that cannot afford two full firmware banks, a minimal recovery boot loader that supports firmware reinstallation via a secondary interface (e.g., UART, USB, or a simple over-the-air protocol) provides a safety net. The update agent should also implement a watchdog timer that triggers a rollback if the new firmware fails to boot within a configurable timeout. These mechanisms ensure that a failed update does not leave the device permanently disabled.

Use Delta Updates to Optimize Bandwidth

Delta updates significantly reduce the size of transmitted data, which conserves network bandwidth, reduces update time, and minimizes power consumption. The delta patch is generated by comparing the new firmware image with the known base image on the device. Libraries such as bsdiff, zdelta, or HDiffPatch can be used for binary diffing. However, the manufacturer must maintain an inventory of firmware versions per device to generate correct patches. In cases where the exact base version is unknown or unverifiable, a full image update should be used as a fallback. Delta updates should be signed and verified just like full images.

Test Thoroughly and Roll Out in Stages

Comprehensive testing is essential before deploying any firmware update to production devices. Testing should include functional verification on representative hardware, regression testing for all device features, stress testing under low-power and low-bandwidth conditions, and security testing of the update mechanism itself. A staged rollout—starting with a small percentage of devices, then gradually increasing to the full fleet—allows manufacturers to detect issues early and pause deployment if problems arise. Monitoring metrics such as update success rate, device crash rate after update, and battery drain patterns provides early warning of issues. A kill switch that allows manufacturers to halt an ongoing rollout remotely is a critical safety feature.

The Future of FOTA in Embedded Systems

The importance of FOTA will continue to grow as embedded systems become more pervasive, intelligent, and safety-critical. Several trends are shaping the future of FOTA technology.

Automotive FOTA is one of the most demanding applications, where ECUs control braking, steering, engine management, and advanced driver-assistance systems (ADAS). Automakers like Tesla, Ford, and BMW have already deployed FOTA for non-safety and safety-critical updates. With the adoption of software-defined vehicles, FOTA will become a core feature for every car, enabling manufacturers to add features, improve performance, and fix security issues throughout the vehicle's lifetime. ISO/SAE 21434 and UN Regulation No. 156 provide the regulatory framework for this evolution.

AI-driven firmware optimization is on the horizon, where machine learning models analyze device behavior and network conditions to determine optimal update timing, delta generation strategies, and power management. This could enable predictive updates that preemptively patch vulnerabilities before they are exploited, based on threat intelligence feeds and anomaly detection.

Post-quantum cryptography will become relevant as quantum computers threaten current public-key algorithms. FOTA systems must be designed to support algorithm agility, allowing cryptographic keys and signing algorithms to be updated remotely. Several standards bodies, including NIST, are already working on post-quantum signature schemes, and FOTA will be the vehicle for deploying those algorithms to the field.

Zero-trust architectures are being extended to device updates, where each update request is verified against device identity, health attestation, and policy compliance before delivery. This approach ensures that only devices in a known good state receive updates, reducing the risk of compromising devices that have already been tampered with.

Conclusion

Firmware Over-the-Air updates have transitioned from a nice-to-have convenience to an essential security requirement for modern embedded systems. FOTA enables manufacturers to respond to vulnerabilities with speed and precision, maintain compliance with evolving regulations, protect sensitive data, and preserve device integrity throughout the product lifecycle. However, implementing FOTA securely requires careful attention to cryptographic practices, fallback mechanisms, bandwidth management, and regulatory obligations. As embedded devices continue to infiltrate every aspect of daily life—from healthcare and transportation to industrial automation and smart infrastructure—the ability to update firmware remotely and securely will remain a cornerstone of device trustworthiness. Manufacturers that invest in robust FOTA infrastructure today will be better positioned to protect their customers, meet regulatory demands, and respond to an ever-changing threat landscape tomorrow.