OTA update

An OTA (over-the-air) update delivers software to a vehicle wirelessly, without a workshop visit. The scope ranges from map and infotainment content, through feature additions and performance changes, to safety-relevant fixes — including recalls remedied entirely in software. OTA capability is the delivery mechanism that makes the software-defined vehicle more than an engineering concept: without it, software shipped at production is software frozen at production.

The industry convention distinguishes SOTA (software over the air), which replaces application code and full system images, from FOTA (firmware over the air), which reflashes embedded controllers. Tesla normalized the full-vehicle version of both from 2012 onward, updating everything from user interface to braking behavior across its fleet; the rest of the industry has been building comparable pipelines since.

How an OTA pipeline works

Technically, OTA capability depends on more than a modem. In the vehicle, updatable systems typically use A/B partition schemes: the new software is written to an inactive partition while the vehicle runs on the active one, verified, and switched over — with fail-safe rollback to the previous version, because an update must never leave a car undrivable. Reflashing dozens of controllers behind a central compute gateway, on batteries rather than bench power, within a window the customer accepts, is a systems-engineering problem of its own; consolidated architectures reduce it by shrinking the number of independently updatable targets.

On the backend, an update campaign system decides which vehicles receive which software: managing hardware and configuration variants across a fleet, staging rollouts, monitoring for anomalies and halting distribution when telemetry shows a problem. Security runs through the whole chain — updates are signed, verified in the vehicle, and protected against rollback and substitution attacks. Uptane, an open framework designed specifically for securing automotive updates against compromised infrastructure, is the reference design in this space and has shaped both commercial products and regulatory expectations. Finally, the pipeline must prove state: an OEM has to know, verifiably, which software version every vehicle in the fleet runs — a requirement that regulation has made explicit.

What gets updated

In practice OTA scope forms a ladder. The lowest rungs — map data, media apps, voice assistants — carry little risk and shipped wirelessly years before the SDV term existed. The middle rungs change vehicle behavior: energy management, chassis tuning, driver-assistance improvements, and features activated after purchase. The top rung is safety-relevant correction — fixing a defect that would otherwise require a physical recall. Field experience shows the difference in cycle time: a software remedy can reach an entire fleet in days, where a hardware campaign takes months and depends on owners bringing vehicles in. Regulators in major markets now routinely record recalls whose remedy is an OTA update, which has also sharpened the debate about when a software fix genuinely closes a safety issue versus merely mitigating it.

Regulation: R156, SUMS and type approval

Regulation moved early here. UNECE R156 requires manufacturers to operate a certified software update management system (SUMS) — audited processes covering how updates are developed, assessed, approved, delivered and documented — and applies alongside UNECE R155, its cybersecurity counterpart. In force since 2021 and phased in for new vehicle types in the EU and other adopting markets from 2022, R156 turned the update pipeline from an engineering asset into a regulated system.

The sharpest consequence concerns type approval. A vehicle is approved in a specific configuration, and software is part of that configuration; R156 obliges the manufacturer to assess, before deployment, whether an update affects any type-approved system. An update that changes approved behavior — braking, emissions, driver assistance — can require an extension of the approval before it may be pushed. This is why OEMs maintain software configuration records per vehicle, and why we can ship it and we may ship it are different questions in an automotive release process. Markets that did not adopt the UNECE regime, notably the United States, rely instead on self-certification and recall law — one reason update cadence can differ for the same vehicle across regions.

The business dimension

OTA is the delivery channel for the SDV business model. Features on demand, subscriptions and post-sale upgrades all presuppose a trusted path to install and revoke software in the field; the same channel carries the data that tells an OEM which features are actually used. The cost side is at least as significant: warranty and recall campaigns resolved in software rather than workshops, and quality issues corrected fleet-wide before they become brand damage. For the vehicle OS programs, the update pipeline is a core control point — whoever operates it owns the change process for the product.

Current state and what to watch

As of 2026, OTA capability is effectively standard on new platforms from major OEMs, but depth varies widely: many vehicles can update infotainment while only the newest architectures update every domain. The gap between fleet leaders shipping monthly full-vehicle releases and programs still counting updates per year remains one of the clearest measures of SDV maturity. Worth watching: how regulators handle increasingly frequent behavior-changing updates within the R156 and type-approval framework, whether software recalls keep growing as a share of total recalls, and how long OEMs commit to updating vehicles after sale — the industry’s answer to the question of software support lifetime is still unsettled.