UNECE UN Regulation No. 156 (UN R156): UNECE UN Regulation No. 156 – Tutorial (about 60 minutes)

UN Regulation No. 156 (UN R156) is the international vehicle regulation that decides whether a manufacturer may change the software of its vehicles after they have been approved, and how. It is written by the United Nations Economic Commission for Europe (UNECE) and is mandatory in many markets, including the European Union. Vehicle manufacturers, their suppliers, approval authorities and technical services work with it every day. After this tutorial you will be able to explain what the regulation demands of the organisation and of the vehicle, follow an update from idea to installed software, and recognise what an assessor will ask to see.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: UN R156 was adopted by the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) in June 2020 and entered into force on 22 January 2021 (the original "00 series"). A 01 series of amendments, which updates the provisions on RX software identification numbers (RXSWIN), was adopted by WP.29 at its 197th session (November 2025) and has been binding on the contracting parties that apply R156 since 4 June 2026 (UN depositary notification C.N.237.2026). Like every new series, it contains transitional provisions for approvals granted to the original series. An interpretation document (ECE/TRANS/WP.29/2021/60) explains the requirements, and a 2025 update to it (ECE/TRANS/WP.29/2025/45) maps them to ISO 24089:2023. Work on related amendments continues in the GRVA working party. This tutorial teaches the requirements common to both series and points out where the 01 series differs; always check the consolidated text in force for your approval. Verified 2026-10-29.

Who it is for: engineers, software release managers, homologation and compliance specialists, quality and cybersecurity staff, and supplier teams who are new to UN R156 and need a solid, accurate foundation. Prerequisites: none. A general idea of how cars contain many electronic control units helps, but every term is explained.

By the end of this course:

You will be able to explain why UN R156 exists, where it applies and which vehicles it covers.
You will be able to define the core vocabulary, including SUMS, RXSWIN, integrity validation data, execution, safe state and over-the-air update.
You will be able to describe the structure of the regulation and the difference between its organisational and vehicle-level requirements.
You will be able to walk a software update through the decisions and records that the regulation expects.
You will be able to explain the two approvals involved, who grants them, how long they last and how they are kept valid.
You will be able to position UN R156 against UN R155, ISO 24089, ISO/SAE 21434 and other related documents.

Lesson 1 – Origins, purpose and scope

Why software updates needed a regulation

For most of the history of the car, a vehicle that left the factory stayed technically the same for its whole life unless a workshop replaced a part. Type approval was built on that assumption. An authority examined a representative vehicle, confirmed that its brakes, lights, steering and emissions met the rules, and then allowed identical vehicles to be sold. If the manufacturer changed something important, it had to come back to the authority and ask for the approval to be extended.

Software broke that assumption. A modern car carries dozens of electronic control units (ECUs), each running software that shapes how the vehicle brakes, steers, charges, warns the driver or keeps its lane. Manufacturers can now change that software in a workshop with a diagnostic tester, or remotely over a mobile network. A single release can alter the behaviour of hundreds of thousands of vehicles overnight. That is a huge benefit: bugs and security holes can be fixed quickly and recalls become cheaper. But it also raises hard questions. How does an authority know that a vehicle on the road still matches what was approved? What happens if an update fails halfway on a motorway? Who decides whether a change is small enough to ship without a new approval? How can an attacker be stopped from pushing malicious software through the same channel?

Regulators answered these questions together with the industry in the UNECE framework. A task force on cybersecurity and over-the-air issues prepared two companion texts, which WP.29 adopted in June 2020: UN R155 on cybersecurity and UN R156 on software updates. Both entered into force in January 2021. R155 asks whether the manufacturer manages cyber risk; R156 asks whether it manages change to vehicle software in a controlled, traceable and safe way.

How UN regulations become law

UN R156 is attached to the 1958 Agreement, a treaty under which countries ("contracting parties") adopt common technical regulations and recognise each other's type approvals. A contracting party that applies R156 appoints an approval authority, usually a ministry or national agency, and technical services that carry out tests and assessments on its behalf. An approval granted in one applying country is accepted by the others. Countries that are not parties to the 1958 Agreement, such as the United States, are not bound by it.

