UNECE UN Regulation No. 155 (UN R155): UNECE UN Regulation No. 155 – Tutorial (about 60 minutes)

UN Regulation No. 155 (UN R155) is the United Nations vehicle regulation on cyber security. Before a vehicle manufacturer can obtain type approval for a vehicle type in a country that applies it, the manufacturer must prove two things: that the company runs a certified cyber security management system, and that this particular vehicle type has been analysed, protected and tested against cyber attacks. Vehicle manufacturers, their suppliers, approval authorities and technical services all work with it. After this tutorial you will be able to explain how the regulation is built, what an approval authority expects to see, and how a manufacturer keeps a vehicle type compliant long after it leaves the factory.

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

Course overview

Edition and status: the regulation's full title is Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system. It is owned by the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) under the 1958 Agreement. WP.29 adopted it in June 2020 and it entered into force in January 2021. It is still in its original version (the 00 series): no new series of amendments has been adopted, and the text has been changed only through supplements. The most recent supplement whose entry into force we could confirm is Supplement 3, in force since 10 January 2025, which widened the scope to L-category vehicles (two- and three-wheelers and quadricycles). The UN depositary record lists three amendments to the original text, notified in 2022, 2024 and 2025, and none since. Further proposals are discussed from time to time in the GRVA working party, so check the UNECE pages before relying on this status. Verified 2026-10-29 against the UN Treaty Collection depositary record for Regulation No. 155, the EU Official Journal publication of the regulation (OJ L 2025/5, consolidated up to Supplement 3) and Commission Delegated Regulation (EU) 2025/1455. The authoritative status record is the UNECE status document for the 1958 Agreement (TRANS/WP.29/343). This course explains the regulation in its own words and does not reproduce its text.

Who it is for: engineers, architects and testers who build vehicle electronics or connected services; security, homologation, quality and compliance staff at vehicle manufacturers and suppliers; product and project managers; and anyone who has heard "R155" in a project meeting and needs a clear, accurate foundation.

Prerequisites: none. A rough idea of what an electronic control unit is, and of why connected cars can be attacked, will help. Every regulatory and security term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why UN R155 exists, which vehicles it covers and how it fits into the UNECE type approval system.
You will be able to define the core vocabulary, including CSMS, vehicle type, risk assessment, threat, vulnerability and mitigation.
You will be able to describe the two layers of the regulation: requirements for the organisation's management system and requirements for each vehicle type.
You will be able to outline the processes a manufacturer needs across the development, production and post-production phases.
You will be able to explain how an approval authority and a technical service assess compliance, and what keeps an approval valid over time.
You will be able to apply the regulation step by step to a realistic vehicle programme.
You will be able to relate UN R155 to UN R156, ISO/SAE 21434 and other neighbouring standards.

Lesson 1 – Origins, purpose and scope

Why vehicles needed a cyber security regulation

A modern car contains dozens of electronic control units (ECUs): small computers that run the engine or electric drive, brakes, steering assistance, airbags, infotainment, keyless entry and much more. These ECUs talk to each other over in-vehicle networks such as CAN and automotive Ethernet. Many vehicles are also connected to the outside world through cellular modems, Wi-Fi, Bluetooth, charging interfaces, diagnostic ports and smartphone apps, and they exchange data with the manufacturer's back-end servers. Every one of these connections is a possible way in for an attacker.

During the 2010s, security researchers publicly demonstrated that some vehicles could be manipulated remotely, for example by sending crafted messages through an infotainment or telematics unit to reach safety-relevant functions. Keyless theft using relay devices also became common. These events showed that vehicle security could no longer be left to the good intentions of each company: an attack on a vehicle can injure people, not only leak data, and a weakness in one model can affect hundreds of thousands of vehicles at once.

Governments that regulate vehicle safety asked a simple question: if a vehicle must be proven safe before it is sold, why should it not also be proven reasonably secure? The answer was developed in the UNECE forum where vehicle rules are harmonised, and it became UN R155.

Where the regulation comes from

The United Nations Economic Commission for Europe (UNECE) hosts the World Forum for Harmonization of Vehicle Regulations, known as WP.29. Despite the "Europe" in the name, its members include countries from several continents. WP.29 administers international agreements, the most important of which here is the 1958 Agreement. Countries and regional organisations that sign it are called Contracting Parties. A Contracting Party may choose which UN Regulations it applies, and when it does, it accepts approvals granted by other Contracting Parties under the same regulation. This mutual recognition is the main benefit: a manufacturer approved once can sell in many markets.

