Key takeaways
- UN Regulation No. 155 requires a certified cybersecurity management system, and No. 156 a software update management system. Both are conditions of vehicle type approval.
- In the EU they applied to new vehicle types from July 2022, and to all new vehicles from July 2024.
- ISO/SAE 21434 is the usual way to show cybersecurity engineering is done properly; ISO 24089 covers software update engineering.
- The evidence runs through the supply chain: a manufacturer has to show that risks in the components it buys are managed too.
- Over-the-air updates have to be identified, controlled and recorded against each vehicle’s approved configuration.
Two regulations, one condition of approval
The UNECE World Forum for Harmonization of Vehicle Regulations adopted UN Regulation No. 155 on cybersecurity and No. 156 on software updates in 2020. In the EU, the General Safety Regulation made both mandatory for new vehicle types from July 2022 and for all new vehicles from July 2024. Other markets that apply UN regulations, Japan among them, require them too.
Both work at two levels. The manufacturer needs a management system — for cybersecurity (a CSMS) and for software updates (a SUMS) — that is assessed and certified. Then each vehicle type has to show that the system was actually applied to it.
What a cybersecurity management system covers
- Risk identification and assessment across the vehicle’s life, with a threat analysis that is kept current. The regulation’s annex lists threats and mitigations to consider.
- Monitoring and response: detecting attacks and new vulnerabilities in vehicles already on the road, and acting on them.
- Testing: showing that the mitigations work, for the vehicle type being approved.
- The supply chain: managing the risks in the hardware and software the manufacturer buys.
ISO/SAE 21434, the cybersecurity engineering standard for road vehicles, is the common way to structure that work and to show it was done.
Updates have to be managed, not just shipped
R156 asks for a process that identifies the software in a vehicle, assesses how an update affects type-approved systems, protects the update in transit and during installation, and records what went to which vehicle. Software relevant to type approval is identified by a software identification number, the RXSWIN, tied to the approved configuration. ISO 24089 covers the engineering side of software updates.
For an over-the-air pipeline, that means:
- Every release maps to the vehicle configurations it is approved for.
- Updates are signed, delivered in stages, and can be rolled back.
- Installation results are recorded for each vehicle.
- Changes that affect type-approved behaviour are flagged before release, not discovered after it.
The evidence is the hard part
Most teams already do much of this work. What fails audits is the trail: a threat analysis that no longer matches the architecture, a supplier who cannot produce their own evidence, a release whose link to its requirement and test lives in a spreadsheet nobody maintains. Traceability from cybersecurity requirement to design, test and release, kept as the work happens, is what makes the second audit easier than the first.
Where to start
Map the evidence chain
For one vehicle type, trace each cybersecurity requirement to its design, tests and releases, and note the gaps.
Bring suppliers into the trail
Agree what evidence each supplier provides, in what form, and when.
Make the update pipeline auditable
Configuration, signing, staged rollout, rollback and a record for every vehicle.
Rehearse a field vulnerability
From report to fix to update, against the time your own process promises.