What is the difference between ISO/SAE 21434 and UNECE Regulations R155 and R156 ?

ISO/SAE 21434:2021 is an engineering standard: it describes how to design, verify and maintain the cybersecurity of a road vehicle across its life cycle. UNECE Regulations R155 and R156 are regulatory type-approval texts: they require the manufacturer to operate, respectively, a cyber security management system (CSMS) and a software update management system (SUMS), audited and certified by a type-approval authority. In practice, applying ISO/SAE 21434 produces the technical evidence expected for R155, but the standard is not normatively required by the regulation.

What is a CSMS under R155 ?

The CSMS (Cyber Security Management System) is the organised set of processes, responsibilities and resources through which a manufacturer manages cyber risk across its vehicles. R155 requires this system to cover the development phase, the production phase and the post-production phase (monitoring, incident response, vulnerability management for the in-service fleet). The authority issues a CSMS certificate of compliance, valid for three years, which is a prerequisite for any vehicle type approval under R155.

What is the purpose of the CAL level in ISO/SAE 21434 ?

CAL stands for Cybersecurity Assurance Level. Four levels, CAL 1 to CAL 4, grade the rigour of effort (independence of reviews, depth of verification, documentation handling) expected to address a cybersecurity goal. The CAL is not a measure of residual risk: it is a scaling factor for assurance activities, recommended informatively in annex E of the standard. For cybersecurity it plays a role analogous to, but distinct from, the ASIL in ISO 26262.

TARA stands for Threat Analysis and Risk Assessment. Described in clause 15 of ISO/SAE 21434, it starts from the item and its assets, identifies threat scenarios, analyses attack paths and their feasibility, rates impact across several dimensions (safety, financial, operational, privacy) and leads to risk-treatment decisions. The TARA is the methodological pivot of the standard, the functional equivalent of the HARA in ISO 26262 for the cyber domain.

From when are R155 and R156 mandatory ?

For the contracting parties applying the regulations (including the European Union), R155 and R156 have applied to new vehicle types approved since July 2022, then to all new vehicles produced since July 2024, that is including types already approved before 2022. In the European Union, Regulation (EU) 2018/858 makes these requirements enforceable for type approval and Regulation (EU) 2019/2144 (GSR) reinforces the framework. A new vehicle without a valid CSMS and SUMS can therefore no longer be registered.

Does ISO/SAE 21434 replace ISO 26262 ?

No. ISO 26262 addresses functional safety (random hardware failures and systematic errors that may cause harm), ISO/SAE 21434 addresses cybersecurity (intentional attacks). The two standards are complementary and applied in parallel: a cyber threat can trigger a functional-safety consequence, and the safety dimension is precisely one of the TARA impact categories. The functional-safety and cybersecurity teams must coordinate their analyses, item definitions and evidence.

What is the scope of R156 (SUMS) ?

R156 requires a SUMS (Software Update Management System) ensuring that every software update, on the production line, in the workshop or over the air (OTA, Over-The-Air), is traced, authenticated and compatible with the vehicle approval. The manufacturer must manage a software identification (RxSWIN), assess the impact of an update on regulated functions, inform the driver where relevant and prevent an update that would invalidate the approval. Like the CSMS, the SUMS receives a certificate of compliance valid for three years.

RxSWIN (Regulation X Software Identification Number) is a software-version identifier attached to the functions covered by a given approval regulation. Introduced by the WP.29 framework, it allows the in-service software configuration of a vehicle to be known and an update to be verified as still compliant. The manufacturer declares the relevant RxSWIN in the approval file and updates it through the SUMS process when an update modifies a regulated function.

Automotive cybersecurity: 21434, R155, R156

Author Hugues Orgitello Last updated 30 May 2026 ~9 min read

Guide, automotive cybersecurity

Road-vehicle cybersecurity rests on two distinct but interlocking pillars: an engineering standard, ISO/SAE 21434, which structures the management of cyber risk across the whole life cycle, and two United Nations type-approval regulations, UNECE R155 (cybersecurity management) and UNECE R156 (software update management). This page sets out the origin of this framework, the content of the standard (item definition, TARA, CAL levels, life cycle), how the R155 and R156 regulations work, their interplay with ISO 26262 functional safety, the type-approval timeline, and the recurring design pitfalls.

A two-layer framework: standard and regulation

Automotive cybersecurity reads at two levels that should not be conflated. The first is normative and voluntary: ISO/SAE 21434, published jointly by ISO and SAE in August 2021, describes the state of the art of cybersecurity engineering for the electrical and electronic systems of road vehicles. The second is regulatory and mandatory: the UNECE R155 and UNECE R156 regulations, adopted by the World Forum for Harmonization of Vehicle Regulations (WP.29) in June 2020, condition the type approval of a vehicle.

The distinction matters. A type-approval authority does not check conformity to ISO/SAE 21434: it checks that the manufacturer operates a management system compliant with R155 and R156, and that the vehicles presented stem from it. The standard is not normatively required by the regulation. In practice, however, applying ISO/SAE 21434 is the most direct route to producing the evidence the R155 assessor expects, because the two texts share the same vocabulary and the same risk-management logic.