Technical work on cyber security was carried out by a task force reporting to GRVA, the WP.29 working party responsible for automated, autonomous and connected vehicles. The resulting texts were adopted in June 2020 as two sister regulations: UN R155 on cyber security and UN R156 on software updates. Both entered into force in January 2021.

What the regulation requires, in one paragraph

UN R155 is short compared with many technical standards, and it does not tell engineers which algorithms or architectures to use. Instead it sets outcome-oriented requirements in two layers. First, the manufacturer must operate a cyber security management system, a set of organisational processes covering the whole vehicle lifecycle, and must hold a certificate showing that an approval authority has assessed it. Second, for each vehicle type submitted for approval, the manufacturer must show that the risks to that type have been identified, assessed and reduced with suitable measures, that the measures were tested, and that attacks can be detected and analysed. Only when both layers are satisfied can the vehicle type receive its R155 approval.

Scope

The original text covered passenger vehicles and buses (category M) and goods vehicles (category N), trailers (category O) only when fitted with at least one ECU, and the heaviest light vehicles (L6 and L7) only when equipped with automated driving functions from level 3 upwards. Supplement 3 extended the scope to L-category vehicles (two- and three-wheelers and quadricycles) in general. Agricultural tractors, mobile machinery and stand-alone tools are not covered. The regulation states that it does not override other rules on data protection, privacy, or access to vehicle data and functions by authorised parties such as independent repairers.

Where it is mandatory

A UN Regulation is legally binding only where a Contracting Party has chosen to apply it, either directly or by referring to it in its own law. The European Union made R155 compulsory through its General Safety Regulation: from July 2022 for new vehicle types and from July 2024 for all newly registered cars, vans, trucks and buses. In 2025 the EU also adopted a delegated act, Delegated Regulation (EU) 2025/1455, that brings R155 into its type approval framework for L-category vehicles, applying to new L-category types from December 2027 and to existing types from June 2029. Japan applies R155 as well, and other Contracting Parties have followed. Some large markets are not part of the 1958 Agreement system: the United States uses self-certification and has no equivalent type approval requirement, while China has issued its own mandatory national standard on vehicle cyber security, which took effect in January 2026 and covers similar ground. For a global manufacturer, R155 is therefore the backbone of compliance, but not the whole picture.

Lesson 2 – Key concepts and vocabulary

Regulatory texts use words precisely. The definitions below are explained in our own words; when you read the official text you will find each one in the definitions section or in the type approval vocabulary that all UN Regulations share.

Type approval – the procedure by which a government body certifies that a design of vehicle, system or component meets the applicable rules before it is placed on the market. Approval is granted to a type, not to each individual vehicle.
Vehicle type – the group of vehicles that the manufacturer submits for approval and that do not differ in essential respects. For R155, the key attributes are the manufacturer's designation of the type and the essential aspects of the electrical and electronic architecture and external interfaces that matter for cyber security.
Cyber security – in the regulation's sense, a state in which a vehicle and the functions it performs are safeguarded against cyber threats that target its electrical and electronic parts.
Cyber security management system (CSMS) – the manufacturer's organised, risk-driven way of working: the processes, the people responsible and the oversight it uses to handle cyber risks to its vehicles and defend them against attacks.
System – a set of components or sub-systems that together perform one or more functions, for example a telematics unit with its antenna, modem and software.
Development phase – the period before a vehicle type receives approval.
Production phase – the period during which vehicles of the type are being built.
Post-production phase – the period after production of the type has ended, up to the end of life of all vehicles of the type that are still in use. Security obligations do not stop when the factory stops.
Threat – something that could set off an unwanted event and lead to damage for a system, a company or a person, for example spoofed messages sent to a vehicle.
Vulnerability – a flaw in an asset, or in a protective measure, that a threat could take advantage of, for example an unpatched software library in an infotainment unit.
Risk – the possibility that a threat exploits a vulnerability and causes harm; it combines how likely this is and how severe the consequences would be.
Risk assessment – the complete activity of spotting and describing risks (identification), working out how serious each one is (analysis), and checking the result against agreed criteria to decide whether it can be tolerated (evaluation).
Risk management – the planned activities through which an organisation steers and keeps control of the risks it faces.
Mitigation – a measure that reduces a risk, such as authenticating messages, isolating networks or locking down a debug port.
Approval Authority – the government body of a Contracting Party that grants approvals and issues the CSMS certificate, for example a national vehicle authority.
Technical Service – an organisation designated by the approval authority to perform assessments and tests on its behalf; it reports its findings, and the authority takes the decision.
Certificate of Compliance for CSMS – the document issued by an approval authority stating that the manufacturer's CSMS meets the regulation; it is a precondition for vehicle type approval and has a limited validity.
TARA – threat analysis and risk assessment, the industry name (from ISO/SAE 21434) for the structured method many manufacturers use to perform the risk assessment R155 demands. The regulation itself does not mandate a particular method.
VSOC – vehicle security operations centre, a team and tooling that monitor a fleet and back-end systems for signs of attack. Again an industry term, not a regulatory one, but a common way to meet the monitoring obligations.