In the European Union the regulation became binding through the General Safety Regulation, Regulation (EU) 2019/2144. It applied to new vehicle types from July 2022 and to all newly registered vehicles from July 2024. Other contracting parties, for example Japan, apply it under their own national law and timetable. Because those timetables differ, a manufacturer selling worldwide must keep a market-by-market view of where R156 is required.

Scope

The regulation applies to vehicles of categories M (passenger vehicles such as cars and buses), N (goods vehicles such as vans and trucks), O (trailers), R (agricultural trailers), S (interchangeable towed agricultural machinery) and T (agricultural tractors) that permit software updates. The last condition matters: a vehicle in one of these categories that cannot have its software changed falls outside the regulation. Agricultural and forestry vehicles (R, S and T) are included, which its companion R155 does not cover. In the other direction, R155 covers some L-category vehicles, while the R156 scope does not list two-wheelers or other L-category vehicles.

The regulation covers both ways of updating: over the air and by wire in a workshop or at the end of the production line. All updates must go through the manufacturer's managed process; over-the-air updates carry additional requirements because no technician is present to keep the vehicle and its occupants safe.

Purpose in one sentence

The goal is that every change to vehicle software is known, assessed for its effect on safety and approval, protected against manipulation, delivered and installed safely, and recorded so that the authority can always tell what software a vehicle runs and whether the vehicle still conforms to its approvals.

Figure 1 – Who writes UN R156, who applies it and who grants the two approvals a manufacturer needs.

Figure 1 shows the institutional picture. WP.29 adopts the text, prepared by its Working Party on Automated/Autonomous and Connected Vehicles (GRVA). Each contracting party that applies the regulation appoints its own authority and technical services. The manufacturer deals with one authority of its choice among the applying countries, and the approvals it receives are recognised by the others.

Lesson 2 – Key concepts and vocabulary

UN R156 uses a small set of terms precisely. Getting them right avoids most misunderstandings in audits and supplier discussions. The explanations below are paraphrased; consult the regulation for the exact definitions.

Software – the digital part of an electronic control system: the instructions and data that make it behave as it does. Configuration parameters, such as calibration values, are among the things an update can change.
Software update – a package used to move software to a new version, which may include a change to configuration parameters. Changing a parameter value without new code can therefore still be a software update.
Execution – the step of installing and activating an update that has already been downloaded to the vehicle. The regulation separates delivery from execution because the risks differ: downloading can happen while driving, activation often cannot.
Software Update Management System (SUMS) – the manufacturer's systematic set of organisational processes and procedures for delivering updates in line with the regulation. It is an organisational capability, not a piece of software.
RX Software Identification Number (RXSWIN) – an identifier, defined by the manufacturer, that represents the software relevant to the type approval of a vehicle under a given UN Regulation "X". For example, an RXSWIN for steering would refer to UN R79. It is not simply a version number; it stands for the approved software set.
Integrity validation data – values such as checksums or cryptographic hashes that let anyone compare a piece of data with a reference and detect errors or changes.
Over-the-air (OTA) update – any update that transfers data wirelessly rather than through a cable or other local connection.
Vehicle user – a broad term covering the driver or operator, the owner, a fleet manager's or the manufacturer's representative, or a technician authorised to act on the vehicle.
Safe state – an operating mode the vehicle can enter after a failure in which no unreasonable risk remains, for example a parked, immobilised vehicle with the previous software still usable or a limited but safe function set.
System – a set of components or subsystems that together perform one or more functions, such as a braking system or an advanced driver assistance system.
Vehicle type – vehicles that share the manufacturer's designation and do not differ in the essential features relevant to software updates.
Type approval – the formal confirmation by an approval authority that a vehicle type meets a regulation. Under R156 the vehicle type is approved "with regard to software updates", and every other UN regulation the vehicle complies with has its own approval.
Certificate of Compliance for SUMS – the document an approval authority issues once it has assessed the manufacturer's SUMS and found it adequate. It is a prerequisite for vehicle type approval under R156.
Target vehicles – the population of vehicles that a particular update is meant for, identified by their type, configuration and current software.
Last known configuration – the manufacturer's best record of the hardware and software currently fitted to a vehicle, used to check compatibility before an update is released.

