Three documents shape how connected vehicle software is built and shipped: UN Regulation No. 155 on cybersecurity, UN Regulation No. 156 on software updates, and the standard ISO/SAE 21434. People mix them up because they appear together in supplier questionnaires. They do different jobs.
This post separates them, quotes the clauses that matter to software teams, and ends with a map from clause to the evidence an auditor will ask for. It is a reading guide. The regulation text is the authority, and your approval authority decides what counts.
Safeguard does not move vehicles or sit in the driving loop. The relevant part here is the software supply chain behind the vehicle: component inventories, vulnerability tracking and update records.
What's affected
UN R155 is a regulation about an organisation and a vehicle type. The manufacturer must run a Cybersecurity Management System (CSMS) and must show each vehicle type was assessed and protected. The text is published in the EU Official Journal as L 82, 9 March 2021.
UN R156 covers software updates. It asks for a Software Update Management System (SUMS) and rules for how updates, including over the air updates, are identified, protected and executed.
ISO/SAE 21434 is an engineering standard, first edition August 2021. Its scope is "engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces." It applies to series production systems whose development or modification began after publication, and it "does not prescribe specific technology or solutions."
The usual shorthand: R155 and R156 are what regulators check. ISO/SAE 21434 is a common way to build the processes that satisfy the first one. The standard is not the law, and following it does not by itself grant type approval.
In the EU, Regulation (EU) 2019/2144 lists "Protection of vehicle against cyberattacks" in Annex II among the requirements, and its recitals say UN cybersecurity regulations should apply on a mandatory basis. That is how the UN texts reach EU type approval.
How to check what applies to your software
Read the clauses that touch software teams directly.
R155, the CSMS. Paragraph 7.2.2.2 lists the processes the manufacturer must demonstrate, including identification and treatment of risks, testing the cybersecurity of a vehicle type, and "the processes used to monitor for, detect and respond to cyberattacks, cyber threats and vulnerabilities on vehicle types." Paragraph 7.2.2.4 says monitoring must be continual and "include vehicles after first registration." Paragraph 7.2.2.5 says the manufacturer must show how it manages dependencies on "contracted suppliers, service providers or manufacturer's sub-organizations."
R155, the vehicle type. Paragraph 7.3.2 requires the manufacturer to "identify and manage, for the vehicle type being approved, supplier-related risks." Paragraph 7.3.7 requires measures to detect and prevent cyberattacks, to support the monitoring capability, and to "provide data forensic capability." Paragraph 7.4.1 requires reporting to the approval authority "at least once a year, or more frequently if relevant," on monitoring outcomes and on whether mitigations remain effective.
R156. Paragraph 7.1.1.2 asks for a process by which information on "all initial and updated software versions, including integrity validation data, and relevant hardware components" can be uniquely identified. Paragraph 7.2.1.1 says "the authenticity and integrity of software updates shall be protected to reasonably prevent their compromise and reasonably prevent invalid updates."
For over the air updates, paragraph 7.2.2.1.1 requires the ability to restore the previous version after a failed or interrupted update, or to place the vehicle in a safe state. Paragraph 7.2.2.1.2 requires that updates only run when the vehicle has enough power to finish, including recovery. Paragraph 7.2.2.3 says that where updating while driving may not be safe, the manufacturer must show how it ensures "the vehicle cannot be driven during the execution of the update."
R156 also introduces the RXSWIN, a "dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software" of the electronic control system. Each RXSWIN must be uniquely identifiable and readable through an electronic interface, at least the OBD port.
What to do now
If you are a supplier to a vehicle maker, you are inside someone else's CSMS. Expect these asks.
- A component inventory per software release. R156 wants versions and integrity validation data to be uniquely identifiable. A software bill of materials per release is the practical way to answer a customer's request for the list.
- A way to learn about new vulnerabilities in what you ship. Continual monitoring after registration only works if you can match new CVEs to the components in each released version.
- Evidence that your update package is authentic. Signed packages, a documented signing key lifecycle, and a record of what was signed.
- A recovery story. What happens when the update stops halfway, when power drops, or when the new image fails its self check.
- A forensic data story. Which logs exist in the ECU, who can read them, and how long they last.
- A supplier notification path. Your customer has to report on monitoring at least once a year. Give them something to report on, including vulnerabilities found in your software and your fix timeline.
Then map each clause to a document you already have or need to write.
| Clause | Evidence an auditor may ask for |
|---|---|
| R155 7.2.2.2 and 7.2.2.4 | Monitoring process, vulnerability intake, triage records |
| R155 7.2.2.5 and 7.3.2 | Supplier risk register, contract terms, SBOMs from suppliers |
| R155 7.3.7 | Detection design, log schema, forensic data export |
| R155 7.4.1 | Annual monitoring report inputs |
| R156 7.1.1.2 | Release register with versions and hashes |
| R156 7.2.1.1 | Signing procedure and verification logic |
| R156 7.2.2.1.1 to 7.2.2.1.2 | Rollback test results, low power test results |
Why it matters
The common failure is treating R155 as a document exercise. The text asks for monitoring of vehicles after first registration and for vulnerability response "within a reasonable timeframe" (paragraph 7.2.2.3). Both depend on knowing exactly which software is in which vehicle at any given moment, which is a data problem before it is a policy problem.
The second failure is the supplier gap. A vehicle maker can only manage supplier risk if the supplier gives it component data. A supplier who cannot say whether its stack contains a newly disclosed library will cost its customer a monitoring finding.
Treat the regulation as a set of questions you must be able to answer fast: what is in this release, who signed it, what happens if it fails, and who do we tell when a CVE appears.
Quick check
Is ISO/SAE 21434 a regulation?
No. It is an engineering standard that sets out cybersecurity risk management requirements across the vehicle lifecycle. R155 is the regulation that approval authorities check, and the standard is a common way to build the processes.
What does R156 require if an update fails halfway?
Paragraph 7.2.2.1.1: the vehicle must be able to restore systems to their previous version, or be placed into a safe state after a failed or interrupted update.
Does R155 stop at first registration?
No. Paragraph 7.2.2.4 says monitoring must be continual and include vehicles after first registration.
Sources
- UN Regulation No. 155, as published in the Official Journal (OJ L 82, 9.3.2021)
- UN Regulation No. 156, as published in the Official Journal (OJ L 82, 9.3.2021)
- SAE International, ISO/SAE 21434 Road Vehicles, Cybersecurity Engineering (issued 31 August 2021)
- Regulation (EU) 2019/2144, General Safety Regulation