Two ideas that hold everything together

The first idea is the separation of organisation and product. The CSMS is about the company: are the processes in place, are people trained, is there governance? The vehicle type requirements are about one design: was this particular architecture analysed and protected? A company can have an excellent CSMS and still submit a poorly protected vehicle; conversely, a well-protected prototype cannot be approved without the organisational backing to keep it secure in the field.

The second idea is lifecycle thinking. Most traditional vehicle requirements are checked once, at approval. Cyber security changes over time: new attack techniques appear, new vulnerabilities are found in software that was considered safe, and the cryptography that is strong today may be weak in ten years. That is why the regulation expects processes that keep working through production and well into the post-production phase.

Figure 1 – UN R155 approval rests on two layers: a certified management system for the organisation and a demonstrated risk treatment for each vehicle type, both kept alive by monitoring and reporting.

Lesson 3 – Structure of the regulation

UN Regulations follow a common layout, so once you know one you can find your way around the others. UN R155 consists of numbered paragraphs followed by annexes. The paragraph titles below are summarised from the published table of contents.

The main paragraphs

Paragraph 1 – Scope. Which vehicle categories are covered, and the reminder that rules on privacy and on authorised access to vehicle data and functions are not affected.
Paragraph 2 – Definitions. The vocabulary covered in Lesson 2.
Paragraph 3 – Application for approval. Who applies (the manufacturer or its representative) and what documents accompany the application, including the information document and the description of the vehicle type.
Paragraph 4 – Marking. How an approved vehicle carries the international approval mark: a circle containing the letter E and the number of the country that granted approval, together with the regulation number and an approval number.
Paragraph 5 – Approval. The conditions under which the approval authority grants or refuses approval, including the need for a valid CSMS certificate and for satisfactory arrangements to manage cyber security, and how the decision is communicated to other Contracting Parties.
Paragraph 6 – Certificate of Compliance for CSMS. How an approval authority assesses the manufacturer's management system, what the certificate contains, how long it remains valid (no more than three years), how it is renewed and when it can be withdrawn.
Paragraph 7 – Specifications. The heart of the regulation, discussed below.
Paragraph 8 – Modification and extension of the vehicle type. What happens when the approved design changes.
Paragraph 9 – Conformity of production. How the authority checks that vehicles built later still match the approved type.
Paragraph 10 – Penalties for non-conformity of production. Withdrawal of approval when production does not conform.
Paragraph 11 – Production definitively discontinued. What the manufacturer must report when it stops building the type.
Paragraph 12 – Names and addresses of technical services and approval authorities. Administrative information sent to the UN secretariat.

Paragraph 7 in detail

Paragraph 7 is divided into four parts, and it is worth knowing their purpose by heart.

7.1 General specifications state that the requirements of R155 do not restrict the provisions of other UN Regulations.

7.2 Requirements for the CSMS describe what the approval authority checks when it assesses the organisation. The manufacturer must show that its management system applies to all three lifecycle phases. It must have processes for:

managing cyber security within the organisation (governance, roles, responsibilities and policies);
identifying risks to vehicle types, considering the threats listed in Annex 5 Part A and any other relevant threats;
assessing, categorising and treating the risks identified;
verifying that the identified risks are properly managed;
testing the cyber security of a vehicle type;
keeping the risk assessment up to date;
monitoring for, detecting and responding to cyber attacks, threats and vulnerabilities on vehicle types, and checking whether existing measures are still effective as new threats appear;
providing relevant data to support the analysis of attempted or successful attacks.

