Firmware Over-the-Air (OTA) Updates

Overview

Practice of delivering firmware updates to deployed devices over a network — covering signed image generation, delta and A/B partition schemes, staged rollouts, rollback on failure, and post-update telemetry. Now table stakes for any connected product, and explicitly required by the EU Cyber Resilience Act for the security-update lifetime of a product.

Benefits

• Lets teams ship security and bug fixes after deployment without truck rolls
• Enables staged rollouts and gradual canary releases to limit blast radius
• A/B and rollback schemes turn 'bad update' from a recall into an incident
• Required to meet CRA security-update obligations across the support window

Limitations & Risks

• Adds attack surface — image signing, key management, and bootloader robustness become safety-critical
• Requires storage and bandwidth headroom that constrained MCUs may not have
• Field rollback paths add real complexity that must itself be tested

Recommended Actions

Pick a managed OTA stack appropriate to the product (Mender, Memfault, MCUboot + custom transport, ESP-IDF OTA, Zephyr device-firmware-update), design rollback before designing the happy path, and treat 'update fails gracefully' as a release gate, not an afterthought.

Additional Notes

Replaces the prior 'Firmware OTA Testing' framing — testing OTA is one concern, but the practice itself is the update lifecycle. Pairs directly with SBOM, CRA Compliance, and DevSecOps.

References & Links

• https://docs.mender.io/
• https://www.trustedfirmware.org/projects/mcuboot/
• https://docs.zephyrproject.org/latest/services/device_mgmt/dfu.html