Safe, secure OTA updates for industrial and automotive
KEY TAKEAWAYS:
- Build your security on a hardware root of trust and verified boot chain
- Enable scalable key management to support long product lifecycles
- Include fail-safe update mechanisms to avoid device bricking
Safe, secure over-the-air (OTA) update architectures let industrial and automotive manufacturers patch vulnerabilities, add features and fix bugs without physically touching deployed devices.
In safety-critical environments, an update must never brick a system or weaken its security posture. Secure boot, robust key management and fail-safe partitioning implemented using MCUs with secure elements can achieve that goal in harsh, real-world conditions.
But there are practical design trade-offs that embedded engineers face when they bring OTA into vehicle platforms and factory automation equipment.
Industrial plants and vehicles run distributed networks of controllers and electronic control units (ECUs) that may operate for decades in electrically noisy, temperature-extreme or vibration-heavy environments where service visits are either costly or impossible.
Many of these devices sit in sealed enclosures or remote locations, making physical access difficult and pushing manufacturers toward remote maintenance as the default. Downtime carries a high price, and in automotive and process control applications, a failed update can compromise both functional safety and cybersecurity. Secure OTA, therefore, must satisfy several constraints at once:
- It must preserve safety-critical functionality under all failure modes with guaranteed rollback to a known good image.
- It must provide strong cryptographic guarantees of firmware origin and integrity from cloud to flash memory.
- It must scale across thousands or millions of devices with rigorous cryptographic key and version management while remaining compliant with functional safety and cybersecurity standards.
- At the same time, development teams need an architecture that is not excessively complex so that firmware engineers, IT staff and safety assessors can understand and audit it.
Building a hardware Root of Trust
Every secure OTA plan starts with a Root of Trust anchored in hardware so that only authenticated code can execute during boot. On security-focused MCUs, this typically combines immutable ROM boot code, unique hardware keys and cryptographic accelerators, creating a chain of trust that extends from the first instruction to the application image. The root of trust must be simple and stable because it is difficult to change once devices are in the field.
A typical secure boot flow for an OTA-capable device works in several stages. First, the ROM bootloader verifies the digital signature (which inherently validates integrity via hashing) of the next-stage bootloader stored in on-chip or external flash, using a public key (or its hash/digest) stored in secure, immutable hardware such as OTP, e-Fuses or other secure storage.
The verified bootloader then performs additional checks, including version, anti-rollback counters and secure debug state before loading the operating system and application firmware. At each stage, failures in signature verification or integrity checks force a fallback to a known good image or a minimal rescue environment, which prevents unauthorized or corrupted code from running.
Secure boot is essential not only for the initial factory image but also for every subsequent OTA update, because the same signature verification path validates new firmware before it can be activated. When architects define the boot chain early in the project, they can reuse the same trust anchors for other functions, such as secure diagnostics or feature enablement, which reduces overall complexity.
Scalable cryptographic key management for OTA fleets
Robust key management is the second pillar of a secure OTA architecture. Devices must verify the authenticity of firmware and mutually authenticate with the back-end update server, and operators need mechanisms to rotate or revoke keys over the product lifetime. In long-lived industrial and automotive programs, that lifetime can exceed 10 or even 15 years, which magnifies the impact of any key management mistake.
Effective key management for OTA fleets includes several core elements. Per-device identity keys, derived from hardware entropy or securely provisioned during manufacturing, enable mutual authentication using TLS/DTLS (typically via device certificates), ensuring encrypted OTA communication.
Separate signing keys for firmware images are held offline or in hardware security modules, so compromise of a server certificate cannot be used to forge updates. Anti-rollback mechanisms such as monotonic counters stored in secure hardware or protected flash, enforced by the bootloader, prevent attackers from reinstalling older, vulnerable firmware even when they obtain valid images. Planned key rotation allows migration to new signing or transport keys without interrupting service, which is critical when supplier relationships or regulatory requirements change.
In safety-critical automotive systems, key management policies should align with security-by-design frameworks such as Uptane (an open, secure software update framework to protect OTA updates in automobiles and other ground vehicles), which explicitly model multiple signing roles to minimize the impact of any single key compromise.
Similar concepts can be applied in industrial fleets by separating responsibilities between product engineering, security operations and manufacturing, with clear ownership of each class of key.
Develop your Secure OTA strategy with Avnet’s /IOTCONNECT™ for AWS on Tria’s OSM93
MaaXBoard OSM93 features an NXP i.MX 93 System on Chip compute module, with integrated AI/ML NPU accelerator, EdgeLock security enclave and Energy Flex architecture that supports separated processing domains, such as the Application domain with two Arm® Cortex®-A55 (1.7 GHz) cores, the real time domain with Arm® Cortex®-M33 (250 MHz) core and Flex domain with Arm® Ethos-U65 NPU (1 GHz).
Fail-safe partitioning and A/B update strategies
Fail-safe memory partitioning ensures that even if power fails mid-update or a newly installed image crashes, the device can still boot and maintain essential functions. For Linux-class systems and larger MCUs, A/B partitioning is widely adopted.
One partition runs the active firmware while the update is written to the inactive bank, and only after the new image passes health checks does the bootloader switch the active flag. This approach adds some flash overhead, but in return, it provides predictable behavior under almost any update failure.
An effective partitioning strategy uses distinct partitions for bootloader, operating system and applications, each with independent versioning and, when necessary, its own A/B structure so that an OS upgrade cannot invalidate the recovery path. The switch from old to new partition is governed by the bootloader, with watchdog-based confirmation logic that reverts automatically if the new firmware fails to start critical tasks or reconnect to the management server. Some designs also include a rescue system or minimal maintenance image stored separately, which gives field engineers a last resort method of recovering devices that encounter unforeseen failures.
Resource-constrained microcontrollers that cannot afford full A/B duplication may stream firmware into a staging area, verify it fully, and only then overwrite the live image, with a small immutable emergency boot block as the final safety net. In these devices, attention to power supervision, flash endurance and update timing is critical because the margin for error is smaller than on high-end platforms.
Selecting the right OTA strategy
| Strategy | Flash overhead | Rollback speed | Best for | Limitation |
|---|---|---|---|---|
| A/B partitioning | 2x image size | Instant | Linux, high-end MCUs | Requires double memory storage |
| Staging area | 1x image size | Medium | Mid-range MCUs | Flash wear during copy |
| In-place update | Minimal | Slow (requires full reflash) | Resource-constrained MCUs | Limited recovery options |
| Delta updates | Minimal | Medium | Bandwidth-constrained systems | Complex verification chain |
Choosing the right elements for secure OTA firmware updates
The choice of MCU and companion security components fundamentally shapes the OTA architecture. Security-focused MCUs aimed at IoT, industrial control and automotive applications often embed TrustZone-class isolation on supported Arm Cortex-M (e.g., M23/M33) and Cortex-A platforms.
TrustZone is a hardware security extension that splits an Arm-based system into isolated secure and normal worlds so that sensitive code and data can run protected from the rest of the software. In addition, the MCUs implement hardware-based cryptography, secure debug, and native support for secure boot and secure firmware update flows. Selecting a device family with good tooling and documentation can shorten development schedules and make certification discussions easier.
Secure enclaves in microprocessors and microcontrollers
A common reference design pairs a security-enabled MCU with hardware-enforced isolation, which separates trusted boot and update logic from application code and creates a trusted execution environment for handling keys and firmware decryption. It adds an external secure flash device or secure element that stores firmware images and sensitive data over an encrypted interface, which protects against bus sniffing and physical tampering of off-chip memory.
Connectivity modules such as LTE, Wi Fi, Ethernet or automotive telematics units may implement or offload TLS, perform mutual authentication, and use robust session management suited to intermittent coverage and long update windows.
In automotive ECUs, where many networked controllers share a vehicle domain, the OTA architecture must account for gateway modules, in vehicle networks such as CAN FD and Ethernet, and scheduling of updates so that safety-relevant functions are never taken offline together. Industrial controllers must coordinate updates with maintenance windows and integrate with supervisory control and data acquisition or manufacturing execution systems to log and verify every change. In both sectors, early collaboration between embedded teams and IT or cloud teams pays off because it avoids mismatches between device capabilities and back-end expectations.
Designing an end-to-end secure OTA strategy
A secure device-side architecture only delivers full value when connected to an equally robust back-end OTA pipeline. End-to-end designs usually include a build-and-signing stage where firmware and containerized application images are scanned, tested and cryptographically signed before release, providing an auditable chain of custody from development to deployment. Development teams should treat this pipeline as part of the product, not just a convenience for engineering, because any weakness there can undermine device-level protections.
An update orchestration platform targets fleets based on hardware variant, region, software baseline and safety constraints, with staged rollouts and canary deployments that limit the impact of unforeseen issues. Telemetry and logging hooks in the device firmware report version, update status and diagnostic data.
These features support regulatory reporting and enable rapid rollback if anomalies appear. Because OTA updates are now a regulatory focus, especially for connected vehicles, manufacturers must treat the OTA infrastructure as part of their overall cybersecurity management system and subject it to continuous risk assessment, penetration testing and compliance audits.
Designing safe, secure OTA update architectures for industrial and automotive devices therefore requires a holistic approach that spans hardware Roots of Trust, cryptography, memory architecture, networking and cloud orchestration, all aligned to industry standards and safety requirements from the earliest design phase. When these elements come together, OEMs gain a platform that can evolve in the field, protect brand reputation, and open the door to new features and revenue streams throughout the product lifecycle.