Two levels: organisation and vehicle

The most important concept is that R156 works on two levels at once. At the organisational level, the manufacturer must have processes: to identify software, to assess the impact of a change, to protect the update process, to inform users and to keep records. At the vehicle level, each vehicle type must have technical properties: updates are protected for authenticity and integrity, the approval-relevant software can be identified, and over-the-air updates are executed safely. The authority checks the first level once for the whole organisation and the second level for each vehicle type. The same split exists in UN R155, which makes the two regulations easy to manage together.

Why the RXSWIN matters

Without a common identifier, a roadside inspector or an authority checking conformity would have to compare long lists of ECU part numbers and software versions with approval documents. The RXSWIN compresses this into one identifier per regulation-relevant software set. If the manufacturer changes software that is relevant to, say, the braking approval, and the change requires the approval to be extended, the RXSWIN changes too. If an update does not touch approval-relevant software, the RXSWIN stays the same even though individual ECU versions moved. That makes the RXSWIN a bridge between the engineering world of versions and the legal world of approvals.

Lesson 3 – Structure of the regulation

UN R156 is short compared with most international standards. Its body follows the usual layout of UN vehicle regulations, followed by annexes with forms and models. Knowing where things sit helps you find the right paragraph quickly.

Paragraph	Topic (paraphrased)
1	Scope: vehicle categories M, N, O, R, S and T that permit software updates
2	Definitions, including software update, execution, SUMS, RXSWIN, safe state, OTA update and integrity validation data
3	Application for approval: who applies and which documents accompany the application
4	Marking: the international approval mark and its approval number
5	Approval: conditions for granting vehicle type approval, including the check on a sample vehicle
6	Certificate of Compliance for the SUMS: application, assessment, validity and renewal
7	Specifications: 7.1 requirements for the SUMS, 7.2 requirements for the vehicle type
8	Modification of the vehicle type and extension of the approval
9	Conformity of production
10	Penalties for non-conformity: withdrawal of approval
11	Production definitively discontinued
12	Names and addresses of technical services and approval authorities
Annexes	Information document (with a model declaration of compliance for the SUMS), communication form, arrangement of the approval mark, model certificate of compliance

The 01 series of amendments adds transitional provisions that govern how approvals granted to the original series are treated. Read their paragraph numbers and dates from the consolidated 01-series text.

Paragraph 7.1 – what the organisation must show

Paragraph 7.1 is the heart of the SUMS assessment. It has four groups.

7.1.1 Processes. The manufacturer needs processes to document and securely hold all information relevant to the regulation and make it available to the authority; to uniquely identify software versions with their integrity validation data and the relevant hardware; to access and update RXSWIN information where RXSWINs are used and to check that installed software is consistent with them; to identify interdependencies between the updated system and other systems; to identify target vehicles and confirm compatibility with their last known configuration before release; to assess and record whether an update affects type-approved systems, adds or changes functions compared with what was approved or registered, or affects systems needed for safe operation; to inform vehicle users about updates; and to supply information to authorities for approval, conformity checks, market surveillance, recalls and periodic technical inspections.
7.1.2 Records. For every update, the manufacturer keeps documentation of the processes and of any standards used to demonstrate compliance; the configuration of affected type-approved systems before and after the update; an auditable register per RXSWIN of the software it covers before and after updates; the list of target vehicles with confirmation of compatibility; and an update description covering items such as its purpose, the systems and functions affected, whether approval-relevant, whether an approval was sought, how execution is done and confirmation that verification and validation were completed.
7.1.3 Security. The manufacturer demonstrates that updates are protected against manipulation before the update process starts, that the update processes themselves (including the systems that deliver updates) are protected against compromise, and that it verifies and validates software functionality and code.
7.1.4 Over-the-air specifics. The manufacturer shows how it ensures that an OTA update will not affect safety if it is carried out while driving, and how updates that need a skilled or complex action, such as recalibrating a sensor, can only proceed when a qualified person is present or in control.

Paragraph 7.2 – what each vehicle type must do

