Why Full OTA Updates Are Still RareOTA Reality Check


A first-principles look at why “full” over-the-air (OTA) updates are uncommon today, and the specific hardware and architecture needed to make them standard.

Working definition: Full OTA = the ability to reliably update all major software domains over the air, including powertrain, battery management system (BMS), charging, ADAS (advanced driver-assistance system), body controls, and infotainment - with auditability, rollback, and cybersecurity controls.

Why Full OTA Is Still Uncommon

1.1 Legacy E/E architectures are fragmented

Most legacy vehicles were never designed for fleet-wide, over-the-air reflashing. A typical ICE or early EV platform may have 50-120 electronic control units (ECUs) sourced from multiple suppliers, each with its own firmware, bootloader, and safety constraints.

Instead of a small number of powerful computers, you get a “spaghetti” of modules on CAN and LIN buses. That is fine for local control, but extremely fragile for coordinated OTA updates.

Consequence: It is difficult or impossible to update all domains in a consistent, automated way without risking bricking modules or violating safety assumptions.

1.2 Safety-critical domains need robust rollback

Powertrain, steering, braking, BMS, and core ADAS controllers are safety-critical. Updating them requires:

  • Atomic update behavior - new image is validated before becoming active.
  • Guaranteed rollback - if validation fails, the module reverts to the previous firmware image.
  • Well-defined “safe state” behavior during update.

Many older ECUs do not support dual-image firmware or A/B partitions, so they cannot safely guarantee rollback after a failed OTA upgrade.

1.3 Supplier fragmentation and liability

Traditional OEMs outsource most ECU hardware and software to Tier 1 suppliers. These suppliers often control:

  • The bootloader and reflashing tools.
  • Diagnostic routines and security keys.
  • Safety certifications tied to specific firmware versions.

Allowing the OEM to push OTA updates directly into supplier-owned modules raises warranty, safety, and liability concerns. This makes “whole-car” OTA politically and contractually difficult, not just technically hard.

1.4 Cybersecurity requirements are non-trivial

Full OTA implies pushing new code into safety-critical systems over public networks. A robust security stack is mandatory:

  • Secure boot and hardware root of trust (RoT).
  • Cryptographically signed and, ideally, encrypted firmware images.
  • Network segmentation between infotainment and safety domains.
  • Intrusion detection on in-vehicle networks and telematics paths.

Many existing vehicles rely on flat or weakly segmented CAN architectures that are not designed for this threat model.

1.5 Backend infrastructure is expensive to build

Hardware in the car is only half of the story. Full OTA also requires heavy backend investment:

  • Build and signing pipelines for all firmware variants.
  • Digital twin / simulation environments for testing updates before deployment.
  • Staged rollout systems (internal fleet, canary groups, regional batches).
  • Telemetry and health monitoring for update success/failure.
  • Audit logs for regulatory compliance and root-cause analysis.

OEMs that grew up around dealer reflashes and TSBs (technical service bulletins) simply do not have this infrastructure by default.

1.6 Regulatory and safety constraints

Updating safety-critical modules interacts with multiple standards and regulations, including:

  • ISO 26262 - functional safety for road vehicles.
  • ISO 21434 - automotive cybersecurity.
  • UNECE R155 and R156 - cybersecurity and software update regulations in many markets.

Full OTA is not “just a feature”; it becomes a regulated process with requirements on validation, documentation, and traceability.


Electronics & Components Required for Full OTA

At the hardware level, full OTA becomes realistic only when the vehicle’s electronics follow a modern, centralized or zonal architecture. The key building blocks are outlined below.

2.1 Central compute or domain controllers

Instead of dozens of unrelated ECUs, a modern OTA-capable platform consolidates functions into a small number of high-performance controllers:

  • Central vehicle computer (vehicle server).
  • ADAS / autonomous driving computer.
  • Infotainment / UX computer.
  • Zonal or domain controllers (body, chassis, powertrain, energy, etc.).

Typical silicon families: NVIDIA Orin / Drive, Tesla’s in-house FSD computer, Qualcomm SA8xxx automotive SoCs, Mobileye EyeQ, NXP S32G and similar.

