UNECE R155
The UN regulation requiring vehicle manufacturers to run a certified cybersecurity management system as a condition of type approval.
UNECE Regulation No. 155 is the UN regulation on vehicle cybersecurity. It requires manufacturers to operate a certified Cyber Security Management System (CSMS) covering the full vehicle lifecycle — development, production and the years a vehicle is on the road — and to demonstrate, per vehicle type, that cybersecurity risks have been identified and treated. Without a valid CSMS certificate there is no type approval, and without type approval a vehicle cannot be sold or registered in the markets that apply the regulation.
R155 is one half of a regulatory pair adopted together in 2020: its sibling, UNECE R156, governs software updates. Together they turned two engineering disciplines — security engineering and update management — into legal preconditions for market access, and they remain the clearest example of regulation written for the software-defined vehicle rather than retrofitted to it.
What the regulation requires
R155 operates on two levels.
The first is organizational. The manufacturer must run a CSMS: documented processes for identifying, assessing and treating cybersecurity risks across three phases — development, production and post-production. The post-production phase is the demanding one. The CSMS must include monitoring for new threats and vulnerabilities affecting vehicles already in the field, and defined processes for responding to what that monitoring finds, for as long as the vehicle type is supported. An approval authority, or a technical service acting on its behalf, audits the CSMS and issues a certificate of compliance that must be renewed periodically.
The second level is per vehicle type. For each type submitted for approval, the manufacturer must show that the CSMS was actually applied: that risks specific to the type were assessed, that mitigations were implemented and tested, and that the supply chain is covered — the manufacturer answers for risks originating at its suppliers. The regulation’s annex lists example threats and mitigations, from spoofed messages on in-vehicle networks to compromised update channels, but it deliberately does not mandate specific technical countermeasures. What it mandates is evidence that a structured risk process ran and reached defensible conclusions.
History and timeline
The work began in UNECE’s World Forum for Harmonization of Vehicle Regulations (WP.29) in the mid-2010s, as remote attacks on connected vehicles moved from research demonstrations to headline news. R155 was adopted by WP.29 in June 2020 and entered into force in January 2021 for the contracting parties applying it.
The EU made it binding through the General Safety Regulation, Regulation (EU) 2019/2144: mandatory for new vehicle types from July 2022, and for all newly registered vehicles from July 2024. The 2024 deadline had visible consequences — several manufacturers withdrew older models from European sale rather than re-engineer legacy electronics for CSMS conformance, an early demonstration that the regulation has teeth and that its costs land on architectures designed before it existed.
Where it applies — and where it does not
R155 applies in countries party to the UNECE 1958 Agreement that have adopted it. The EU applies it through its type-approval framework, and Japan and South Korea apply it on their own national schedules — a significant share of the global market moving on broadly aligned requirements.
The United States is the notable absence. The US does not participate in the 1958 Agreement’s mutual-recognition system; NHTSA addresses vehicle cybersecurity through non-binding guidance and its general safety authority rather than an approval gate. China regulates vehicle cybersecurity through its own national framework outside UNECE. In practice, manufacturers building global platforms engineer to the strictest common denominator — usually the UNECE requirements — because maintaining regionally divergent security architectures costs more than uniform compliance.
R155 and ISO/SAE 21434
R155 states what must be demonstrated; ISO/SAE 21434 describes how engineering organizations typically demonstrate it. The standard, published in 2021, defines a cybersecurity engineering process for road vehicles — threat analysis and risk assessment methods, work products, lifecycle phases — and has become the de facto reference framework for CSMS audits. Conformance with ISO/SAE 21434 is not legally required by R155, but approval authorities and technical services widely treat it as the expected baseline, and OEMs flow it down their supply chains contractually. The same division of labor exists on the update side, where ISO 24089 plays the equivalent role for R156’s software update management system.
Common misconceptions
R155 is often described as a security-feature checklist. It is not. The regulation certifies a management system and a risk process, not the presence of any particular technology; two compliant vehicles can implement very different countermeasures if both trace to a sound risk assessment.
It is also not one-and-done. The CSMS certificate expires and must be renewed, the post-production monitoring obligation runs for the supported life of the type, and changes to a type can require the cybersecurity case to be revisited.
Finally, it does not apply retroactively: vehicles registered before the applicable dates are unaffected, which is why compliance pressure concentrated on new platforms and on older models still in production — and why some of the latter were retired instead.
What to watch
Three threads matter through the rest of the decade. First, interpretation: WP.29 continues to refine guidance on how the requirements apply, and audit practice among technical services is still converging, so the effective bar can shift without the regulation’s text changing. Second, the post-production load: as compliant fleets age, the cost of monitoring and responding to vulnerabilities across many vehicle types simultaneously becomes a structural line item, and one argument for consolidating software onto fewer, longer-lived platforms. Third, scope pressure: features that change behavior after sale — from over-the-air updates governed by R156 to learning-based driver assistance — keep testing the boundary between the cybersecurity case, the update case and the safety case, and regulators have signaled that these threads will be handled together rather than separately.
Recent coverage
Related: ISO/SAE 21434 · OTA update · Type approval / homologation · UNECE R156