UN R156 explained: the SUMS and why OTA needs its own regulation

What UN R156 is

UN R156 is the UNECE regulation on software updates and the Software Update Management System. It sits beside UN R155 (cyber security) under the 1958 Agreement administered by WP.29, and the two are almost always carried as a pair. Where R155 asks whether you can manage cyber security risk across the lifecycle, R156 asks a narrower and more mechanical question: can you change the software in a vehicle after it has left the factory without losing control of what that software is, and without introducing a safety or regulatory problem in the process.

Approval under R156 has two parts. The manufacturer holds a Certificate of Compliance for its SUMS — proof that the management system exists and functions — and then, on top of that, obtains a per-vehicle-type approval that ties specific software to that type. You cannot get a type approval without a valid SUMS certificate behind it. This mirrors the R155 structure, where the CSMS certificate is a precondition for vehicle-type approval.

Why software updates needed their own regulation

Type approval was built around the idea that a vehicle is a fixed thing. You certify a configuration once and it stays certified. Over-the-air and workshop updates broke that assumption. A vehicle that can update itself can, in principle, change a braking calibration, a driver-assistance parameter or a regulated emissions function long after any inspector last saw it.

Two problems follow. First, the software identity approved at type approval can silently drift from what is actually running in the field. Second, the update channel itself becomes a way to push a bad or hostile change to an entire fleet at once. R156 answers both. It requires the approved software of a type to be identified and tracked through the RxSWIN, and it requires the update process to protect the integrity of the software and to fail safely.

The RxSWIN, in one paragraph

The RxSWIN — Regulation X Software Identification Number — is the thread that holds the whole thing together. It identifies the R155/R156-relevant software of a vehicle type, it must change when that relevant software changes, and it is declared in the type approval. When an update alters regulated software, the RxSWIN is updated and, depending on what changed, the type approval may need to be extended before the update can be released. We treat RxSWIN in depth in RxSWIN explained; here it is enough to know that R156 without RxSWIN discipline is not R156 compliance at all.

What the SUMS actually has to do

The SUMS is the management system that makes all of this repeatable. At assessment, the manufacturer has to show that it can, for every update:

SUMS obligation	What it means in practice
Identify software	Know the current software configuration of each type and each affected vehicle, via RxSWIN and version records
Assess an update	Determine whether the update affects type-approval-relevant functions and whether an approval extension is needed
Protect integrity	Ensure the update reaching the vehicle is authentic and unaltered from what was built and signed
Execute safely	Deliver and install under safe pre-conditions, with a defined behaviour if the update fails
Keep records	Retain evidence of what was updated, when, on which vehicles, and with what outcome
Inform the user	Where relevant, tell the vehicle user what the update does and any conditions attached

None of these is optional, and none is satisfied by a written procedure alone. The approval authority looks for records that show the process actually ran on a real programme — the same evidence-over-description standard that governs an R155 audit.

OTA is not the trigger

A common and expensive misreading is that R156 only bites if you do over-the-air updates. It does not. The SUMS requirement applies whenever a vehicle type can be updated at all, including updates carried out at a dealer or workshop through a diagnostic tool. The difference between OTA and workshop updates is in the delivery mechanism and its controls, not in whether the SUMS is required. If your vehicle can be reflashed in service, you need a SUMS, RxSWIN management and update records. We cover this case directly in the non-OTA article for teams that assumed they were out of scope.

How R156 relates to R155 and to ISO 24089

R156 and R155 overlap but are not the same. R155 governs the cyber security management system and the vehicle's resistance to attack; R156 governs the software update process and configuration identity. An OTA channel is simultaneously a cyber security concern under R155 (it is an attack surface listed in Annex 5) and a software-update concern under R156 (it must preserve integrity and configuration). A serious programme designs the two together rather than treating them as separate files.

Underneath R156 sits ISO 24089:2023, "Road vehicles — Software update engineering". The regulation says what must be true; ISO 24089 provides the organisational and project-level engineering processes that make it true and repeatable. Using it is not legally mandatory, but it is the practical basis on which most SUMS evidence is built.

What an assessor checks

At a SUMS assessment the authority is looking for a small number of concrete things: that you can state the software configuration of a type and prove it; that your RxSWIN changes when regulated software changes; that updates are integrity-protected end to end; that there is a defined safe behaviour and recovery path when an update fails; and that you hold records showing all of this happened on an actual release, not just in a template. Gaps here look exactly like the gaps that stall a first R155 assessment — a process described but never evidenced.

The AutoSifu view

We take a SUMS from process design to assessment on one route: compliance mapping against R156 and AIS-190, the update-workflow and RxSWIN solutioning that makes the process real, and the CoC and VTA support that gets it certified. Because CIRT works alongside us, the approval body is in the room while the SUMS is being built rather than meeting it for the first time at audit. That is how a first R156 assessment becomes predictable instead of a surprise.