Dimension	ISO/SAE 21434	UNECE R155 / R156
Nature	Engineering standard (voluntary)	Type-approval regulation (mandatory)
Issuer	ISO and SAE	WP.29 (under the UNECE)
Object	How to do cybersecurity	Evidence that the organisation can do it
Controlled unit	Item, component, project	CSMS, SUMS, vehicle type
Evidence	Cybersecurity Case, deliverables	Certificate of compliance, audit
Geographic scope	International	Contracting parties to the 1958 Agreement

The role of WP.29 and the 1958 Agreement

WP.29 is not a standards body in the sense of ISO or the IEC: it is an intergovernmental forum hosted by the United Nations Economic Commission for Europe (UNECE). It produces technical regulations (the UN Regulations) that contracting parties to the 1958 Agreement transpose into their approval law. The European Union, Japan, Korea, the United Kingdom and many other states apply these regulations; the United States, which is not a party to the 1958 Agreement, follows a distinct self-certification framework.

ISO/SAE 21434: structure and key concepts

ISO/SAE 21434 is organised around a cybersecurity life cycle covering design, production, operation and decommissioning. It defines roles, deliverables and risk-based reasoning whose essential building blocks are the item definition, the TARA and the Cybersecurity Case.

Item definition and scope

As in ISO 26262, the starting point is the item definition: the precise delimitation of the system under analysis, its functions, its interfaces and its environment. The item definition conditions the identification of the assets to protect, their cybersecurity properties (confidentiality, integrity, availability) and the boundaries of the analysis. An imprecise item definition is the leading cause of an incomplete TARA.

The seven-step TARA

Clause 15 describes the Threat Analysis and Risk Assessment (TARA) as a sequence of analyses that may be run independently but follow a logical chain.

Asset identification: census of assets and their cybersecurity properties from the item definition.
Threat scenario identification: description of possible compromises to the assets' properties.
Impact rating: scoring of consequences across four categories, safety, financial, operational, privacy.
Attack path analysis: decomposition of the ways a threat scenario can be realised.
Attack feasibility rating: estimation of the attack effort, for example via an attack-potential-based approach.
Risk value determination: combination of impact and feasibility.
Risk treatment decision: reduce, share, retain or avoid the risk, leading to the cybersecurity goals.

The CAL levels

CAL (Cybersecurity Assurance Level) grades, over four levels CAL 1 to CAL 4, the intensity of the assurance activities associated with a cybersecurity goal. Contrary to a common belief, the CAL does not measure residual risk and is not a strict equivalent of the ASIL: it is a scaling factor for activities (degree of review independence, depth of verification, documentation rigour). The CAL derivation method is described in annex E, informatively, which leaves room for adaptation by each organisation.

Aspect	ASIL (ISO 26262)	CAL (ISO/SAE 21434)
Domain	Functional safety	Cybersecurity
Scale	A, B, C, D (plus QM)	CAL 1, 2, 3, 4
Derivation	Normative (S, E, C in HARA)	Informative (annex E)
What it grades	Rigour against failures	Rigour of assurance activities
Measures risk ?	Indirectly	No, an effort factor

The Cybersecurity Case and distributed management

The overall argument, the Cybersecurity Case, gathers the evidence that the cybersecurity goals are met. The standard also formalises the supply chain through the Cybersecurity Interface Agreement (CIA), the cyber equivalent of the Development Interface Agreement in ISO 26262, which allocates responsibilities between OEM, Tier 1 and Tier 2. The post-production phase is handled by continuous monitoring (cybersecurity monitoring), vulnerability management and incident response across the in-service fleet.

UNECE R155: the CSMS and cyber type approval

Regulation R155 imposes two interlocking things. First, the manufacturer must obtain a certificate of compliance for its CSMS (Cyber Security Management System), that is, have the type-approval authority audit the organisation, processes and resources with which it manages cyber risk. Second, every vehicle type presented for approval must demonstrate that its cybersecurity is governed by that CSMS.

The three phases covered by the CSMS

Phase	Main R155 requirements
Development	Risk identification and management, design of measures, verification and validation, supply-chain management
Production	Consistency between design and manufacture, configuration protection, key and secret management
Post-production	Monitoring of threats and vulnerabilities, detection and incident-response capability, security updates on the in-service fleet

The CSMS certificate is valid for three years and conditions any vehicle approval under R155. Annex 5 of the regulation lists a catalogue of threats and mitigations that the assessor uses as a reference: a manufacturer must show that it has considered these threats or justified their irrelevance.

Interplay with European Union law

In the European Union, Regulation (EU) 2018/858 on the approval and market surveillance of motor vehicles makes the relevant UNECE regulations enforceable for type approval. Regulation (EU) 2019/2144, the General Safety Regulation (GSR), reinforces the framework for vehicle safety features. Cybersecurity (R155) and software update management (R156) thereby become approval conditions for vehicles in the targeted categories (notably M and N, and some O).