7.2.1 All updates. The authenticity and integrity of updates are protected so that compromise and invalid updates are reasonably prevented. Where RXSWINs are used, each one is uniquely identifiable, changes when an approval-relevant update leads to an extension or new approval, can be read in a standardised way through an electronic interface (at least the standard on-board diagnostics connector), and is protected against unauthorised modification. If RXSWINs are not stored on the vehicle, the manufacturer declares them and the related software versions to the authority and keeps the declaration current, and the software versions must be readable instead.
7.2.2 OTA updates. If an update fails or is interrupted, the system can be restored to its previous version or the vehicle can be put into a safe state. Execution only starts when there is enough power to finish, including any recovery. When execution could affect safety, the manufacturer shows by technical means that it only happens in a safe condition. Users are informed before execution about the purpose and criticality of the update, changes to functions, expected duration, functions unavailable meanwhile and instructions for safe execution; and afterwards about success or failure and what changed. When updating while driving would be unsafe, the vehicle cannot be driven during execution and the driver cannot use functions that would affect safety or the update. Preconditions defined by the manufacturer must be met before execution starts.

Figure 2 – The two halves of paragraph 7 and the approval each half supports.

Figure 2 summarises the logic; read each column from top to bottom. The four groups under 7.1 are assessed together and lead to the SUMS certificate. The two groups under 7.2 are checked per vehicle type and, together with a valid certificate, lead to the vehicle type approval.

What the 01 series changes

Under the original series, the RXSWIN requirements were written conditionally: they applied where a manufacturer chose to use an RXSWIN. Authorities and inspectors, however, need a consistent way to see which approval-relevant software a vehicle carries. The 01 series grew out of a French proposal to clarify the software identification number requirements, and it updates how RXSWINs are to be implemented. Its model declaration and model certificate now state which series of R156 they refer to, because a SUMS may need to change to meet the new series. At the same session WP.29 also adopted a template for adding RXSWIN provisions to other UN Regulations, and in 2026 working parties were still discussing how to insert such provisions into individual regulations, for example those on stability control or automated lane keeping. Because the detailed RXSWIN obligations differ between the series, read the consolidated 01-series text before you design or change your RXSWIN scheme.

Lesson 4 – How it works in practice

Reading paragraph 7 can make R156 look like a checklist. In practice, it describes a pipeline that runs every time someone wants to change vehicle software, plus a foundation of tools and roles that must exist before the first update.

Building the foundation

Before a SUMS can work, the manufacturer needs several capabilities.

A configuration database that knows, for each vehicle identification number (VIN), which ECUs, hardware versions, software versions and parameter sets are fitted. This must be kept up to date after workshop repairs, part replacements and every update. It is the source of "last known configuration".
An RXSWIN scheme that defines, for each relevant UN Regulation, which software items count as approval-relevant and how the identifier is structured and stored.
A change and impact assessment procedure with named decision makers, criteria for when an update affects an approval, and templates for recording the rationale whether the answer is "yes" or "no".
A secure build and signing chain, with keys protected in hardware security modules, separation of duties, and integrity validation data generated for every release.
A delivery back end for OTA updates and diagnostic tools for workshop updates, both protected against misuse. This overlaps strongly with the cybersecurity management system required by R155.
User communication channels: in-vehicle screens, apps, owner letters and dealer instructions.
Supplier agreements that make ECU suppliers provide software identification, dependency information, test evidence and secure bootloaders.

Roles

The regulation does not prescribe an organisation chart, but authorities expect clear ownership. Typical roles include a SUMS owner who maintains the processes; homologation engineers who judge approval impact and liaise with the authority; system owners who know each ECU's interdependencies; release managers who approve packages; campaign managers who run deliveries and can stop them; security engineers responsible for keys and the back end; and customer communication teams. Suppliers contribute evidence but the legal responsibility stays with the vehicle manufacturer, which holds the approvals.

The update pipeline

Figure 3 – The managed path of one software update through the decisions and records the regulation expects.

Figure 3 shows a typical pipeline. Let us walk through it.

1. Request. Updates arise from many sources: a field defect, a new feature, a cybersecurity vulnerability reported through the R155 monitoring process, or a recall ordered by an authority. The request is registered with an identifier and an owner.

