ISO 24089: software update engineering, explained

For most of the industry's history, changing the software in a vehicle was an event: a technician, a cable, a workshop bay. Software-defined vehicles turned it into a continuous capability — the same change may reach a production line, a dealer network and a customer's driveway, and the organisation shipping it is accountable for every copy. The regulation arrived first: UN Regulation No. 156 entered into force in January 2021 and made a Software Update Management System a condition of vehicle type approval — in the EU, approval has been refused for new vehicle types since July 2022, and from July 2024 non-compliant new vehicles can no longer be registered, sold or enter into service.

The engineering answer came two years later. ISO 24089, Road vehicles — Software update engineering, was published in February 2023 (first edition, with a minor amendment in 2024) under ISO's road-vehicles committee (ISO/TC 22/SC 32). It is deliberate about what it is not: it does not prescribe specific technologies or solutions, and the development of the vehicle-function software itself is outside its scope. What it defines is the discipline around the change — how an organisation plans, builds, verifies, distributes and documents changes to vehicle software after its initial development.

The scope is wider than most people expect. The standard specifies requirements and recommendations for software update engineering on both the organisational and the project level, and applies to vehicles, vehicle systems, ECUs, infrastructure, and the assembly and deployment of software update packages after initial development. It is not written for vehicle manufacturers alone: the scope states that the organisations involved can include manufacturers, suppliers, and their subsidiaries or partners.

The body of the standard is six requirement clauses: organisational level, project level, infrastructure level, vehicle and vehicle-systems level, software update packages, and software update campaigns. Each follows the same internal pattern — objectives, requirements and recommendations, and defined work products — which is what makes the standard auditable rather than aspirational: for every clause there is something an assessor can ask to see.

The vocabulary is precise in ways that matter. A software update campaign is the sequence of identifying targets, resolving recipients, distributing packages and monitoring and documenting the results; a software update operation is the receipt, installation and activation of a package in a vehicle, system or ECU. And the defined distribution methods are wired, wireless or hardware replacement — this is an update standard, not an over-the-air standard. A workshop reflash over a cable is governed by exactly the same engineering discipline.

UN R156 defines a Software Update Management System as a systematic approach defining organisational processes and procedures to comply with the requirements for delivery of software updates. The manufacturer's SUMS is assessed by an approval authority and receives a Certificate of Compliance valid for at most three years — and without a valid certificate, no vehicle type approval. The regulation's demands are concrete: every software version uniquely identified with integrity validation data, update authenticity and integrity protected, compatibility with the target vehicle configuration verified before delivery, and type-approval-relevant software identified by RXSWIN — readable in a standardised way at least through the OBD port, or declared to the authority instead.

One nuance is worth being precise about: R156 never mentions ISO 24089. The regulation predates the standard by two years, and a full-text search finds no ISO reference at all. The pairing of the two is established industry practice rather than a formal requirement — though it is being formalised in one direction: a UNECE task force has worked on adding ISO 24089 references and a mapping table to the regulation's interpretation document. The practical division of labour stands regardless: the regulation states what must be true; the standard describes an engineering practice for how an organisation makes it true.

ISO 24089 has exactly three normative references: ISO 26262-6 and 26262-8 — the software-development and supporting-process parts of the functional-safety standard — and ISO/SAE 21434, cybersecurity engineering. The selection is deliberately narrow: referencing two parts rather than the whole ISO 26262 series lets organisations that do not apply the full series still conform. The message in that choice is that a software update sits exactly where functional safety and cybersecurity meet: it changes safety-relevant behaviour, over a channel an attacker would love to own.

The cybersecurity coupling runs in both directions. ISO 24089 borrows the organisational-level/project-level structure that ISO/SAE 21434 established, and UN R155 — the cybersecurity sibling of R156 — explicitly catalogues threats to vehicle update procedures in its Annex 5. The update process is not just governed; it is an attack surface in its own right, which is why the engineering of updates and the securing of the diagnostic channel end up being the same programme of work.

The quietly radical part of ISO 24089 is that vehicle configuration information — the comprehensive accounting of hardware versions, software versions and configuration parameters in a vehicle — is a first-class engineering object, with named requirement subclauses at both the infrastructure level and the vehicle level. Campaign targets are determined by configuration information; recipients are resolved against it; compatibility is proven against it. You cannot campaign what you cannot enumerate — the record is not paperwork after the fact, it is the mechanism that makes a safe campaign possible.

At the ECU, the requirements become the reflashing sequence itself. The UDS services that carry an update — RequestDownload, TransferData, RequestTransferExit — are defined in ISO 14229-1's upload/download functional unit, and the same standard defines boot software as the software executing from a dedicated area of ECU memory — an area not erased during a normal programming sequence: the component that makes an interrupted update recoverable rather than fatal. R156 adds the operational guarantees for over-the-air execution — a failed update must end in a restored previous version or a safe vehicle state. We walked through that choreography, and what a production bootloader must guarantee, in the reflashing article.

The practical way into ISO 24089 is not a two-year compliance programme; it is a gap analysis. No accredited certification scheme against the standard is established — assessment bodies offer gap analyses and their own conformity certificates instead — and they structure the assessment the way the standard is structured: the organisational management level on one axis, the lifecycle of actual projects on the other, with a document review of existing procedures against the clause requirements. Most organisations discover the same thing: the update mechanism is in better shape than the update record.

That suggests the order of work. The record first — vehicle configuration information and a complete account of what was updated, where, when and with what result — because that is what both R156's auditors and ISO 24089's work products keep returning to. The process second. The platform last. The mechanism side of that equation is a solved problem: a production-grade flash bootloader with signed packages and zero units bricked since 2016 is what Autotech Bootloader has delivered in serial production, and the record side is exactly what our UN R156 readiness checklist walks through.