Further sub-paragraphs add that responses to newly found threats and vulnerabilities must happen within a reasonable time, that monitoring must include vehicles after registration (while respecting privacy when vehicle data is analysed), and that the manufacturer must manage dependencies on suppliers, service providers and its own sub-organisations.

7.3 Requirements for vehicle types describe what is checked for each design submitted for approval. In summary, the manufacturer must:

hold a valid CSMS certificate that is relevant to the type being approved;
identify and manage the cyber security risks related to suppliers for that type;
identify the critical elements of the type, perform a thorough risk assessment and treat the risks, considering Annex 5 Part A and other relevant threats;
protect the type with proportionate mitigations, considering those listed in Annex 5 Parts B and C, and justify any alternative measure;
secure any dedicated environments the vehicle offers for storing and running aftermarket software, services, applications or data;
perform appropriate and sufficient testing before approval to verify that the security measures are effective;
put measures in place to detect and prevent attacks, support the monitoring capability, and provide data forensic capability so that attacks can be analysed;
use cryptographic modules that follow consensus standards, or justify the use of any that do not.

7.4 Reporting provisions require the manufacturer to report the outcome of its monitoring activities to the approval authority or technical service at least once a year, or more often when relevant. The report includes relevant information on new attacks and confirms that the measures remain effective or describes what was done. The authority may require the manufacturer to fix any ineffectiveness it finds, and the CSMS certificate can be withdrawn if the response is insufficient.

The annexes

Annex 1 – Information document, the structured description of the vehicle type, with an appendix in which the manufacturer declares that its CSMS conforms.
Annex 2 – Communication, the standard form an authority uses to notify others of an approval, extension, refusal or withdrawal.
Annex 3 – Arrangement of the approval mark.
Annex 4 – Model of the Certificate of Compliance for CSMS.
Annex 5 – List of threats and corresponding mitigations. Part A is a catalogue of high-level threats with examples of vulnerabilities or attack methods, grouped under headings such as back-end servers, vehicle communication channels, the update process, unintended human actions, external connectivity, vehicle data and code, and other potential vulnerabilities. Part B lists mitigations for threats aimed at the vehicle, and Part C lists mitigations for threats outside the vehicle, such as back-end servers.

Annex 5 is not a checklist that guarantees approval. It is a minimum frame of reference: the manufacturer must show that it has considered every listed threat, decided whether it applies to the vehicle type, and either applied a listed mitigation or explained why an equivalent or different measure is appropriate. Threats that are not in the annex but are relevant to the design must be handled too.

Figure 2 – The structure of UN R155: administrative paragraphs around a core of specifications, with Annex 5 providing the threat and mitigation catalogue that the risk assessment must consider.

Interpretation guidance

Because the requirements are deliberately outcome-based, WP.29 also adopted an interpretation document. It explains, paragraph by paragraph, what an approval authority may reasonably look for and gives examples of evidence. It is guidance, not law, but authorities and technical services use it heavily, and reading it alongside the regulation is the fastest way to understand what "appropriate" means in practice.

Lesson 4 – How it works in practice

Knowing the paragraphs is one thing; building an organisation that satisfies them is another. This lesson walks through what a manufacturer typically puts in place, using ordinary engineering and management language.

Step 1: governance and organisation

The management system starts with leadership. Top management sets a cyber security policy, assigns accountability (often to a chief product security officer or similar role), and gives the function budget and authority. Roles are defined across departments: engineering, purchasing, production, after-sales, IT and legal. People receive training appropriate to their role, from secure coding for software developers to awareness for workshop staff who connect diagnostic tools to vehicles. Rules are written down for how risks are rated and who may accept a remaining risk.

Step 2: risk-based engineering during development

For each vehicle programme, the security team works with system engineers from the concept stage. A typical risk assessment proceeds like this:

