Blog:
Secure Over‑The‑Air Updates for Cortex‑M and External Devices using Torizon

Introduction

Modern embedded products rarely consist of a single homogeneous system. A Linux‑capable system‑on‑module (SoM) often sits at the center, surrounded by real‑time microcontroller cores, external MCUs and FPGAs, HMIs, cameras and even machine‑learning accelerators. Each of these subsystems has its own firmware or data that will need updates as your product matures. Keeping everything in sync across a fleet is hard — you need secure delivery, resilience against network glitches and a way to customise the update procedure for each component.

To address this challenge Toradex introduced Subsystem Updates in the Torizon platform. This feature builds on the automotive‑grade Uptane update standard to provide secure, versioned updates not just for the OS and application, but for any subsystem connected to your embedded Linux device. Whether you’re flashing a Cortex‑M core, updating a camera firmware or distributing a new machine‑learning model, Torizon Subsystem Updates lets you do it safely and reliably over the air.

Why Updating Every Subsystem Matters

Many OTA solutions only update the base operating system and application. In practice, devices include multiple programmable components whose firmware may be developed by different teams and have different lifecycles. Without a unified update system you end up with ad‑hoc scripts, manual field upgrades and a high risk of bricking devices. Moreover, there’s the increased risk for attacks against the cybersecurity of your device. Not only the main Linux system is subjected to regulations such as the CRA (Cyber Resilience Act), but any ancillary digital element.

Torizon’s Subsystem Updates solves this by treating any component as a first‑class update target. Before this feature, Torizon Cloud could deliver new applications, rootfs updates and bootloader packages, external devices such as WiFi modules, and microcontrollers could only be updated as part of a full system upgrade. After enabling subsystem updates, these components can be updated and managed independently of the main OS and application. After enabling subsystem updates, those external devices along with internal cores (e.g., Cortex‑M) become updateable just like your Docker‑compose stack. The result is a coherent update strategy spanning the entire product.

Built on Uptane: Security and Reliability by Design

Subsystem updates rely on Torizon’s Uptane‑compliant update architecture. Uptane was designed for the automotive industry and offers resilient protection against all attackers; even nation‑state adversaries cannot tamper with software without detection. The framework performs certificate validation at every step, ensures that software comes from you and hasn’t been modified, and provides a multilevel, fault‑tolerant recovery mechanism that is resistant to unreliable networks and power cuts.

What Are Subsystem Updates?

Subsystem Updates are a generic, plugin‑driven mechanism to deliver custom payloads to your devices. Each update package is versioned and managed independently of other subsystems, and Torizon Cloud handles delivery, authenticity and integrity checks for you. A lightweight action handler script on the device performs the actual installation, letting you define how to flash a microcontroller or copy a file to an FPGA or take any other customized action in the system, backed by our secure OTA update strategy.

Typical Use Cases

The flexibility of this mechanism opens up a wide range of scenarios:

• Built‑in Cortex‑M firmware – update the real‑time core firmware inside your SoC.
• External MCUs/FPGAs – flash firmware on microcontrollers or FPGAs connected over UART, SPI or even the network.
• Branding assets and UI resources – remotely change splash screens, icons or videos without touching your application.
• Configuration files – manage configuration files or license keys centrally.

How Subsystem Updates Work

Subsystem updates involve several key components:

Configuring Your Own Subsystem Update

Implementing a subsystem update requires two files:

1. secondaries.json – describes each subsystem to the update client. For each target you specify an ecu_hardware_id (the subsystem name), the directory where payloads are stored, the path where the current payload is found and the path to your action handler. Toradex recommends storing update data under /var/sota/storage/<subsystem> to comply with OSTree restrictions.
2. Action handler script – a shell script, Python program or binary that implements three actions: get-firmware-info (report the current version), install (perform the update) and complete-install (finalise installation after a reboot). A minimal shell example echoes the appropriate JSON status and calls tools like avrdude to flash a Cortex‑M core. If your update requires a reboot, touch /run/need‑reboot and return the ‘need‑completion’ status code so the client knows to run complete-install on next boot.

Example Flow

For example, a subsystem can be created to update the Cortex‑M4 core. In this setup, Aktualizr is configured to deliver the firmware image into /var/sota/storage/cm4, and an action handler is written to invoke avrdude -P /dev/ttyACM0 -D -U flash:w:$SECONDARY_FIRMWARE_PATH:i, which flashes the MCU. The same update mechanism can deliver additional assets such as a new PNG splash screen to the device by creating a separate subsystem that copies the image into the boot partition. Similarly, the same approach can be used to update Arduino firmware on a USB‑connected ESP32 by adapting the action handler. These examples demonstrate how flexible the action handler mechanism is. If you can script the update process, you can automate it.

Benefits for Engineers and Managers

For Embedded Linux Engineers

• Unified update pipeline – manage OS images, container applications and microcontroller firmware through one platform.
• Customisable installation – write simple scripts to flash firmware or copy files; no need to modify the secure delivery infrastructure.
• Flexible interfaces – deliver updates via UART, SPI, CAN or network depending on your subsystem’s needs.
• Works online or offline – subsystem updates function the same whether the device is connected to the cloud or updated via USB stick.

For Application Engineers

• Rapid iteration – update models, configuration files or branding assets without building a new OS release.
• Automated CI/CD integration – TorizonCore Builder CLI lets you integrate package creation and deployment into your existing pipelines.
• Fleet visibility – see which devices have which firmware versions and track update success.

For Technical Leads and Product Managers

• Reduced complexity – one platform manages all software components, lowering maintenance overhead.
• Security and compliance – Uptane compliance and CRA support help you meet regulatory requirements
• Longevity and cost savings – shipping security patches for up to five years and enabling remote updates reduces field service costs.
• Scalability – manage thousands of devices through Torizon Cloud, with features like scheduled updates and rollback policies.

Getting Started

Toradex makes it easy to try Torizon Subsystem Updates. You can request sample hardware or experiment on Raspberry Pi, x86 or QEMU. Pre‑built Torizon OS images and a 30‑day feature‑complete trial are available; remote access, OTA updates and device monitoring work out of the box, and there’s extensive documentation and examples on the Toradex Developer Center. Check out the reference action handlers on GitHub to see how to update different microcontrollers. When you’re ready, provision your device to Torizon Cloud, define your subsystems and start shipping secure OTA updates to your fleet.

Conclusion

Subsystem Updates extend Torizon from a robust OS and application update platform into a holistic solution for updating every component in your embedded product. By leveraging the security and reliability of Uptane, providing flexible action handlers and supporting both online and offline workflows, Torizon gives engineers a straightforward way to keep Cortex‑M cores, external MCUs, FPGAs, cameras and configuration files in sync across their fleets. Coupled with features like SBOM publication, secure boot and vulnerability monitoring, it also helps product managers meet evolving regulations such as the EU Cyber Resilience Act. If your device contains more than just a Linux OS — and most modern products do — Torizon Subsystem Updates might be the missing piece in your DevOps pipeline.