2. Target vehicles. The team decides which vehicles need the update: by type, model year, region, equipment level and current software versions. A precise target definition avoids sending software to vehicles where it does not belong.

3. Compatibility. For each target, the team checks the last known configuration. A vehicle that had a replacement ECU fitted at a dealer may run a different hardware revision. If the configuration database is wrong, compatibility checks are worthless; this is why database quality matters so much.

4. Dependencies and safety. Engineers identify which other systems interact with the changed software. A change to a camera ECU may affect the lane keeping function, the emergency braking function and the instrument cluster. They also assess whether the update affects systems needed for safe operation, typically using the functional safety process from ISO 26262 and the cybersecurity process from ISO/SAE 21434.

5. Approval impact. This is the decision that makes R156 different from ordinary release management. The homologation engineer asks: does the update change a parameter, function or behaviour that was assessed when some UN Regulation X approval was granted? Does it add or enable a function that was not present at approval? Would test results recorded in the approval documents still be valid? If the answer is yes, the manufacturer must go to the approval authority for an extension or a new approval of that regulation before rolling the update out, and the RXSWIN for that regulation changes. If the answer is no, the decision and its reasoning are recorded. Authorities pay particular attention to "no" decisions because they are where a manufacturer could quietly change approved behaviour.

6. Verification, validation and signing. The package is tested on representative hardware and configurations, including failure cases such as power loss during installation. It is then signed so that the vehicle can check authenticity and integrity before accepting it.

7. Informing and delivering. Users are told what the update does and what to expect. Delivery happens over the air or in a workshop, possibly in waves so that early problems can be caught before the whole fleet is updated.

8. Execution. The vehicle checks preconditions, installs and activates the software, and verifies the result. If anything goes wrong it returns to the previous version or a safe state.

9. Recording. The outcome for each vehicle is reported back. The configuration database and the RXSWIN register are updated. Failed vehicles are followed up.

Over-the-air execution in the vehicle

The vehicle-side behaviour for OTA updates deserves a closer look, because it is what an assessor or technical service will test on a sample vehicle.

Figure 4 – States of a vehicle during an over-the-air update, showing that every path ends in a working or safe vehicle.

Figure 4 shows the key idea: there is no path that ends with a half-updated, unsafe vehicle. Preconditions might include the vehicle being parked with the parking brake applied, the high-voltage battery or 12-volt battery above a threshold, and no diagnostic session in progress. Designs commonly use two memory banks (an "A/B" layout) so the old software stays available until the new one is proven. These are engineering choices; the regulation sets the outcome, not the technique.

Workshop updates

Wired updates in a dealer workshop or at the end of the production line still fall under the SUMS. The same identification, impact assessment, integrity protection and record keeping apply. The difference is that a trained technician is present, so some OTA-specific vehicle requirements (such as informing the driver through the vehicle display) are handled through workshop procedures. The diagnostic tools and their access credentials must be protected as part of the update infrastructure.

Lesson 5 – Assessment, certification and compliance

UN R156 involves two separate approvals, and confusing them is a frequent source of mistakes. One concerns the organisation, the other concerns each vehicle type.

Step 1: Certificate of Compliance for the SUMS

The manufacturer (or its accredited representative) applies to an approval authority of a contracting party that applies R156. It provides a description of its SUMS and a signed declaration, following a model in the regulation, that its processes meet the requirements. The authority, often working through a technical service, assesses the processes: it reviews documents, interviews people, samples records of past updates and checks that the described processes are really used. If satisfied, it issues a Certificate of Compliance for the SUMS.

The certificate is valid for a maximum of three years. During that time the authority may verify at any moment that the SUMS still meets the requirements and may withdraw the certificate if it does not. The manufacturer must tell the authority about changes that could affect the certificate, for example a reorganisation or a new update platform, and the authority decides whether further checks are needed. At the end of the validity period, after a positive reassessment, the authority issues a new certificate or extends the existing one for another three years. Without a valid certificate, no new vehicle type approval under R156 can be granted.

Step 2: Vehicle type approval with regard to software updates