Describe the item: the functions, ECUs, networks, external interfaces and back-end services that make up the vehicle type.
Identify assets worth protecting, such as safety-relevant control messages, cryptographic keys, personal data and the integrity of software.
Identify threat scenarios for those assets, using Annex 5 Part A as a minimum list and adding design-specific threats.
Rate the impact of each scenario (safety, financial, operational, privacy) and the feasibility of the attack.
Decide how to treat each risk: reduce it with a mitigation, avoid it by changing the design, share it (for example contractually with a supplier) or accept it with a documented justification.
Turn the decisions into security requirements, allocate them to systems and suppliers, and trace them through design and implementation.

The regulation does not prescribe this exact method, but ISO/SAE 21434 does describe a comparable one, and most manufacturers base their process on it.

Step 3: suppliers and the supply chain

Much of a vehicle's software and hardware is made by suppliers. The manufacturer remains responsible for the vehicle type, so it must make sure that suppliers know which security requirements apply, deliver evidence that they met them, report vulnerabilities, and support the vehicle over its life. In practice this is done with cyber security interface agreements that set out who does which activity and who delivers which work product, plus audits or assessments of supplier processes.

Step 4: verification and testing

Testing confirms that mitigations exist and work. It typically combines functional security tests (does the secure boot reject an unsigned image?), vulnerability scanning of software components, fuzz testing of interfaces that accept external input, and penetration testing by skilled testers who think like attackers. Findings feed back into the risk assessment. The approval authority or technical service may also check, on a sample basis, that the documented measures are actually implemented in a vehicle of the type.

Step 5: production

Security does not end with the design. Production must not introduce weaknesses: keys must be injected securely, debug interfaces must be closed, the correct software versions must be flashed, and end-of-line tools must be protected. The CSMS covers these processes too.

Step 6: monitoring, response and reporting after approval

Once vehicles are on the road, the manufacturer watches for threats and vulnerabilities from many sources: its own fleet telemetry and back-end logs, threat intelligence feeds, supplier notifications, researchers who report issues through a coordinated vulnerability disclosure programme, and public vulnerability databases. When something relevant appears, a defined incident response process assesses the impact on each affected vehicle type, decides on measures (for example a software update, a back-end change or a configuration change) and executes them within a reasonable time. Evidence is kept, and the yearly monitoring report to the approval authority summarises the outcome.

Monitoring is easier to describe than to do. Vehicles produce large amounts of data, much of it personal, so the manufacturer must design data collection to be useful for detecting attacks while respecting privacy law. The data forensic capability required for each vehicle type means that the vehicle and back end must keep enough logs, securely, to reconstruct what happened during an attack.

Figure 3 – The CSMS spans the whole lifecycle: risk work and testing in development, secure manufacturing in production, and a continuous monitor-detect-respond loop that runs for vehicles in the field, from first registration through the post-production phase, and keeps the risk assessment current.

Typical artefacts

An auditor will expect to see documented evidence. Common artefacts include: the cyber security policy and organisation chart; process descriptions and templates; training records; the risk assessment for each vehicle type, with traceability to requirements and tests; supplier agreements and supplier evidence; test plans and reports; the mapping of Annex 5 threats and mitigations; the incident response procedure; monitoring records; and the yearly reports. Good tools that link these artefacts make audits far less painful.

Lesson 5 – Assessment, certification and compliance

UN R155 is not a voluntary standard that a company can choose to certify against with a private certification body. It is a legal approval requirement in the markets that apply it, and the decisions are taken by government approval authorities. Understanding who does what avoids a lot of confusion.

Who assesses

The approval authority of a Contracting Party is responsible for both the CSMS certificate and the vehicle type approval. It may carry out the assessment itself or use a designated technical service, often a testing and inspection company, to perform audits and tests. The technical service reports; the authority decides. A manufacturer can choose which Contracting Party's authority it applies to; once granted, the approval is recognised by the other Contracting Parties that apply R155.

Step one: the CSMS certificate

The manufacturer submits a description of its management system together with evidence that the processes exist and are used. The authority or technical service audits the organisation, typically through document review, interviews and sampling of real project records. If the system meets the requirements of paragraph 7.2, the authority issues a Certificate of Compliance for CSMS following the model in Annex 4. The certificate has a validity of no more than three years. Before it expires, the manufacturer applies for a new or extended certificate, and the authority checks that the system still meets the requirements, including any changes to the regulation since the last assessment. The authority can withdraw the certificate if the system no longer complies.

Step two: vehicle type approval

