ISO 24089 explained: software update engineering

What ISO 24089 is

ISO 24089:2023, "Road vehicles — Software update engineering", is the international standard that defines how vehicle software updates are engineered across the lifecycle. It is the software-update counterpart to ISO/SAE 21434, which does the same job for cybersecurity engineering. Where UN R156 is a regulation that states what a Software Update Management System must achieve, ISO 24089 is an engineering standard that describes how to build and run the processes that achieve it.

The relationship is the same one that holds between UN R155 and ISO/SAE 21434: the regulation sets the obligation and the standard supplies the substance. R156 will tell an assessor that your updates must be safe, traceable and recorded. ISO 24089 is where the engineering practices that make those things true — repeatably, and with evidence — actually live.

Two levels: organisational and project

ISO 24089 structures software update engineering at two levels, and understanding the split is the key to using the standard well.

Level	What it establishes	Example concerns
Organisational	The standing capability to do software updates	Update infrastructure, roles and responsibilities, policies, competence
Project	Applying that capability to a specific update or campaign	Package engineering, delivery, installation, verification, records for this release

The organisational level is the capability you build once and maintain: the infrastructure, the defined roles, the policies and the competence that let you do updates at all. The project level is what you do each time you actually release an update — engineer the package, deliver it, install it, verify it, record it. A mature programme has both. A common weakness is a strong project-level ability to ship a given update with no documented organisational capability behind it, which leaves the manufacturer unable to show the update process is systematic rather than heroic.

What it engineers

Reading across the update lifecycle, ISO 24089 addresses the things a SUMS has to get right in practice: the infrastructure that produces and distributes updates; the engineering of the update package itself, including its integrity and its dependencies; the delivery and installation on the vehicle under safe conditions; and the verification and records that show each of these worked. It is deliberately process-focused rather than prescriptive about architecture — it tells you what has to be engineered and evidenced, not which specific technology to use.

This is why the standard maps so cleanly onto R156's requirements. The regulation's demands for configuration identity, integrity, safe installation and records each correspond to an area of engineering that ISO 24089 lays out.

Where it meets rollback and recovery

One area where the standard earns its place is the handling of update failure. R156 requires that updates fail safely, but it does not tell you how to design and verify that behaviour. ISO 24089 provides the engineering discipline: how failure modes are identified, how safe-states and recovery paths are specified, and how they are verified before a campaign is released. We treat this specific intersection in rollback, recovery and integrity; the general point is that ISO 24089 is what lets a manufacturer move from asserting that an update fails safely to demonstrating it with test evidence.

How it supports the SUMS

For a manufacturer, the practical value of ISO 24089 is that it produces the artefacts a SUMS assessment needs. Building the update capability on the standard means the process descriptions and records the assessor traces are generated as a natural output of the engineering, rather than reconstructed afterwards to satisfy an audit. The organisational-level processes give you the documented capability; the project-level processes give you the per-release records. Together they populate the SUMS document set that R156 assessment examines, which we set out in SUMS documentation.

Is it mandatory?

No. ISO 24089 is a standard, not law, and R156 does not legally require its use. But the situation mirrors ISO/SAE 21434 under R155: the standard is the practical basis on which most compliant evidence is built, because it structures the engineering to produce exactly what the regulation asks you to demonstrate. A manufacturer is free to meet R156 by another route, but it would be building the same evidence from scratch, and would have to justify why its home-grown process is equivalent. In practice, aligning to ISO 24089 is the path of least resistance to a defensible SUMS.

ISO 24089 and ISO/SAE 21434 together

The two standards are complementary rather than overlapping. ISO/SAE 21434 engineers cybersecurity across the lifecycle and underpins R155; ISO 24089 engineers software updates and underpins R156. An OTA channel touches both — it is a cybersecurity attack surface under 21434 and R155, and a software-update mechanism under 24089 and R156. Treating the two standards as one engineering programme, rather than two disconnected compliance exercises, is how serious manufacturers avoid building the same evidence twice. We cover the cybersecurity side in ISO/SAE 21434 explained.

The AutoSifu view

We use ISO 24089 as the engineering backbone of R156 and AIS-190 work, so the SUMS evidence is a by-product of doing the update engineering properly rather than a separate documentation exercise. On one route we align the organisational and project processes to the standard, build the update capability, and prepare the CoC and VTA evidence. With CIRT working alongside us, the approval body sees the engineering as it takes shape, and the standard's artefacts arrive at assessment already recognisable to the assessor.