With a valid SUMS certificate, the manufacturer applies for approval of a vehicle type. It submits an information document describing how the vehicle meets paragraph 7.2: how integrity and authenticity are protected, how RXSWINs are structured and read, how OTA execution is made safe and how users are informed. The authority or technical service checks this on a sample vehicle of the type, verifying that the documented measures are really implemented, sometimes performing tests itself and sometimes witnessing tests run by the manufacturer. Typical checks include reading the RXSWIN through the diagnostic connector, attempting to install a tampered package, interrupting an update and observing recovery, and checking that the vehicle cannot be driven during an update that requires it to be stationary.

If the type meets the requirements, the authority grants approval, assigns an approval number and notifies the other contracting parties using the communication form in the annex. The regulation also defines the international approval mark: a circle around the letter "E" with the number of the approving country, together with the approval number.

Figure 5 – The order of events from SUMS assessment to vehicle type approval and ongoing surveillance.

Figure 5 shows the sequence. The order matters: the organisational certificate comes first, then the vehicle type approval, and both are followed by continuing oversight.

Keeping approvals valid

Approval is not a one-time event. Conformity of production rules mean the authority can check that vehicles and processes still match the approval, both periodically and when it has reason to. Under R156, the authority also checks the manufacturer's update decisions, in particular decisions not to notify it about an update, and may use sampling to do so. Records relating to the approval must stay available to the authority long after production of the type has ended; read the exact retention period in the regulation text. If requirements are no longer met, the approval can be withdrawn and the withdrawal is notified to other contracting parties.

Modifications and extensions

Two kinds of change are easily confused. Changing the vehicle type with regard to R156 itself, for example replacing the OTA architecture, is handled by the modification and extension procedure of paragraph 8. Updating software that is relevant to another regulation, such as steering or braking, is handled through that other regulation's approval, and the R156 processes are what detect the need and record it. In both cases the manufacturer must not decide on its own that an approval-relevant change is acceptable.

Certification versus compliance

There is no voluntary "R156 certification" that a supplier can buy for its products. The only formal outcomes are the SUMS certificate for a vehicle manufacturer and the type approval for a vehicle type, both issued by an approval authority. Suppliers support compliance by meeting contractual requirements, often written with reference to ISO 24089 and ISO/SAE 21434, but they are not themselves approved under R156. Consultants and tool vendors may run readiness assessments; these have no legal status.

Interpretation document

Because the regulation states outcomes briefly, WP.29 published an interpretation document to help authorities and manufacturers. It explains the intent behind the paragraph 7 and Annex 1 requirements and gives examples of evidence that could demonstrate them. The 2025 update adds references to ISO 24089:2023 where the standard helps to understand or implement a requirement. The interpretation document is guidance; it does not add requirements, and an authority may accept other evidence that meets the regulation.

Lesson 6 – Worked example

Ridgeway Trucks is a fictional manufacturer of medium and heavy goods vehicles (category N) selling in the European Union and several other contracting parties. Its new truck range has twelve ECUs that can be updated over the air, including the braking controller, the advanced emergency braking system, the gateway and the infotainment unit. To register the trucks in the EU, Ridgeway needs approval under R156, so it plans the work in five stages.

Stage 1: Gap analysis and design

The newly appointed SUMS owner compares Ridgeway's existing release process with paragraph 7.1. The engineering release process is solid, but three gaps appear. First, the configuration database is fed only by the factory: dealer repairs are recorded in a separate service system that is never synchronised, so the "last known configuration" of trucks in the field is unreliable. Second, there is no defined procedure for judging whether an update affects an approval; engineers have been asking the homologation team informally. Third, the OTA back end was built by a start-up partner and nobody at Ridgeway can show how signing keys are protected.

Ridgeway closes the gaps. It connects the service system to the configuration database so that every part replacement and every workshop flash updates the vehicle record. It writes an approval impact procedure with a checklist for each relevant UN Regulation, including the braking regulation and the regulation on advanced emergency braking for heavy vehicles, and names the homologation lead as the decision maker. It moves signing keys into a hardware security module operated by its own security team and, together with its R155 cybersecurity programme, threat-models the back end.

Stage 2: RXSWIN scheme

