OTA Updates for Edge AI: Challenges, Risks & Best Practices

In the rapidly evolving landscape of Edge AI, the "deploy and forget" mentality is a relic of the past. As we discuss in our Understanding the Functional Layers of Edge AI white paper the complexity Edge AI systems – which have eight distinct functional layers, from silicon to cloud - demands a lifecycle strategy that is as sophisticated as the models themselves. At the heart of this strategy lies over-the-air (OTA) updates.

For software engineers and system architects, OTA is the ultimate double-edged sword. It is the essential conduit for security patches, performance optimisations and model refinements. However, in an edge environment - where devices are often remote and resource-constrained, and possibly even mission-critical - a failed update isn’t just a technical glitch, it’s a potential "bricking" event that can take down an entire industrial line or a fleet of autonomous vehicles, for example.

In this Tech Talk we explore the challenges and risks associated with OTA updates and present a number of solutions. We’re going to reference function layers early on, so here’s a brief reminder of what they are:

The Challenges

The main difficulty with OTA in Edge AI stems from the porous nature of the architecture. As stressed in our Edge AI Implementation & Integration Challenges white paper, the system is not a simple linear stack. Layers often collapse or bypass one another to meet extreme latency and power demands. 

When you push an update, you aren't just updating an app, you might be updating a quantised model in the AI runtime and model infrastructure layer (layer 4), a driver in the firmware and hardware abstraction layer (layer 2) or a safety threshold in the decision, control and application logic layer (layer 6). Here are three things to be particularly aware of:

1. The Versioning Nightmare

At the edge, you are dealing with a fragmented ecosystem of GPUs, NPUs, CPUs and other devices. An update to the AI model might require a specific version of the firmware to access new hardware acceleration primitives. If the OTA orchestrator isn’t version-aware across all eight layers, a model update could trigger an operator fallback to the CPU, introducing delays that break the real-time requirements of the data pipeline and perception layer (layer 5).

2. The "Data Tax" of Connectivity

Edge devices often operate on the fringes of connectivity - using cellular, satellite or low-power WANs. Transmitting a multi-gigabyte deep learning model over a 4G link is not only expensive but also risky. The data tax here isn’t just about bandwidth, it’s about the power consumed by the radio and the time the device spends in a vulnerable, non-operational state during the update.

3. Atomic Integrity in Unstable Environments

What happens if the power fails or the network drops when the device is only partway through an update? In a standard consumer device, this might be an annoyance but in an Edge AI system governing an autonomous guided robot (AGR), for example, it’s potentially catastrophic. Ensuring atomicity - where an update either completes 100% or rolls back to a known good state -is a non-negotiable if you want edge resilience.

The Risks

The risks of OTA updates at the edge (or rather countering those risks) have moved from best practice to legal necessity. For example, the European Union’s Cyber Resilience Act (CRA), which entered into force in December 2024, establishes a new legal framework for digital products. 

To quote the CRA and emphasise the point we’re making here…

“The CRA introduces mandatory cybersecurity requirements for manufacturers, covering the planning, design, development and maintenance of such products. These obligations must be met at every stage of the value chain. The CRA also requires manufacturers to handle vulnerabilities during the lifecycle of their products.” – Cyber Resilience Act

Operational Bricking and Regression

The most immediate risk is "bricking" - rendering the device useless due to a corrupted update. However, a more subtle risk is improving performance in one area whilst worsening it in another. For example, an updated model might improve inference speed by 5% but processing might consume 15% more power, leading to an increase in heat not factored into the system’s thermal management (when the system was designed).

Conversely, in a vision-based system, a model update intended to reduce power could reduce the frame rate of the perception layer, causing the decision logic to miss a critical object detection event.

Security Vulnerabilities and the "Update Hijack"

Authoritative standards like ETSI EN 303 645 (last updated in late 2024, at this time of us writing this Simms Tech Talk) explicitly require that…

“The consumer IoT device shall have a mechanism available which makes successful brute-force attacks on authentication mechanisms via network interfaces impracticable unless the device has a resource constraint determined by the use case that prevents the implementation. – EN 303 545, Provision 5.1-5

Without robust end-to-end encryption and digital signatures, an adversary can perform an OTA "update hijack." For example, by pushing a malicious model, an attacker could subtly alter the decision logic of the system, instructing a security camera to ignore specific faces or allowing a robotic arm to exceed its safety boundaries. 

Model Theft and IP Exposure

Models are a company’s most valuable IP, and during an OTA transfer they are at their most vulnerable. If the update isn’t encrypted end-to-end and decrypted only within a trusted execution environment (TEE), the proprietary weights and architecture could be intercepted and cloned by competitors.

The Solutions

To navigate the above risks, engineers must adopt a "safety-first" approach to OTA orchestration. Here are the core strategies we recommend at Simms.

1. A/B Partitioning and Dual-Bank Flash

The gold standard for edge updates is the A/B partition strategy. The device maintains two complete copies of the software stack. The update is written to the inactive B partition while the A partition continues to run the system. Only after the update is fully verified, via checksums and attestation, does the system toggle the bootloader to the new partition. If the new version fails to boot or meet performance metrics, the system automatically rolls back to the A partition.

2. Delta Updates and Compression

To mitigate the data tax we mentioned earlier, we recommend using binary diffing or delta updates. Instead of sending an entire 500MB model, for example, the OTA server only transmits the specific weights or layers that have changed. When combined with edge-optimised compression algorithms, this can reduce the update payload by up to 90%, significantly lowering the risk of transfer failure and reducing power consumption.

3. Hardware-Anchored Attestation (Using a TPM)

Security must be anchored in the physical hardware layer (layer 1). By using a trusted platform module (TPM) or a secure element, the device can perform "Remote Attestation." Before the cloud pushes an update, the device sends a signed report of its current firmware and OS state. The cloud only releases the update if the device is verified as "healthy" and uncompromised. Once received, the update is decrypted using keys stored securely within the TPM, ensuring the model is never exposed in plain text.

4. Digital Twin Pre-Verification

Before pushing an update to a fleet of 10,000 devices, for example, it should be "flight-tested" on a digital twin. By simulating the update on a virtual representation of the edge hardware, engineers can identify potential performance regressions or thermal issues in a safe environment. This pre-deployment step is critical for maintaining the reliability of vision-based systems where environmental variables are constantly changing.

Summary

At Simms, we believe that successful OTA isn't just a software problem, it’s a holistic system challenge that requires a deep understanding of how a change in the AI runtime affects memory bandwidth, for instance. Also, if you opt for A/B partitioning your edge device will need more memory to meet immediate and future requirements.

Planning an Edge AI deployment? Let's discuss how to build a platform that's secure, scalable and ready for long-term success.