UN R156 compliance: what the SUMS actually requires

UN Regulation No. 156 was adopted by the UNECE's World Forum for Harmonization of Vehicle Regulations (WP.29) in June 2020, together with its cyber-security sibling UN R155, and both entered into force on 22 January 2021. R155 governs the cyber-security of the vehicle and the organisation behind it; R156 governs how software reaches a vehicle — over the air, over a workshop cable, or by hardware replacement. Its central instrument is the Software Update Management System: a systematic approach defining the organisational processes and procedures that must be in place before an organisation changes the software in a vehicle it has type-approved.

The teeth are in type approval. 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 there is no vehicle type approval. In the EU the enforcement dates come from the General Safety Regulation rather than from R156 itself: approval has been refused for new vehicle types since July 2022, and since July 2024 non-compliant new vehicles can no longer be registered, sold or enter into service.

Stripped of regulatory prose, R156's demands are concrete. Every software version must be uniquely identified, with integrity validation data so a tampered image can be detected. The authenticity and integrity of every update must be protected. Compatibility with the target vehicle configuration must be verified before an update is delivered — not discovered after it fails. And type-approval-relevant software is identified by RXSWIN, the RX Software Identification Number: a dedicated identifier, defined by the vehicle manufacturer, that must be easily readable in a standardised way, at least through the OBD port — or, where RXSWINs are not held on the vehicle, declared to the approval authority instead.

Two further requirements shape the engineering. The process must record every update carried out — which software, which vehicle, what result — because the record is what the authority audits. And for over-the-air execution the regulation adds an operational guarantee: a failed update must end in a restored previous version or a safe vehicle state. Recovery is a compliance requirement, not a product feature.

The uncomfortable discovery for many organisations is that the hard part of R156 is not the update mechanism — it is the record. Most engineering teams can move a signed image into an ECU; far fewer can prove, for every unit in a fleet and across years of production and workshop history, which software ran on which vehicle, when it changed and on whose approval. That proof is a diagnostics discipline: the same baseline and traceability thinking that end-of-line programming and workshop reprogramming have always needed, now made a condition of selling the vehicle.

The precondition is what ISO 24089 calls vehicle configuration information: the comprehensive accounting of hardware versions, software versions and configuration parameters in each vehicle. Campaign targets are determined by it, 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.

UN R156 states what must be true; ISO 24089, published in February 2023, describes an engineering practice for how an organisation makes it true — from organisational and project processes down to packages and campaigns. One nuance is worth being precise about: R156 never mentions ISO 24089. The regulation predates the standard by two years, and the pairing of the two is established industry practice rather than a formal requirement — though a UNECE task force has worked on mapping the standard into the regulation's interpretation document.

That also sets the realistic entry path. No accredited certification scheme against ISO 24089 is established; assessment bodies offer gap analyses and their own conformity certificates instead. The order of work that assessment experience keeps suggesting: the record first, the process second, the platform last.

At the ECU, R156's requirements become the reflashing sequence itself. The UDS services that carry an update — RequestDownload, TransferData, RequestTransferExit — are defined in ISO 14229-1, and the component that makes an interrupted update recoverable rather than fatal is the resident flash bootloader, which validates the application at every boot and never erases itself. We walked through that choreography, and what a production bootloader must guarantee, in the reflashing article. A bootloader and its tooling are built to support that process — supporting a regulation is not a claim of certification.

For a supplier, evidence-ready has a concrete shape: signed software packages verified before an application is marked valid, an update chain whose gates hold end to end, and tooling that produces the traceability record the manufacturer's audit will ask for. That is the standard Diadrom holds its own products to — Autotech Bootloader has run in serial production with signed packages and zero units bricked since 2016 — and the record side is exactly what our UN R156 readiness checklist walks through.