Consolidation reduces the number of firmware images to manage and makes it practical to coordinate secure, system-level OTA updates.

2.2 Zonal architecture with high-speed network backbone

Zonal architectures replace many independent ECUs with a smaller number of “zonal controllers” connected via automotive Ethernet. Core hardware elements include:

  • Automotive Ethernet switches and PHYs (1 Gbps and up).
  • Zonal ECUs that aggregate sensors, actuators, and LIN/CAN subnets.
  • High-speed backbone network between zones and central compute.

Firmware images can then be distributed over Ethernet to zonal controllers, which in turn manage updates to local sub-modules over CAN/LIN, with better control and observability.

2.3 OTA-capable ECUs with A/B partitioned flash

At the module level, OTA requires that each critical ECU support safe update mechanisms:

  • Dual-bank NOR or NAND flash (A/B partitions).
  • A bootloader that can verify signatures and select the active image.
  • Support for atomic switch-over after successful verification.
  • Optional delta-update support to minimize bandwidth and flash wear.

If something goes wrong during update, the module can roll back to the last known-good image without losing functionality.

2.4 Hardware root of trust (RoT) and secure boot

To prevent malicious or corrupted firmware from running, ECUs and central computers must implement secure boot:

  • An immutable boot ROM or secure element that stores public keys.
  • Cryptographic verification of bootloader and OS images.
  • Hardware security modules (HSMs) or TPM-like chips for key storage.

Common building blocks: Infineon AURIX microcontrollers, NXP S32G with built-in HSM, STMicro SPC5 series with secure boot support, standalone secure elements.

2.5 Telematics control unit (TCU) with reliable connectivity

OTA depends on a robust link between the fleet backend and each vehicle. The TCU typically integrates:

  • 4G/5G modem and RF front-end.
  • GNSS receiver for positioning and timing.
  • eSIM or multi-IMSI SIM for network flexibility.
  • Secure VPN or TLS stack anchored to hardware keys.

The TCU handles download of update payloads, initial authentication, and sometimes pre-validation before handing images to in-vehicle controllers.

2.6 Power management for “update mode”

Vehicles must be able to perform updates safely even when “off” from the driver’s perspective. This requires:

  • Dedicated keep-alive power rails for critical ECUs and networking components.
  • Supervisory microcontrollers that control when modules are powered for updates.
  • Battery monitoring to avoid excessive state-of-charge (SoC) depletion during long updates.

Without this, a failed update in a low-battery state could leave modules partially flashed and non-functional.

2.7 Secure gateways and domain isolation

A modern OTA-capable vehicle uses gateway ECUs that segment the network into domains:

  • Infotainment and connectivity domain.
  • Powertrain, chassis, and braking domain.
  • Energy domain (BMS, charging, DC/DC, inverters).
  • Body controls, comfort systems, etc.

The gateway enforces firewall rules and routes OTA traffic in a controlled way, ensuring that a compromise in the infotainment stack does not directly expose safety-critical domains.


Why Only a Few OEMs Have Full OTA Today

Practically, full OTA is limited to automakers that have rebuilt both their in-vehicle electronics and their software delivery pipeline around this model. These OEMs tend to share several characteristics:

  • Centralized or zonal E/E architectures with Ethernet backbones.
  • High degree of in-house control over ECU software and bootloaders.
  • Unified software platforms across multiple vehicle lines.
  • Dedicated cloud infrastructure for CI/CD, fleet management, and telemetry.

That combination is still the exception rather than the rule, which is why most vehicles on the road only support partial OTA - usually infotainment and navigation - even when marketing claims sound broader.


Strategic Takeaways

  • Full OTA is an architectural decision, not a late-stage feature. It has to be designed into the E/E platform from day zero.
  • Hardware enablers are well understood. Central compute, zonal controllers, Ethernet, A/B partitions, RoT, and secure gateways are now standard patterns.
  • The bottleneck is organizational and ecosystem inertia. Supplier contracts, legacy tooling, and regulatory processes slow adoption more than the silicon itself.

As more OEMs migrate to centralized and zonal architectures, expect full OTA to become a baseline capability - especially for EVs and autonomy-ready platforms where software is a primary differentiator.