The homologation team defines one RXSWIN for each UN Regulation whose approval depends on software. For the braking regulation, the RXSWIN covers the software of the braking controller and the parameters of the trailer control function; for emergency braking, it covers the radar, camera and braking controller software sets. Each identifier combines the regulation number and a manufacturer sequence. The RXSWINs are stored in the gateway and can be read through the diagnostic connector with a standard request; they can only be written by a signed update. Because Ridgeway is applying under the 01 series, it checks the scheme against that series' RXSWIN provisions and states the series number in its SUMS declaration.

Stage 3: SUMS assessment

Ridgeway applies to an approval authority and signs the declaration. The technical service spends several days on site. It asks for the process descriptions, then picks two recent updates from the development fleet and follows their records end to end: the target list, compatibility checks, the dependency analysis, the approval impact record, the test report, the signing log and the per-vehicle results. It interviews the campaign manager about who can stop a rollout at night. It notes one observation: the user information template does not mention which functions are unavailable during installation. Ridgeway fixes the template, the authority accepts the correction, and the Certificate of Compliance is issued for three years.

Stage 4: Vehicle type approval

Ridgeway submits the information document for the truck type and presents a sample vehicle. The technical service reads the RXSWINs through the diagnostic port and compares them with the declared values. It attempts to install a package with a broken signature, which the vehicle rejects. It starts an update and cuts the 24-volt supply mid-installation; after power returns the braking controller runs its previous version and the driver display shows that the update failed. It confirms that the truck cannot be driven while an update requiring a stationary vehicle is executing. The type approval is granted.

Stage 5: Living with the SUMS

Eight months after launch, two updates are proposed in the same week.

Update A fixes a map display error in the infotainment unit. The dependency analysis shows no interaction with approval-relevant systems. The homologation lead records that no approval is affected and why. Ridgeway informs drivers through the display, delivers the package over the air in three waves, and records results. Ninety-seven per cent of trucks install successfully in the first fortnight; the remaining trucks have been parked in areas without coverage, and the campaign stays open until they are reached or brought to a workshop.

Update B changes a threshold in the emergency braking software to reduce false activations in tunnels. The impact assessment shows that the threshold is a parameter assessed during the emergency braking approval. Ridgeway therefore applies for an extension of that approval, supplies new test evidence, and only after the extension is granted does it assign the new RXSWIN and schedule the rollout. Because the update changes a safety-relevant function, execution requires the truck to be parked with the engine off, and the user information explains the change in plain language. After the campaign, the RXSWIN register shows the old and new identifiers with their software sets.

At the next conformity check, the authority samples the decisions of the past year. It looks closely at Update A and other "no impact" decisions, and it compares the RXSWIN read from a randomly chosen truck with the register. Everything matches. The worked example shows the core message of R156: the regulation does not stop manufacturers from updating vehicles; it makes them prove they know what they changed, why it was acceptable and that every vehicle ended in a known, safe state.

Lesson 7 – Relationship to other standards and frameworks

UN R156 sits in a family of regulations and standards. It is the legal requirement; most of the others are voluntary engineering documents that help meet it.

Document	Type and owner	Relationship to UN R156
UN R155 (cybersecurity and CSMS)	UN regulation, UNECE WP.29	Companion regulation adopted the same day. Requires a cybersecurity management system; the update channel is one of the assets it must protect, and security fixes are delivered through the R156 process.
ISO 24089:2023 (software update engineering)	International standard, ISO	Voluntary engineering standard describing organisational, project, infrastructure, vehicle, package and campaign requirements. Widely used to implement a SUMS; mapped to R156 in the 2025 interpretation document but not referenced by the regulation itself.
ISO/SAE 21434 (cybersecurity engineering)	International standard, ISO and SAE	Engineering standard used to implement R155. Its threat analysis covers the update infrastructure and the integrity and authenticity protections R156 asks for.
ISO 26262 (functional safety)	International standard, ISO	Provides the safety analysis and verification methods used to judge whether an update affects safe operation and to validate safe execution and recovery.
Uptane	Open security framework, Linux Foundation project	A technical design for secure OTA delivery with multiple signing roles; one way to meet the vehicle-side integrity and authenticity requirements, not a compliance scheme.
GB 44496-2024 (China)	Chinese mandatory national standard	China's own rules on vehicle software updates, closely aligned in concept with R156; relevant to manufacturers selling in China, which does not apply R156.