For each vehicle type, the manufacturer applies for approval under R155 and supplies the information document and evidence for paragraph 7.3: the risk assessment, the mitigations, test results, supplier risk management, and the detection and forensic measures. A valid CSMS certificate is a precondition. The authority or technical service assesses the documentation and may test a sample vehicle to confirm that the documented measures are implemented. If everything is in order, the type is approved, the approval is communicated to other Contracting Parties using the Annex 2 form, and the vehicles carry the approval mark.

Figure 4 – The approval sequence: the management system is certified first, then each vehicle type is assessed against it, and reporting continues after approval.

What keeps an approval valid

Approval is not a one-time event. Several mechanisms keep compliance alive:

Annual reporting of monitoring outcomes, with the authority able to demand remediation.
Certificate renewal at least every three years.
Modification procedures: if the vehicle type changes in a way that affects its cyber security, the manufacturer must inform the authority, which decides whether the existing approval can be extended or a new assessment is required.
Conformity of production: the authority checks that vehicles built later still match the approved type.
Withdrawal: the authority can withdraw an approval or a CSMS certificate when the conditions are no longer met.

Things that are often misunderstood

There is no "ISO/SAE 21434 certificate" that replaces R155 approval. Conformity with the ISO standard is a strong way to build and evidence the processes, and auditors frequently use it as a reference, but the legal decision is taken under the regulation. Likewise, suppliers do not receive R155 approvals for their components under the current text; they support the manufacturer, who holds the approval. Finally, R155 approval does not mean that a vehicle is impossible to hack. It means that the manufacturer has demonstrated a systematic, risk-based approach and the ability to respond when new threats appear.

Older designs deserve a note. Vehicle types whose development started before the regulation applied could not have used a certified CSMS from day one. The regulation contains wording that allows the manufacturer, in such cases, to show that cyber security was adequately considered during development, rather than re-running a full lifecycle that already happened. Some manufacturers decided to discontinue older models in the EU rather than retrofit them, because adding detection, logging and update capability to an old architecture was not practical.

Lesson 6 – Worked example

To tie everything together, follow a fictional manufacturer, Northvale Motors, as it prepares a new connected electric sport utility vehicle (category M1) for sale in the European Union and Japan. The vehicle has a telematics control unit with a cellular modem, a central gateway, an infotainment unit with Bluetooth and Wi-Fi, a charging controller, a digital key function that works with a smartphone, and over-the-air update capability.

1. Establish and certify the CSMS

Northvale's board appoints a head of product security with authority to stop a release on security grounds. A cyber security policy is approved, and a steering group with engineering, purchasing, quality, after-sales, IT and legal meets every month. Process owners write procedures for the eight process areas from paragraph 7.2, based on ISO/SAE 21434 methods. Engineers, testers and buyers complete role-based training. A vehicle security operations centre is set up to receive data from the fleet and the back end, and a public page invites researchers to report vulnerabilities.

Northvale chooses a national approval authority in the EU, which mandates a technical service to audit the CSMS. The auditors review the procedures, interview staff and sample records from an earlier project that used the new processes as a pilot. They find two gaps: the procedure for supplier vulnerability notifications has no deadlines, and there is no documented criterion for when a remaining risk may be accepted. Northvale fixes both. The authority issues the Certificate of Compliance for CSMS, valid for three years.

2. Assess the risks of the vehicle type

The programme team describes the vehicle type: its ECUs, networks, external interfaces and back-end services. Assets include braking and steering command messages, the digital key secrets, owner location data and the integrity of every ECU's software. The team then works through each Annex 5 Part A threat group and asks whether it applies. For example, under communication channels they consider spoofed messages received over the cellular link; under the update process they consider tampered update packages; under external connectivity they consider attacks through the charging interface and through Bluetooth; under back-end servers they consider compromise of the server that sends remote commands to unlock the vehicle. Two design-specific threats are added because the annex's generic examples do not describe them precisely enough for this design: relay attacks against the phone-as-key function, and malicious apps in the infotainment app store.

Each scenario is rated for impact and feasibility. Remote unlocking through a compromised back end is rated high impact and medium feasibility; spoofing of braking commands from the infotainment unit is rated severe impact but low feasibility once the gateway filters traffic.

3. Choose and allocate mitigations

For each risk that is too high, the team chooses treatments, comparing them with Annex 5 Parts B and C:

The central gateway separates the infotainment and telematics domains from the chassis domain and only forwards allow-listed messages.
Safety-relevant messages are authenticated so that an injected message is rejected.
All ECUs use secure boot, and update packages are signed and verified before installation, linking to the software update management system required by UN R156.
The back end uses strong authentication, least-privilege access, and anomaly detection on remote-command traffic.
The digital key uses distance bounding to resist relay attacks.
The infotainment app store runs third-party apps in an isolated environment with restricted permissions, which addresses the requirement about dedicated environments for aftermarket software.
Debug interfaces are permanently locked on production units.

The telematics supplier receives a security requirements specification and signs an interface agreement. It commits to deliver its own risk analysis, a software bill of materials and test reports, and to notify Northvale of vulnerabilities within an agreed time for the life of the vehicle.

4. Test and prepare evidence

Security tests confirm that the gateway drops forbidden messages, that secure boot rejects modified images and that the app sandbox prevents access to vehicle networks. An external team runs a penetration test on a pre-series vehicle and finds that the Wi-Fi hotspot exposes an unnecessary service. It is removed and retested. Detection rules are installed in the vehicle and back end, and the team checks that logs are stored securely and can be retrieved for forensic analysis. The final evidence package maps every Annex 5 threat to a decision and a measure, and every measure to a test result.

5. Obtain the type approval

Northvale applies for R155 approval of the vehicle type. The technical service reviews the evidence, questions the justification for one accepted risk, and tests a sample vehicle to confirm that debug ports are locked and the gateway filters messages. The authority grants the approval and notifies the other Contracting Parties. Because Japan also applies R155, Northvale can use the same approval as the basis for its Japanese market entry, subject to that country's administrative procedures.

6. Live with the vehicle in the field

Eight months after launch, a researcher reports a vulnerability in the Bluetooth software stack used by the infotainment supplier. The VSOC confirms which vehicle types and software versions are affected, and the risk assessment is updated: the flaw could allow code execution on the infotainment unit, but the gateway prevents access to the chassis domain. The supplier delivers a fix, Northvale validates it and rolls it out over the air using its R156-certified update process. Fleet data shows no sign of exploitation. In its next yearly report to the approval authority, Northvale summarises this incident, the response time and the confirmation that its measures remain effective.

Two years later, Northvale prepares a facelift with a new driver monitoring camera connected to the same domain controller. Because the change affects the architecture assessed for cyber security, it informs the authority, updates the risk assessment and supplies new evidence, and the approval is extended. A few months before the CSMS certificate expires, Northvale applies for renewal, and the auditors check that the processes still work and reflect any changes made to the regulation in the meantime.

This example shows the full logic: the organisation is certified once and renewed; each vehicle type is analysed, protected and tested; and the loop of monitoring, response and reporting keeps both alive for as long as the vehicles are on the road.

Lesson 7 – Relationship to other standards and frameworks

UN R155 rarely stands alone. It sets legal requirements that other documents help to meet, and it has siblings that cover adjacent topics. Understanding the map avoids duplicated work.

Regulation versus standard

A regulation is law (where adopted) and says what must be achieved and proven to an authority. A standard is a voluntary consensus document, usually written by industry experts in bodies such as ISO and SAE, that says how a discipline can be carried out. Standards become relevant to regulation when authorities accept them as evidence. UN R155 does not make any standard mandatory, but the interpretation guidance and audit practice refer to them.

Document	Type and owner	What it covers	Relationship to UN R155
UN R156	UN Regulation, UNECE WP.29	Software update management system (SUMS) and approval of vehicle types for software updates, including over the air	Sister regulation adopted at the same time; secure updates are a key R155 mitigation, and the two are usually implemented together
ISO/SAE 21434	International standard, ISO and SAE International (2021)	Cyber security engineering for road vehicles across the lifecycle, including organisational processes and threat analysis and risk assessment	The most common engineering basis for building a CSMS and for producing the risk assessment evidence R155 requires
ISO/PAS 5112	Publicly available specification, ISO (2022)	Guidelines for auditing cyber security engineering processes	Helps auditors and manufacturers plan audits of the organisational processes that an R155 CSMS assessment examines
ISO 24089	International standard, ISO (2023)	Software update engineering for road vehicles	Engineering basis for R156; indirectly supports R155 mitigations related to the update process
ISO 26262	International standard, ISO	Functional safety of electrical and electronic systems in road vehicles	Different goal (failures rather than attacks) but strongly linked: attacks can cause safety hazards, so safety and security analyses must be coordinated
GB 44495-2024	Mandatory national standard, China	Technical requirements for vehicle cyber security, including a management system and vehicle-level requirements and tests	Covers similar ground for the Chinese market, which is outside the 1958 Agreement system; manufacturers often align the two programmes

