ISO 24089 (Road vehicles — Software update engineering), explained

ISO 24089:2023, "Road vehicles — Software update engineering," is the engineering-process standard behind every workshop flash and over-the-air (OTA) campaign a vehicle manufacturer runs. Published in February 2023 by ISO/TC 22/SC 32 and amended once in 2024, it does not say which update technology to use; it specifies what an organization, a project, the supporting infrastructure, the vehicle itself, and the update package and campaign each have to get right so that a software update stays safe, secure and traceable. It is the standard most often cited as the practical "how" behind UN Regulation No. 156's legal "what."

What it actually covers, and what it deliberately doesn't

Per Clause 1 (Scope), ISO 24089 "specifies requirements and recommendations for software update engineering for road vehicles on both the organizational and the project level." It applies to "vehicles, vehicle systems, ECUs, infrastructure, and the assembly and deployment of software update packages after the initial development," and to "organizations involved in software update engineering for road vehicles," explicitly naming "vehicle manufacturers, suppliers, and their subsidiaries or partners" as in scope — not just OEMs.

Two exclusions matter as much as the inclusions. First: "the development of software for vehicle functions, except for software update engineering, is outside the scope of this document" — ISO 24089 governs how an update is engineered and delivered, not how the underlying vehicle feature is designed (that is ISO 26262 and ISO/SAE 21434 territory). Second: "this document does not prescribe specific technologies or solutions for software update engineering" — it is a process standard, solution-neutral by design, covering wired, wireless and hardware-replacement updates alike rather than just OTA.

The five normative clauses

The standard's own Introduction summarizes its activities as: implementing organizational-level processes; implementing project-level processes per update project; defining vehicle and infrastructure functions to support those processes; assembling update packages using infrastructure functions; and preparing and executing update campaigns using vehicle and infrastructure functions. That maps directly onto five requirement clauses, each closing with a "Work products" subclause listing the records the clause expects:

Clause	Level	What it requires
4 — Organizational level	Organization-wide	Governance, continuous improvement, information sharing, supporting processes (document, configuration, requirements and quality management), and auditing
5 — Project level	Per software-update project	Project management (plan, roles, responsibilities), tailoring and rationale for any deviation, interoperability between infrastructure and vehicle functions, and integrity of software/metadata/packages
6 — Infrastructure level	Organization's systems and tools	Managing cybersecurity and other risk, managing vehicle configuration information, communicating software-update-campaign information, and processing software update packages
7 — Vehicle and vehicle systems level	On-vehicle, in the ECUs	The same four requirement groups as Clause 6, implemented in the vehicle rather than the back-office infrastructure
8 — Software update package	The deliverable artifact	Identifying targets and package contents, assembling the package, verifying and validating it, and approving it for release
9 — Software update campaign	The delivery event	Preparation, execution and completion of a campaign that resolves targets into actual recipients, delivers packages, and documents results

A reading note from NIST's Suzanne Lightman, who reviewed the draft text for the UPTANE project in 2022, is worth repeating for anyone approaching the document for the first time: "print out clause 3 — definitions — and keep it with you when reading this document," since the standard builds its own precise, document-specific vocabulary (condition, recipient, safe vehicle state, software update campaign, and so on) that later clauses rely on without re-explaining.

Built on, not instead of, functional safety and cybersecurity engineering

Clause 2 lists exactly three normative references: ISO 26262-6 (software-level product development), ISO 26262-8 (supporting processes), and ISO/SAE 21434 (cybersecurity engineering). ISO 24089 does not duplicate those standards' requirements — several of its own definitions are marked as modified quotations from them. Its "cybersecurity" term, for example, is sourced from "ISO/SAE 21434:2021, 3.1.9, modified" to apply to "vehicle systems of road vehicles and infrastructure required to support software update engineering" rather than to vehicle items generally. Per Lightman's summary, requiring conformance with all three "should ensure that all code and hardware is developed with proper attention to safety and cybersecurity" before Clause 4's organizational processes even begin — ISO 24089 governs the update engineering layered on top, not a substitute safety or cybersecurity process.

How it relates to UN R156

UN R156, the UN vehicle regulation that makes a certified Software Update Management System (SUMS) a type-approval condition, is law; ISO 24089 is a voluntary engineering standard. ISO 24089's own Introduction explains the practical need it answers: with rising update frequency and both workshop and OTA delivery in use, "the establishment and application of software update engineering is important to ensure software quality, cybersecurity, and safety." Manufacturers commonly use ISO 24089 to design and evidence the SUMS processes a UN R156 type-approval audit checks, the same relationship ISO/SAE 21434 has to UN R155's CSMS requirement — see UN R155, UN R156 and ISO/SAE 21434 explained for the regulation's binding EU dates. No independently confirmed Official Journal or UNECE text naming ISO 24089 as automatically satisfying UN R156 was found for this guide; treat formal-equivalence claims as to be confirmed with your type-approval authority, and note that organizations that build updates but do not themselves distribute them to vehicles on the road were, per Lightman's account of the standard's development, a specific point of debate in the Clause 5 tailoring provisions.

The 2024 amendment

ISO 24089:2023/Amd 1:2024 is the one published amendment so far. Public secondary summaries describe two changes: a new "tool" definition in the terminology clause (devices such as a laptop or vehicle diagnostic device used to carry out update operations), and a strengthened clause 5.3.4 integrity requirement calling for documented processes to preserve the integrity of software, metadata and update packages specifically during distribution. This guide has not purchased the amendment's own text, so treat the precise clause wording as to be confirmed against the amendment itself; the substance is consistent with the base standard's existing emphasis on integrity as a named Clause 5 requirement area.

A workable starting point

1. Read Clause 3 before anything else — the standard's terms (condition, recipient, safe vehicle state, in-vehicle resource, software update campaign) are precisely defined and used consistently; skipping the glossary makes Clauses 4-9 hard to follow correctly.
2. Separate organizational process work (Clause 4) from per-project work (Clause 5) — a governance policy, audit cadence and supporting-process set exist once; a plan, tailoring rationale and interoperability check happen for every update project.
3. Decide what lives in infrastructure vs. on-vehicle early — Clauses 6 and 7 require the same four capability groups (risk, configuration information, campaign communication, package processing), but many requirements explicitly allow either location or both; architecture decisions here shape your whole SUMS.
4. Treat the package and the campaign as separate work products — Clause 8's verification/validation and release approval happen before Clause 9's campaign preparation starts; conflating the two makes rollback and safe-vehicle-state logic harder to audit.
5. Pair ISO 24089 with ISO/SAE 21434 and the ISO 26262 parts it cites — it assumes, rather than re-specifies, the functional-safety and cybersecurity engineering of the underlying vehicle software. See ISO/SAE 21434 cybersecurity engineering explained for that standard's own structure.

SoftWSP's firmware and device assessments can evidence the vehicle-system and infrastructure-level integrity and configuration-management controls ISO 24089 calls for in Clauses 6-8: see Device & Firmware Security.

This guide summarises ISO's own published preview text of ISO 24089:2023, its catalogue record, and independent secondary analysis of the standard; it is not a substitute for the purchased ISO text and does not constitute compliance or legal advice.