R155 and R156 together

Most manufacturers run R155 and R156 as one programme. They share the two-level structure (management system certificate plus vehicle type approval), the same authorities and often the same technical services. The CSMS identifies vulnerabilities; the SUMS fixes them safely. A weakness in the update channel is both a cybersecurity risk under R155 and an integrity failure under R156.

Regulation versus standard

A useful way to remember the difference: R156 says what must be achieved and is checked by an authority; ISO 24089 and ISO/SAE 21434 say how an engineering organisation can achieve it and are adopted voluntarily, often through contracts. Conformance to a standard is good evidence, but the authority judges against the regulation.

Other UN regulations

R156 is also connected to every regulation whose approval depends on software, for example those on steering, braking, emergency braking, lane keeping or automated lane keeping. Each of these approvals can be affected by an update, and the RXSWIN is the link that ties a software set to each of them.

Common pitfalls and best practices

Common pitfalls

Treating the SUMS as a tool purchase. Buying an OTA platform does not create the organisational processes, decisions and records that the authority assesses.
Unreliable configuration data. If workshop repairs and part swaps are not fed back, compatibility checks and target lists are wrong, and software reaches vehicles it does not fit.
Undocumented "no impact" decisions. Deciding informally that an update does not affect an approval leaves no evidence and is exactly what authorities sample.
Forgetting parameters. Changing calibration values without new code is still a software update and can change approved behaviour.
Ignoring workshop updates. Focusing only on OTA leaves dealer flashing tools and end-of-line programming outside the managed process.
Vague user information. Notices that do not explain purpose, duration or unavailable functions fail the user-information requirements and confuse drivers.
Leaving campaigns open-ended. Without tracking unreached vehicles, the fleet drifts into many unknown software states.

Best practices

Design the RXSWIN scheme early, together with the electrical architecture, so each approval-relevant software set is clear before type approval.
Use one authoritative configuration record for factory, workshop and OTA changes, and reconcile it regularly with what vehicles report.
Write an explicit approval impact checklist per relevant UN Regulation and record the rationale for every decision, positive or negative.
Run R155 and R156 as one programme, sharing threat analysis, key management, incident handling and audits.
Test failure paths deliberately: power loss, interrupted downloads, missing dependencies and wrong hardware variants, on every targeted configuration.
Roll out in waves with clear stop criteria and a named person who can halt a campaign at any hour.
Use ISO 24089 and ISO/SAE 21434 as the engineering backbone and flow their requirements down to suppliers through contracts.

Summary and key takeaways

UN R156 is a UNECE regulation under the 1958 Agreement that controls software updates of vehicles in categories M, N, O, R, S and T that permit updates; it is mandatory in the EU and other applying contracting parties.
It works on two levels: the manufacturer's Software Update Management System and the update capabilities of each vehicle type.
The SUMS is assessed by an approval authority and leads to a Certificate of Compliance valid for at most three years; vehicle type approval requires a valid certificate and checks on a sample vehicle.
Every update needs target identification, compatibility checks, dependency and safety analysis, an approval impact decision, security protection and records.
The RXSWIN links approval-relevant software to each UN Regulation approval; the 01 series, binding since June 2026, updates the RXSWIN provisions, so check which series your approval follows.
Over-the-air updates must inform users, check preconditions, execute only when safe and always end in a working or safe vehicle.
Authorities keep checking after approval, with particular attention to decisions not to notify them about updates.
ISO 24089, ISO/SAE 21434 and ISO 26262 are voluntary standards that help meet R156; the regulation itself is what the authority enforces.

Reflection questions

Think of a vehicle or connected product you know. Which of its software changes would you classify as affecting an approval, and what criteria would you use to decide?
Your configuration database is fed only by the factory. What could go wrong in the first year of OTA campaigns, and which processes would you add to fix it?
How would you explain to a supplier why it needs to provide software identification and dependency data even though it is not itself approved under R156?
Design the user information for an update that disables adaptive cruise control for twenty minutes while it installs. What must the driver know before and after?
If your organisation already runs an R155 cybersecurity programme, which parts of it could you reuse for the SUMS, and where would you need new processes?