UNECE R156: the SUMS and software updates

R156 addresses a distinct but related subject: the control of software updates, in particular over-the-air (OTA, Over-The-Air) updates. The manufacturer must obtain a certificate of compliance for its SUMS (Software Update Management System), also valid for three years.

What the SUMS must guarantee

Traceability: record which software version is or has been in service on which vehicle.
Regulatory identification: manage the RxSWIN (Regulation X Software Identification Number) attached to the functions covered by a regulation.
Impact assessment: determine whether an update affects a regulated function, safety or the approval.
Integrity and authenticity: prevent the installation of unauthorised or altered software.
Driver information: for an OTA update liable to affect use, inform and, where relevant, obtain a user action.
Reversibility and safe execution: ensure the vehicle stays safe or is safely unusable during the update.

The RxSWIN, pivot of software compliance

The RxSWIN identifies the software configuration associated with a given regulatory scope. When an update modifies a regulated function, the corresponding RxSWIN changes and the manufacturer must verify that the approval remains valid, or update it. This mechanism makes software an approval object in its own right, on a par with a mechanical component.

Interplay with functional safety and the wider cyber framework

Cybersecurity and functional safety are addressed in parallel, never one instead of the other. ISO 26262 covers malfunctions (random failures, systematic errors); ISO/SAE 21434 covers intentional attacks. The junction point is the safety impact category of the TARA: a cyber threat whose consequence is harm to people joins the scope of an ISO 26262 Safety Goal. The two teams ideally share the item definition and reconcile their analyses.

Standard or text	Domain	Nature
ISO 26262	Vehicle functional safety	Standard
ISO/SAE 21434	Vehicle cybersecurity	Standard
UNECE R155	Cybersecurity management (CSMS)	Regulation
UNECE R156	Software update management (SUMS)	Regulation

Beyond the vehicle alone, the wider European cyber framework intersects: the forthcoming Cyber Resilience Act targets products with digital elements, while the IEC 62443 standard structures the cybersecurity of industrial automation systems, which charging stations or production lines may fall under. For the vehicle itself, R155 and R156 remain the approval reference.

Type-approval timeline

For the contracting parties applying the regulations, the rollout happened in two stages.

Deadline	Scope
July 2022	New vehicle types: a type approved from this date must be covered by a valid CSMS (R155) and SUMS (R156)
July 2024	All new vehicles: even types approved before 2022 must comply to continue being produced and registered

In concrete terms, since July 2024 a new vehicle in the targeted categories can no longer be registered in the European Union without a valid CSMS and SUMS. The timeline explains the early discontinuation of certain models whose software compliance would have cost more than maintaining them on the market.

Typical manufacturer procedure

Set up the CSMS and SUMS: define the processes, roles and tools for managing cyber risk and software updates.
Organisational audit: the type-approval authority (or its technical service) audits both systems and issues the certificates of compliance (valid three years).
Apply to the vehicle type: for each type, run the TARA, design the measures, build the Cybersecurity Case and declare the RxSWIN.
Type approval: present the evidence attached to the CSMS and SUMS; the type receives its approval.
In-service maintenance: monitor vulnerabilities, manage incidents, deploy OTA updates per the SUMS, reassess the approval if a RxSWIN changes.

Common pitfalls

Pitfall	Consequence	Good practice
Confusing ISO/SAE 21434 and R155	Believing regulatory compliance is achieved by the standard alone	Distinguish the engineering evidence (standard) from the approval certificate (regulation)
Vague item definition	Incomplete TARA, missed assets	Freeze and review the item definition before the TARA, share it with the functional-safety team
Treating the CAL as an ASIL	Over-sizing or inconsistent justification	Use the CAL as an assurance-effort factor, justify the derivation method
Neglecting post-production	R155 non-conformity on the in-service fleet	Tool up monitoring, vulnerability management and incident response from the start
OTA without RxSWIN management	An update invalidating the approval	Link each regulated function to a RxSWIN and assess the impact of every update
Functional-safety / cyber silos	A safety-impacting threat left uncoordinated	Share the item definition and analyses between the ISO 26262 and ISO/SAE 21434 teams
Expired certificates	Approval suspension	Track the three-year validity of the CSMS and SUMS certificates and plan re-audits

Sources and references

Sources & references

ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering , ISO www.iso.org/standard/70918.html
UN Regulation No. 155, Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system , UNECE unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security
UN Regulation No. 156, Uniform provisions concerning the approval of vehicles with regards to software update and software update management system , UNECE unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
ISO 26262:2018, Road vehicles, Functional safety , ISO www.iso.org/standard/68383.html
Regulation (EU) 2018/858 on the approval and market surveillance of motor vehicles , EUR-Lex eur-lex.europa.eu/eli/reg/2018/858/oj
Regulation (EU) 2019/2144 (General Safety Regulation, GSR) , EUR-Lex eur-lex.europa.eu/eli/reg/2019/2144/oj
UNECE WP.29, World Forum for Harmonization of Vehicle Regulations , UNECE unece.org/transport/vehicle-regulations