Figure 5 – Voluntary standards describe how to engineer and audit and feed evidence into the two regulations, while secure updates under R156 serve as a key R155 mitigation.

Other frameworks you may meet

Organisations sometimes also hold an information security certification for their IT, such as ISO/IEC 27001. That certification protects corporate information but does not by itself cover vehicle engineering; it can, however, support the protection of back-end servers and development environments that R155 also cares about. In the supplier community, assessment models such as Automotive SPICE have a cyber security extension that some manufacturers use to evaluate supplier processes. These are useful building blocks, but none of them replaces the regulation's own requirements.

Common pitfalls and best practices

Common pitfalls

Treating approval as the finish line. Teams that disband after approval leave no one to monitor, respond and report; the obligations run until the last vehicle of the type is off the road.
Using Annex 5 as a tick list. Marking every listed mitigation as "done" without a design-specific risk assessment misses threats the annex does not mention and invites hard questions from auditors.
A CSMS that exists only on paper. Beautiful process documents with no project records behind them do not pass an audit that samples real evidence.
Ignoring suppliers. Without interface agreements and vulnerability notification duties, the manufacturer cannot show control over the parts of the vehicle it did not build itself.
No data for forensics. Designing ECUs without secure logging makes it impossible to analyse an attack, which the regulation explicitly expects.
Forgetting the back end. Many realistic attacks target servers, apps and update infrastructure rather than the vehicle itself.
Underestimating change management. Changing the architecture without informing the approval authority can put the approval at risk.

Best practices

Start early. Begin the risk assessment at the concept stage, when architectural changes such as domain separation are still cheap.
Build on ISO/SAE 21434. Using a recognised engineering standard gives a common language with suppliers and auditors.
Keep traceability. Link each threat to a decision, each decision to a requirement, and each requirement to a test result, so evidence can be produced quickly.
Plan R155 and R156 together. A secure update capability is both an R156 requirement and the main tool for responding to new vulnerabilities under R155.
Invest in monitoring and response. A vehicle security operations centre, a vulnerability disclosure programme and rehearsed incident playbooks make the post-production obligations workable.
Talk to the authority early. Agreeing the evidence format and scope with the technical service before formal submission avoids late surprises.
Treat the yearly report as a management review. Use it to check whether measures are still effective, not only to satisfy a deadline.

Summary and key takeaways

UN R155 is a UNECE regulation under the 1958 Agreement, in force since January 2021 and still in its original series, last changed by Supplement 3 in January 2025.
It covers categories M and N, trailers (O) fitted with an ECU and, since Supplement 3, L-category vehicles, wherever a Contracting Party has adopted it, notably in the EU and Japan.
Approval has two layers: a certified cyber security management system for the organisation, and a demonstrated risk treatment for each vehicle type.
The CSMS must cover development, production and post-production, with processes for governance, risk identification and treatment, testing, keeping the assessment current, monitoring, response and forensic data.
Annex 5 lists threats and mitigations that must be considered, but it is a minimum reference, not a complete checklist.
Approval authorities, often supported by technical services, issue the CSMS certificate (valid for up to three years) and the type approval.
Compliance continues after approval through yearly monitoring reports, change management, conformity of production and certificate renewal.
ISO/SAE 21434 and UN R156 are the closest companions: the first supplies engineering methods, the second the secure update capability.

Reflection questions

Think of a connected product your organisation builds or uses. Which of its external interfaces would you examine first in a risk assessment, and why?
How would you explain to a project manager the difference between holding a CSMS certificate and holding a type approval for a specific vehicle?
If a supplier refuses to commit to vulnerability notifications for the life of a vehicle, what options does the manufacturer have, and what are the consequences of each?
What evidence would convince you, as an auditor, that a manufacturer's monitoring process really works rather than existing only on paper?
Which mitigation in the worked example contributes most to limiting the damage of a compromised infotainment unit, and how would you test that it is effective?