ISO/SAE 21434, UN R155 and R156: automotive cyber
Road-vehicle cybersecurity rests on two layers that are often conflated: a voluntary engineering standard, ISO/SAE 21434, and two United Nations type-approval regulations, UNECE R155 (cybersecurity management system, CSMS) and UNECE R156 (software update management system, SUMS). This page reads the regulations paragraph by paragraph from the texts published in the Official Journal, gives the EU application dates from 2022 to 2029, summarises the structure of the standard (item definition, TARA, CAL), and lists the claims the texts contradict.
A two-layer framework: standard and regulation
Section titled “A two-layer framework: standard and regulation”The first layer is normative and voluntary. ISO/SAE 21434:2021, first edition dated August 2021, was prepared jointly by ISO/TC 22/SC 32 and the SAE Vehicle Cybersecurity Systems Engineering Committee, and cancels and supersedes SAE J3061:2016. It specifies engineering requirements for cybersecurity risk management across concept, product development, production, operation, maintenance and decommissioning of road-vehicle E/E systems, and it applies to systems whose development or modification began after its publication. It does not prescribe specific technology. Its systematic review closed on 2 October 2026 and the ISO catalogue now lists it at stage 90.92, "to be revised"; the 2021 edition remains the current one until a revision is published.
The second layer is regulatory. UN Regulations No 155 and No 156 are annexed to the 1958 Agreement administered by WP.29. Their authentic texts are WP.29 documents of 2020 (ECE/TRANS/WP.29/2020/79 for R155, ECE/TRANS/WP.29/2020/80 for R156), and both entered into force on 22 January 2021. The EU published them for information in OJ L 82 of 9 March 2021.
A type-approval authority does not certify conformity to ISO/SAE 21434. It assesses the manufacturer CSMS or SUMS, issues a Certificate of Compliance, and approves each vehicle type against the regulation. Applying the standard is a common way to produce the evidence the assessor reviews, but R155 mentions ISO/SAE 21434 only in a footnote to paragraph 5.3.1, as an example (with ISO 26262 and ISO/PAS 21448) of the knowledge the approval authority staff should have.
| Dimension | ISO/SAE 21434:2021 | UN R155 / UN R156 |
|---|---|---|
| Nature | Engineering standard, voluntary | Type-approval regulation, mandatory where applied |
| Issuer | ISO/TC 22/SC 32 and SAE | WP.29, 1958 Agreement |
| Assessed unit | Item or component, organisation | Manufacturer system (CSMS, SUMS) and vehicle type |
| Output | Work products, cybersecurity case | Certificate of Compliance (max. three years) and type approval with E-mark |
| Who applies it | OEMs and suppliers | The vehicle manufacturer (or its accredited representative) |
Where the regulations apply
Section titled “Where the regulations apply”The UN regulations apply in the Contracting Parties to the 1958 Agreement that have chosen to apply them; the OJ publication points to the UNECE status document (TRANS/WP.29/343) for that list. The United States is not a party to the 1958 Agreement. The table below gives the scope written in each regulation.
| Regulation | Scope (paragraph 1) |
|---|---|
| R155 | Categories M and N; category O if fitted with at least one electronic control unit; L6 and L7 if equipped with automated driving functions from level 3 onwards |
| R156 | Categories M, N, O, R, S and T that permit software updates |
ISO/SAE 21434: structure and key concepts
Section titled “ISO/SAE 21434: structure and key concepts”The standard has normative clauses 5 to 15, each with objectives, requirements, recommendations, permissions and work products (identified as RQ, RC, PM and WP followed by clause and sequence numbers), and informative annexes A to H. Its only normative reference is ISO 26262-3:2018.
| Clause | Subject |
|---|---|
| 5 | Organizational cybersecurity management |
| 6 | Project dependent cybersecurity management |
| 7 | Distributed cybersecurity activities (customer and supplier, cybersecurity interface agreement) |
| 8 | Continual cybersecurity activities (monitoring, event evaluation, vulnerability analysis and management) |
| 9 | Concept (item definition 9.3, cybersecurity goals 9.4, cybersecurity concept 9.5) |
| 10 | Product development |
| 11 | Cybersecurity validation |
| 12 | Production |
| 13 | Operations and maintenance (incident response 13.3, updates 13.4) |
| 14 | End of cybersecurity support and decommissioning |
| 15 | Threat analysis and risk assessment methods |
Item definition and scope
Section titled “Item definition and scope”The item definition (9.3) delimits the system under analysis, its functions, interfaces and operational environment. It conditions the identification of the assets and of their cybersecurity properties, and therefore the completeness of the TARA. The concept phase then derives cybersecurity goals (9.4) and a cybersecurity concept (9.5).
The TARA methods of clause 15
Section titled “The TARA methods of clause 15”Clause 15 describes modular methods rather than a single fixed procedure.
- Asset identification (15.3): assets, their cybersecurity properties and the damage scenarios their compromise can cause.
- Threat scenario identification (15.4).
- Impact rating (15.5): Annex F gives informative guidelines, with the safety, financial, operational and privacy categories.
- Attack path analysis (15.6).
- Attack feasibility rating (15.7): Annex G gives informative guidelines.
- Risk value determination (15.8).
- Risk treatment decision (15.9): avoid, reduce, share or retain the risk.
Annex H applies these methods to a headlamp system as a worked example.
The CAL levels
Section titled “The CAL levels”CAL (cybersecurity assurance level) is described in Annex E, which is informative. The commonly cited scheme has four levels, CAL 1 to CAL 4, which scale the rigour of cybersecurity activities for an item or component. A CAL is not a measure of residual risk and does not select technical measures.
| Aspect | ASIL (ISO 26262) | CAL (ISO/SAE 21434) |
|---|---|---|
| Domain | Functional safety | Cybersecurity |
| Scale | QM, A, B, C, D | CAL 1 to CAL 4 |
| Where defined | Normative (HARA, ISO 26262-3) | Annex E, informative |
| What it scales | Requirements and methods against failures | Rigour of cybersecurity activities |
UN R155: the CSMS and the vehicle type
Section titled “UN R155: the CSMS and the vehicle type”R155 has two levels of assessment. Paragraph 6 covers the Certificate of Compliance for the CSMS, issued to the manufacturer after the approval authority or its technical service is satisfied that the processes exist (with a signed declaration following Appendix 1 to Annex 1). Paragraph 7.3 covers each vehicle type, which can only be approved if the manufacturer holds a valid CSMS certificate relevant to that type.
R155 paragraph by paragraph
Section titled “R155 paragraph by paragraph”| Paragraph | What the text requires |
|---|---|
| 6.7 | CSMS certificate valid for a maximum of three years from issue, unless withdrawn |
| 6.10 | Manufacturer applies for renewal in due time; new certificate or extension for a further three years |
| 6.11 | Expiry or withdrawal of the CSMS certificate is treated as a modification of the related vehicle approvals, which may include their withdrawal |
| 7.2.2.1 | CSMS applies to the development, production and post-production phases |
| 7.2.2.2 | Processes for managing cybersecurity, identifying risks (threats of Annex 5 Part A and other relevant threats), assessing and treating them, verifying they are managed, testing, keeping the risk assessment current, monitoring and responding to attacks, and supporting forensic analysis |
| 7.2.2.3 | Threats and vulnerabilities requiring a response are mitigated within a reasonable time |
| 7.2.2.4 | Monitoring is continual, includes vehicles after first registration, and respects privacy and consent |
| 7.2.2.5 | Dependencies on suppliers, service providers and sub-organisations are managed |
| 7.3.1 | Valid CSMS certificate relevant to the vehicle type (for approvals before 1 July 2024, a manufacturer who shows the type could not be developed under the CSMS must show cybersecurity was adequately considered in development) |
| 7.3.3 | Exhaustive risk assessment of the vehicle type, its elements, their interactions and external systems, considering all Annex 5 Part A threats |
| 7.3.4 | Proportionate mitigations, including the relevant Annex 5 Part B and C mitigations or another appropriate mitigation |
| 7.3.5 | Secure dedicated environments for after-market software, services, applications or data, if provided |
| 7.3.6 | Testing before type approval to verify the effectiveness of the security measures |
| 7.3.7 | Measures to detect and prevent attacks, support monitoring, and provide data forensic capability |
| 7.3.8 | Cryptographic modules in line with consensus standards, or justified |
| 7.4.1 | Report the outcome of monitoring to the approval authority at least once a year |
Under paragraph 5.1.2 the authority or technical service also tests a vehicle of the type, by sampling, focused on risks assessed as high.
Annex 5: threats and mitigations
Section titled “Annex 5: threats and mitigations”Annex 5 has three parts. Part A lists vulnerabilities and attack methods, grouped under seven headings (back-end servers, communication channels, update procedures, unintended human actions, external connectivity, vehicle data and code, and vulnerabilities that could be exploited if not sufficiently protected or hardened). Part B gives mitigations for the vehicle in tables B1 to B8, and Part C gives mitigations outside the vehicle, such as IT back-ends, in tables C1 to C3. Paragraph 5.1.3 lists, among the grounds for refusing type approval, a risk assessment that did not consider all the Part A threats.
UN R156: the SUMS and software updates
Section titled “UN R156: the SUMS and software updates”R156 covers every software update process for type-approved characteristics, whether by cable or over the air (OTA, defined in paragraph 2.9 as any wireless method of data transfer). The manufacturer needs a Certificate of Compliance for its SUMS, valid for a maximum of three years (paragraph 6.6). Unlike R155, paragraph 6.10 states that existing vehicle type approvals do not lose their validity when the SUMS certificate expires.
R156 paragraph by paragraph
Section titled “R156 paragraph by paragraph”| Paragraph | What the text requires |
|---|---|
| 7.1.1.2 to 7.1.1.4 | Unique identification of initial and updated software versions with integrity validation data; access to RXSWIN information before and after an update; check that software on a component matches its RXSWIN |
| 7.1.1.6 and 7.1.1.7 | Identify target vehicles and confirm compatibility with their last known configuration before issuing an update |
| 7.1.1.8 to 7.1.1.10 | Assess and record whether an update affects type-approved systems, adds or alters legislated functions, or affects safe operation |
| 7.1.1.11 | Process for informing the vehicle user about updates |
| 7.1.2.3 | Auditable register, per RXSWIN, of all relevant software before and after an update |
| 7.1.3 | Protect updates and the delivery process against manipulation and compromise |
| 7.1.4 | OTA: assess safety if updated while driving; require a skilled person where an update needs a complex action such as sensor recalibration |
| 7.2.1.1 | Authenticity and integrity of updates protected |
| 7.2.1.2 | Where RXSWIN is used: unique, readable in a standardised way at least via the OBD port, protected against unauthorised modification |
| 7.2.2.1 | OTA: restore the previous version or reach a safe state after a failed update; enough power to complete it; safe execution |
| 7.2.2.2 | Inform the user before execution: purpose, changes, expected duration, unavailable functions, instructions |
| 7.2.2.3 | If updating while driving may be unsafe, the vehicle cannot be driven during execution |
| 7.2.2.4 | Inform the user of success or failure and of the changes made |
| 9.1.3 | Authority periodically validates manufacturer decisions, in particular updates not notified to it |
The RXSWIN
Section titled “The RXSWIN”Paragraph 2.2 defines the RX Software Identification Number as an identifier, defined by the manufacturer, representing the type-approval-relevant software contributing to the characteristics approved under UN Regulation No X. The RXSWIN must be updated when a software modification leads to an extension or a new type approval (7.2.1.2.1). If RXSWIN identifiers are not held on the vehicle, the manufacturer declares the software versions linked to the relevant approvals to the authority and updates that declaration with each change (7.2.1.2.2).
EU application dates, 2022 to 2029
Section titled “EU application dates, 2022 to 2029”The UN regulations themselves contain no July 2022 or July 2024 deadline (R155 only uses 1 July 2024 for its transitional provisions in 7.3.1 and 7.3.4). The EU dates come from two different acts.
| Date | R155 (GSR 2019/2144, Annex II D4, code B) | R156 (Delegated Regulation 2022/2236, Article 2) |
|---|---|---|
| 6 July 2022 | EU type-approval refused for new types that do not comply | Type-approval refused for new types whose software the manufacturer updates after registration, if not compliant |
| 7 July 2024 | Registration, placing on the market and entry into service of non-compliant new vehicles prohibited | Type-approval refused for any non-compliant new type; registration prohibited for non-compliant new vehicles updated after registration |
| 7 July 2026 | Registration prohibited for all non-compliant new complete vehicles | |
| 7 July 2029 | Registration prohibited for non-compliant new completed (multi-stage) vehicles |
Delegated Regulation (EU) 2022/2236 inserted R156 as item H2 (software update) of Annex II to Regulation (EU) 2018/858; the GSR Annex II does not list R156. At the date of this page (October 2026), the 7 July 2026 step has passed: in the EU, a new complete vehicle without R156 compliance can no longer be registered, whether or not its manufacturer updates it after registration.
Typical manufacturer sequence
Section titled “Typical manufacturer sequence”- CSMS and SUMS: define the processes; declare them using the model in Appendix 1 to Annex 1 of each regulation.
- Certificates of Compliance: assessment by the approval authority or its technical service; certificates valid for a maximum of three years.
- Vehicle type file: R155 risk assessment and mitigations per Annex 5, test results; R156 RXSWIN or software version declaration.
- Type approval: document checks and vehicle testing by sampling; approval mark (circle with E, then the number of the regulation, R, a dash and the approval number).
- In service: continual monitoring with at least annual reporting under R155, update records under R156, renewal of certificates before expiry.
Interplay with functional safety and other cyber texts
Section titled “Interplay with functional safety and other cyber texts”ISO 26262 covers malfunctions; ISO/SAE 21434 covers intentional attacks. They are applied in parallel, and ISO/SAE 21434 uses ISO 26262-3:2018 as its normative reference. The safety impact category of the TARA is where the two analyses meet, which is why sharing the item definition between the two teams avoids inconsistent scopes.
The Cyber Resilience Act, Regulation (EU) 2024/2847, does not apply to products with digital elements to which Regulation (EU) 2019/2144 applies (Article 2(2)). Vehicles approved under the GSR therefore stay under R155 and R156, while after-market devices or charging equipment outside that scope can fall under the CRA. IEC 62443 remains the reference for industrial automation systems.
| Standard or text | Domain | Nature |
|---|---|---|
| ISO 26262 | Vehicle functional safety | Standard |
| ISO/SAE 21434 | Vehicle cybersecurity engineering | Standard |
| UNECE R155 | Cybersecurity management (CSMS) | UN Regulation |
| UNECE R156 | Software update management (SUMS) | UN Regulation |
Claims the texts contradict
Section titled “Claims the texts contradict”| Common claim | What the text says |
|---|---|
| R155 and R156 apply "from July 2022 to new types and July 2024 to all vehicles" in every country that applies them | Those are EU dates. The UN texts entered into force on 22 January 2021 and contain no such deadline; each Contracting Party sets its own application dates |
| R156 has the same EU timeline as R155, set by the GSR | The GSR Annex II lists R155 (D4) only. R156 comes from Delegated Regulation (EU) 2022/2236, with further steps on 7 July 2026 and 7 July 2029 |
| R155 requires ISO/SAE 21434 | R155 names ISO/SAE 21434 only in a footnote on approval authority competence; it requires a CSMS and a risk assessment, not conformity to the standard |
| An expired certificate suspends approvals under both regulations | R155 6.11: CSMS expiry is treated as a modification and may lead to withdrawal. R156 6.10: existing approvals keep their validity when the SUMS certificate expires |
| The certificates are valid for exactly three years | Both texts say a maximum of three years, unless withdrawn |
| R155 covers M, N and "some O" vehicles | Category O is covered if fitted with at least one ECU; L6 and L7 with level 3 automated driving are also covered |
| Annex 5 threats can be dismissed as irrelevant | The manufacturer must consider all Part A threats (7.3.3); failing to do so is a ground for refusal (5.1.3). Mitigations from Parts B and C can be replaced by another appropriate mitigation |
| Every vehicle must carry an RXSWIN | R156 requirements apply "where a vehicle type uses RXSWIN"; otherwise software versions are declared to the authority and readable via the OBD port |
| CAL is defined normatively, like ASIL | Annex E is informative |
| The Cyber Resilience Act adds a second layer on GSR vehicles | CRA Article 2(2) excludes products covered by Regulation (EU) 2019/2144 |
Common pitfalls
Section titled “Common pitfalls”| Pitfall | Consequence | Good practice |
|---|---|---|
| Treating ISO/SAE 21434 conformity as R155 compliance | Gaps against paragraph 7.2 and 7.3 requirements | Map each R155 paragraph to evidence, including Annex 5 coverage |
| Vague item definition | Incomplete TARA, missed assets | Freeze the item definition before the TARA and share it with the functional-safety team |
| Monitoring stops at start of production | Non-conformity with 7.2.2.4, nothing to report under 7.4.1 | Plan continual monitoring of registered vehicles and the annual report |
| Updates without impact assessment | An update alters approved characteristics unnoticed | Record the 7.1.2.5 items for every update and keep the RXSWIN register current |
| Ignoring the 7 July 2026 EU step | Complete vehicles no longer registrable without R156 compliance | Check that every model still in production carries R156 approval |
| Letting the CSMS certificate lapse | Related approvals treated as modified and possibly withdrawn | Apply for renewal in due time (6.10) |
Further reading
Section titled “Further reading”- ISO 26262: automotive functional safety: the sister functional-safety standard, applied in parallel with ISO/SAE 21434.
- UN R10 (ECE R10): automotive EMC and the E-mark: another UN Regulation under the 1958 Agreement, with the same approval mark logic.
- IEC 62443 and ISA-99: industrial cybersecurity: the cyber framework for automation systems, relevant to vehicle-related infrastructure.
- Cyber Resilience Act (CRA): the horizontal European regulation on products with digital elements, which excludes GSR vehicles.
- IATF 16949: automotive quality: the quality framework within which cyber production processes sit.
- EV charging: IEC 61851, ISO 15118, OCPP: the charging ecosystem, where vehicle cyber and industrial cyber meet.
- Glossary: definitions of CSMS, SUMS, TARA, CAL, RxSWIN, OTA and item.
Sources and references
Section titled “Sources and references”Sources & references
- ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering (catalogue entry), ISO www.iso.org/standard/70918.html
- UN Regulation No 155, cybersecurity and cybersecurity management system (OJ L 82, 9.3.2021, p. 30), EUR-Lex eur-lex.europa.eu/eli/reg/2021/387/oj
- UN Regulation No 156, software update and software update management system (OJ L 82, 9.3.2021, p. 60), EUR-Lex eur-lex.europa.eu/eli/reg/2021/388/oj
- Regulation (EU) 2019/2144 (General Safety Regulation), Annex II item D4 and date codes, EUR-Lex eur-lex.europa.eu/eli/reg/2019/2144/oj
- Commission Delegated Regulation (EU) 2022/2236, software update (UN R156), Article 2, EUR-Lex eur-lex.europa.eu/eli/reg_del/2022/2236/oj
- 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) 2024/2847 (Cyber Resilience Act), Article 2(2), EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
- ISO 26262:2018, Road vehicles, Functional safety, ISO www.iso.org/standard/68383.html
- UNECE WP.29, World Forum for Harmonization of Vehicle Regulations, UNECE unece.org/transport/vehicle-regulations
Frequently asked questions
- What is the difference between ISO/SAE 21434 and UN Regulations 155 and 156 ?
- ISO/SAE 21434:2021 is a voluntary engineering standard (first edition August 2021, prepared by ISO/TC 22/SC 32 and SAE) for cybersecurity risk management of road-vehicle E/E systems. UN Regulations No 155 and No 156 are type-approval regulations under the 1958 Agreement: the vehicle manufacturer needs a Certificate of Compliance for its cybersecurity management system (CSMS) and its software update management system (SUMS), and each vehicle type is then approved. R155 does not make ISO/SAE 21434 mandatory: it names the standard only in a footnote, as an example of the knowledge approval-authority staff should have.
- What does a CSMS under R155 have to cover ?
- Paragraph 7.2 of R155 requires the CSMS to apply to the development, production and post-production phases, with processes for risk identification (including the Annex 5 Part A threats), risk assessment and treatment, testing, keeping the risk assessment current, monitoring and responding to cyberattacks, and providing data for forensic analysis. Monitoring must be continual and include vehicles after first registration. The manufacturer must also report the outcome of its monitoring to the approval authority at least once a year (paragraph 7.4.1).
- How long is the R155 or R156 certificate of compliance valid ?
- A maximum of three years from issue, unless withdrawn (R155 paragraph 6.7, R156 paragraph 6.6), with renewal or extension for further three-year periods. The consequences of expiry differ: under R155 (paragraph 6.11) expiry or withdrawal of the CSMS certificate is treated as a modification of the vehicle approvals concerned and may lead to their withdrawal, whereas under R156 (paragraph 6.10) existing type approvals do not lose their validity when the SUMS certificate expires.
- What is the CAL level in ISO/SAE 21434 ?
- CAL means cybersecurity assurance level. It is described in Annex E of ISO/SAE 21434, which is informative, and the commonly cited scheme has four levels, CAL 1 to CAL 4. A CAL scales the rigour of cybersecurity activities for an item or component; it does not measure residual risk and it does not prescribe technical measures.
- What is the TARA ?
- TARA means threat analysis and risk assessment. Clause 15 of ISO/SAE 21434 describes it as modular methods: asset identification (15.3), threat scenario identification (15.4), impact rating (15.5), attack path analysis (15.6), attack feasibility rating (15.7), risk value determination (15.8) and risk treatment decision (15.9). Annexes F and G give informative guidelines for impact and attack feasibility rating, and Annex H works through a headlamp example.
- From when are R155 and R156 mandatory in the European Union ?
- R155 is required by the General Safety Regulation (EU) 2019/2144, Annex II item D4, with date code B: EU type-approval refused for non-compliant new types from 6 July 2022, registration of non-compliant new vehicles prohibited from 7 July 2024. R156 came through Delegated Regulation (EU) 2022/2236 amending Regulation (EU) 2018/858: from 6 July 2022 for new types whose software is updated after registration, from 7 July 2024 for all new types and for new vehicles updated after registration, from 7 July 2026 for all new complete vehicles and from 7 July 2029 for completed (multi-stage) vehicles.
- Which vehicles do R155 and R156 cover ?
- R155 applies to categories M and N, to category O if fitted with at least one electronic control unit, and to L6 and L7 vehicles with automated driving functions from level 3 onwards. R156 applies to categories M, N, O, R, S and T that permit software updates. In the EU, the GSR Annex II row D4 for R155 marks the M and N categories.
- What is the RXSWIN ?
- In R156 (paragraph 2.2) the RX Software Identification Number is an identifier defined by the manufacturer for the type-approval-relevant software contributing to the characteristics approved under UN Regulation No X. RXSWIN is used where a vehicle type has one: each RXSWIN must be uniquely identifiable, readable in a standardised way at least through the OBD port, protected against unauthorised modification, and updated when a software change leads to an extension or a new type approval. Without an on-board RXSWIN, the manufacturer declares the software versions to the approval authority instead.