UNECE R155/R156: Automotive Cybersecurity & Software Update Compliance

UN Regulations No. 155 and No. 156 make cyber security and software update management conditions of vehicle type approval. Both entered into force on 22 January 2021. The R155 text that applies today is the consolidated version incorporating all valid text up to Supplement 3, in force from 10 January 2025 and published in the Official Journal as 2025/5. That supplement changed the scope. R155 now applies, verbatim, “to vehicles, with regard to cyber security, of Categories L, M, N and O, if fitted with at least one electronic control unit” (R155 para 1.1). Summaries that still limit R155 to Categories M and N, with an L6/L7 carve-out tied to level 3 automated driving, are describing superseded text.

For an embedded software team the useful question is narrower than “are we compliant”. It is: which clauses reach the source code, the toolchain and the test evidence, and what does an Approval Authority actually inspect. This page answers that from the regulations’ own text. Every normative statement below carries its clause, paragraph or Annex table number. Where the regulations say nothing, this page says so rather than filling the gap.

---

R155: the Cyber Security Management System

R155 defines a CSMS, verbatim, as “a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks” (R155 para 2.3). It is an organisational obligation on the vehicle manufacturer, assessed separately from any individual vehicle type.

The certificate, and what its expiry costs

The Certificate of Compliance for CSMS is issued by an Approval Authority appointed by the Contracting Party, after the manufacturer declares and then demonstrates that it has the necessary processes in place (R155 paras 6.1, 6.4 and 6.5). Verbatim, “The Certificate of Compliance for CSMS shall remain valid for a maximum of three years from the date of deliverance of the certificate unless it is withdrawn” (R155 para 6.7). On a positive re-assessment the Authority issues a new certificate or extends validity “for a further period of three years” (R155 para 6.10).

Letting that certificate lapse is not an administrative inconvenience. Expiry or withdrawal is treated, for the vehicle types concerned, as a modification of approval under paragraph 8, “which may include the withdrawal of the approval if the conditions for granting the approval are not met anymore” (R155 para 6.11).

Three lifecycle phases

The CSMS must apply to three phases: (a) the development phase, (b) the production phase, and (c) the post-production phase (R155 para 7.2.2.1). The post-production phase is not bounded by warranty or by the end of a model run. R155 defines it as running until the end of life of all vehicles of that type (R155 paras 2.5, 2.6 and 2.7). A CSMS scoped only to the engineering programme does not satisfy the clause.

The eight process demonstrations

The manufacturer must demonstrate CSMS processes covering eight items, (a) to (h), under R155 para 7.2.2.2. Four of them bear directly on the software toolchain:

• (b) identification of risks to vehicle types, taking into account the threats listed in Annex 5 Part A
• (e) verbatim, “The processes used for testing the cyber security of a vehicle type”
• (g) monitoring, detection of and response to cyber attacks, threats and vulnerabilities
• (h) providing the data needed to support analysis of attempted or successful cyber attacks

Monitoring under (g) is qualified further. It must be continual, it must cover vehicles after first registration, and it must include the capability to analyse and detect threats, vulnerabilities and cyber attacks from vehicle data and vehicle logs, with privacy rights and consent respected (R155 paras 7.2.2.4(a) and (b)).

Supplier dependencies, the clause that reaches India

R155 para 7.2.2.5 requires the manufacturer to demonstrate how the CSMS manages dependencies with contracted suppliers, service providers and sub-organizations in regard of the 7.2.2.2 requirements. R155 para 7.3.2 additionally requires supplier-related risks to be identified and managed for the vehicle type. Between them, these two clauses are why an obligation formally placed on the vehicle manufacturer arrives, in contract form, at Tier-1 and Tier-2 suppliers and at offshore engineering centres.

What the Authority inspects at type approval

Approval of a vehicle type is a two-stage check. The Authority first performs document checks that the manufacturer has documented the risk assessment, the test results and the mitigations applied, including supporting design information (R155 para 5.1.1(b)). It then verifies by testing a vehicle of the type that the documented cyber security measures were actually implemented, using sampling focused on the highest assessed risks (R155 para 5.1.2).

Three further clauses set what has to exist before that inspection:

• An exhaustive risk assessment for the vehicle type covering individual elements, their interactions, interactions with external systems, and all threats referred to in Annex 5 Part A, plus any other relevant risk (R155 para 7.3.3)
• Verbatim, “The vehicle manufacturer shall perform, prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented” (R155 para 7.3.6). Failing to do so is an explicit ground for refusing type approval (R155 para 5.1.3(d))
• Verbatim, “Cryptographic modules used for the purpose of this Regulation shall be in line with consensus standards. If the cryptographic modules used are not in line with consensus standards, then the vehicle manufacturer shall justify their use” (R155 para 7.3.8)

Documentation retention and annual reporting

The formal documentation package specified in Annex 1 must be supplied at application and must remain available for at least 10 years after production of the vehicle type is definitively discontinued. The same 10-year availability applies to the additional material the manufacturer retains (R155 paras 3.3(a) and 3.3(b)).

Reporting is continuous, not one-off. The manufacturer must report at least once a year to the Approval Authority or Technical Service on the outcome of its monitoring activities, including information on new cyber attacks, and must confirm that the mitigations implemented are still effective (R155 paras 7.4.1 and 7.4.2). Insufficient reporting can lead to withdrawal of the CSMS certificate (R155 para 6.8).

Transitional relief

The current text carries a limited carve-out. For type approvals of Categories M, N and O first issued before 1 July 2024, and Category L first issued before 1 July 2029, a manufacturer that can show the type could not be developed in compliance with the CSMS must instead demonstrate that cyber security was adequately considered during the development phase (R155 para 7.3.1). The same date split applies to the technical-feasibility carve-out on the Annex 5 Part B and Part C mitigations (R155 para 7.3.4).

---

R156: the Software Update Management System

R156 scope is different from R155 and wider in one direction. Verbatim: “This Regulation applies to vehicles of Categories M, N, O, R, S and T that permit software updates” (R156 para 1.1). Categories R, S and T bring agricultural trailers and machinery into scope, which R155 does not cover.

R156 defines RXSWIN verbatim as “a dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software of the Electronic Control System contributing to the Regulation No X type approval relevant characteristics of the vehicle”, and SUMS as “a systematic approach defining organizational processes and procedures to comply with the requirements for delivery of software updates according to this Regulation” (R156 paras 2.2 and 2.5).

A materially different consequence on expiry

The SUMS Certificate of Compliance also lasts three years and renews for a further three after positive assessment (R156 paras 6.6 and 6.9). What happens on expiry is where R156 diverges sharply from R155. Verbatim: “Existing vehicle type approvals shall not lose their validity due to the expiration of the manufacturer’s Certificate of Compliance for Software Update Management System” (R156 para 6.10). Under R155 para 6.11, by contrast, CSMS expiry is treated as a modification of approval that may lead to withdrawal. Programme planning that assumes the two regulations behave the same way here is planning against the wrong risk.

Twelve processes assessed

The SUMS initial assessment verifies twelve processes (R156 paras 7.1.1.1 to 7.1.1.12):

Clause	Process
7.1.1.1	Documentation securely held and available to the Authority on request
7.1.1.2	Unique identification of all initial and updated software versions, including integrity validation data
7.1.1.3 and 7.1.1.4	RXSWIN access, update and consistency verification
7.1.1.5	Interdependencies between updated systems
7.1.1.6	Identification of target vehicles
7.1.1.7	Compatibility confirmation before an update is issued
7.1.1.8 to 7.1.1.10	Assessment of the impact on type approval and on safe operation
7.1.1.11	Informing the vehicle user
7.1.1.12	Making information available to Authorities for type approval, conformity of production, market surveillance, recalls and Periodic Technical Inspection

The RXSWIN register and per-update evidence

For every RXSWIN there must be an auditable register describing all software relevant to that RXSWIN before and after an update, including software versions and their integrity validation data (R156 para 7.1.2.3). Per-update documentation must include, verbatim, “(h) Confirmation that the software update will be conducted safely and securely” and “(i) Confirmation that the software update has undergone and successfully passed verification and validation procedures” (R156 para 7.1.2.5).

The security clause

R156 para 7.1.3 requires the manufacturer to demonstrate three things: that updates are protected against manipulation before the update process is initiated (7.1.3.1), that the update processes themselves are protected against compromise including development of the update delivery system (7.1.3.2), and, verbatim, “The processes used to verify and validate software functionality and code for the software used in the vehicle are appropriate” (7.1.3.3).

That last sentence is the clearest statement anywhere in either regulation that code verification and validation practice is itself an object of assessment.

Vehicle-level requirements

Verbatim, “The authenticity and integrity of software updates shall be protected to reasonably prevent their compromise and reasonably prevent invalid updates” (R156 para 7.2.1.1). Each RXSWIN must be “easily readable in a standardized way via the use of an electronic communication interface, at least by the standard interface (OBD port)”, and RXSWINs and software versions must be protected against unauthorised modification (R156 paras 7.2.1.2.2 and 7.2.1.2.3).

For over-the-air updates specifically, R156 para 7.2.2 adds that the vehicle “is able to restore systems to their previous version in case of a failed or interrupted update or that the vehicle can be placed into a safe state” (7.2.2.1.1), that updates execute only with enough power to complete including recovery or safe state (7.2.2.1.2), that safe execution is demonstrated by technical means (7.2.2.1.3), that five specified items of user information are given before execution (7.2.2.2), that the vehicle cannot be driven during an unsafe execution (7.2.2.3), that the user is informed of success or failure and of what changed (7.2.2.4), and that preconditions are met before execution (7.2.2.5).

---

Annex 5 of R155: where the regulation names technical mitigations

R155 Annex 5 has three parts (Annex 5 paras 1 and 3). Part A is the baseline of threats, vulnerabilities and attack methods. Part B lists mitigations intended for vehicle types. Part C lists mitigations for areas outside the vehicle, for example IT backends. Part A indexing is cross-referenced from the Part B and Part C tables, so a mitigation is always read against a specific threat.

Annex 5 Part A, Table A1 groups threats under seven high-level categories numbered 4.3.1 to 4.3.7: back-end servers; communication channels; update procedures; unintended human actions; external connectivity and connections; vehicle data and code; and potential vulnerabilities that could be exploited if not sufficiently protected or hardened. Individual threats are indexed up to 32, though some index numbers are unused, so no threat count should be quoted.

Part B contains eight tables: B1 Vehicle communication channels, B2 Update process, B3 Unintended human actions facilitating a cyber attack, B4 External connectivity and connections, B5 Potential targets of, or motivations for, an attack, B6 Potential vulnerabilities that could be exploited if not sufficiently protected or hardened, B7 Data loss and data breach from vehicle, and B8 Physical manipulation of systems to enable an attack. Part C contains C1 Back-end servers, C2 Unintended human actions and C3 Physical loss of data.

Table B6, mitigation M23, the software-development row

One row in Annex 5 speaks directly to how software is written and tested. In Table B6, threat 28.1 reads: “The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present”. The mitigation, M23, reads verbatim:

“Cybersecurity best practices for software and hardware development shall be followed.”

with a second line:

“Cybersecurity testing with adequate coverage”

Those two lines are the only place in the regulation’s own mitigation catalogue that asks for software-development discipline and for test coverage. Read together with R155 para 7.2.2.2(e), R155 para 7.3.6 and R156 para 7.1.3.3, they mark out where a static analysis and unit-test toolchain has direct standing in the regulatory text rather than in a standard adopted alongside it.

The other mitigations that shape an embedded design

Mitigation	Verbatim text	Against
M6	”Systems shall implement security by design to minimize risks”	Table B1, threat 5.1, code injection through a communication channel
M10	”The vehicle shall verify the authenticity and integrity of messages it receives”	Table B1, threats 4.1, 5.1, 6.1, 6.2 and 11.2
M11	”Security controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules)“	Table B1 threat 4.2, quoted above; the same mitigation reference also appears against Table B2 threat 12.4 and Table B5 threat 19.3 in slightly shorter wording
M12	”Confidential data transmitted to or from the vehicle shall be protected”	Table B1, threat 7.1, interception of information
M16	”Secure software update procedures shall be employed”	Table B2, threat 12.1, compromise of over the air software update procedures
M20	”Security controls shall be applied to systems that have remote access”	Table B4
M21	”Software shall be security assessed, authenticated and integrity protected. Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle”	Table B4, threat 17.1

---

What the regulations do not require

Three claims circulate widely about R155 and R156 that their texts do not support, and one relationship is routinely overstated. Each is worth settling plainly, because compliance plans get built on them.

Neither regulation makes conformity with an ISO standard a compliance route. R156 contains no reference to any ISO standard at all. R155 mentions ISO/SAE 21434 exactly once, in footnote (1) attached to paragraph 5.3.1(a), which concerns the competence of the Approval Authority’s and Technical Service’s own personnel. The footnote reads, verbatim: “E.g. ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434.” That is a personnel-competence reference, not an accepted evidence path.

R155 never uses the term TARA. The phrase “threat analysis” appears once, in Annex 5 paragraph 4, on possible attack impacts. Threat Analysis and Risk Assessment is an ISO/SAE 21434 term and should be attributed there, not presented as an R155 requirement. What R155 does require is the exhaustive risk assessment of para 7.3.3, which covers all Annex 5 Part A threats.

Neither regulation requires a Software Bill of Materials. There is no SBOM obligation in either text. An SBOM may be a sound engineering practice and may be required by other instruments, but citing R155 or R156 as its source is incorrect.

The two ISO standards commonly paired with these regulations are engineering frameworks, and both say so. ISO/SAE 21434, “Road Vehicles - Cybersecurity Engineering”, was issued on 31 August 2021 (edition 1, 81 pages). Its scope states that it “specifies 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”, and adds that it “does not prescribe specific technology or solutions related to cybersecurity”. ISO 24089:2023, “Road vehicles - Software update engineering”, was published in February 2023 (edition 1, 24 pages, committee ISO/TC 22/SC 32). Its scope states that it “specifies requirements and recommendations for software update engineering for road vehicles on both the organizational and the project level”, that “the development of software for vehicle functions, except for software update engineering, is outside the scope of this document”, and that “this document does not prescribe specific technologies or solutions for software update engineering”. Teams adopt them because they are useful, not because a regulation names them as an approval route.

---

EU enforcement: two regulations, two different instruments

The proposals for the new UN Regulations on cyber security and CSMS and on software update and SUMS were on the agenda of the 181st session of UNECE WP.29 held on 23 June 2020, and the EU position was to vote in favour (Council Decision (EU) 2020/848 of 16 June 2020, recitals and Article 1).

In EU law the two regulations then arrived by different routes, on different dates. This is the single most common error in R155/R156 planning material.

R155 comes in through Regulation (EU) 2019/2144. Annex II lists requirement row “D4 Protection of vehicle against cyberattacks” against regulatory act “UN Regulation No 155” with date code B. The Notes to that table define code B as a date for refusal to grant EU type-approval of 6 July 2022, and a date for prohibition of registration of vehicles and of placing on the market and entry into service of components and separate technical units of 7 July 2024. Annex I lists UN Regulation 155 with scope M, N, O.

R156 is not in Annex I or Annex II of Regulation (EU) 2019/2144 at all. It was brought into EU type approval by Commission Delegated Regulation (EU) 2022/2236 of 20 June 2022, amending Annexes I, II, IV and V to Regulation (EU) 2018/858. Its Annex IV amendment reads, verbatim: “5. Arrangements concerning software update - The software update management system of the manufacturer as well as the whole vehicle type shall comply with the requirements as set out in UN Regulation 156.” The transitional dates are set out in Article 2 of that Delegated Regulation and run further out than the R155 dates.

Instrument	Date	What it triggers
Reg. (EU) 2019/2144, Annex II row D4, code B	6 July 2022	Refusal to grant EU type-approval (R155)
Reg. (EU) 2019/2144, Annex II row D4, code B	7 July 2024	Prohibition of registration, and of placing on the market and entry into service of components and separate technical units (R155)
Del. Reg. (EU) 2022/2236, Art. 2(1)	6 July 2022	Refusal of type approval for a new type where the manufacturer executes software updates affecting type-approved characteristics after registration, if non-compliant
Del. Reg. (EU) 2022/2236, Art. 2(3) to 2(5)	7 July 2024	Certificates of conformity invalid and registration prohibited for such new vehicles; refusal of type approval for any new vehicle type if non-compliant; refusal of approval for small-series and special-purpose vehicles
Del. Reg. (EU) 2022/2236, Art. 2(6) and 2(7)	7 July 2026	Certificates of conformity invalid for new complete vehicles and for small-series and special-purpose vehicles
Del. Reg. (EU) 2022/2236, Art. 2(8)	7 July 2029	Certificates of conformity invalid for new completed vehicles
R155 para 6.7, R156 para 6.6	Every 3 years	CSMS and SUMS certificates expire and must be re-assessed

---

Where a verification toolchain actually attaches

Everything below is anchored to a clause or an Annex 5 mitigation. Where the connection is an engineering argument rather than a regulatory requirement, this page says so.

Static analysis of the shipped source

R155 Annex 5 M23 asks that “Cybersecurity best practices for software and hardware development shall be followed”. R156 para 7.1.3.3 asks that the processes used to verify and validate software functionality and code are appropriate. R155 para 5.1.1(b) is where the Authority checks the resulting documentation. Static analysis is how a team makes those three sentences auditable.

Perforce Klocwork is a SAST engine for C, C++, C#, Rust, Java, JavaScript, Python and Kotlin, with CWE and the CWE Top 25, OWASP, CERT, PCI DSS, DISA STIG and ISO/IEC TS 17961 security taxonomies alongside MISRA C:2023 and AUTOSAR C++14. Its incremental, diff-based inter-procedural dataflow analysis scans only changed files while reporting whole-system results, which is what lets it run as a CI gate rather than a periodic audit.

Perforce Helix QAC covers C and C++ with MISRA C:2025, MISRA C:2023, MISRA C++:2023, AUTOSAR C++14, CERT and CWE, using separate dedicated parsers for each language, and ships TUV SUD certified qualification kits. Perforce positions QAC as the gold standard for MISRA, and that superlative is Perforce’s rather than a GSAS claim. One point of frequent confusion is worth settling: Helix QAC is a static code analysis tool for C and C++, formerly sold as PRQA QA-C and QA-C++. It is not a version control system, and GSAS does not carry Perforce Helix Core.

Dynamic testing and coverage evidence

M23’s second line asks for “Cybersecurity testing with adequate coverage”. R155 para 7.3.6 requires appropriate and sufficient testing prior to type approval, and para 5.1.3(d) makes its absence a ground for refusal. R156 para 7.1.2.5(i) requires per-update confirmation that verification and validation procedures were passed. Those are coverage-evidence obligations, and static analysis alone does not discharge them.

Razorcat TESSY performs unit, module and integration testing of embedded C and C++ with C0, C1, decision, MC/DC and MCC coverage, automated test driver and stub generation, ReqIF requirements traceability, and batch execution from CI. Razorcat CTE, the Classification Tree Editor, covers the systematic test-design half: defining input partitions and boundary conditions so the resulting coverage figure is defensible rather than incidental.

Compiler and standard library qualification

This one is an engineering argument, not a regulatory requirement, and should be presented that way. Neither R155 nor R156 names compiler qualification. But R156 para 7.1.3.3 asks whether the processes used to verify and validate code are appropriate, and the compiler and the C or C++ standard library sit between verified source and the binary that ships. R155 Annex 5 M21 separately asks that software be “security assessed, authenticated and integrity protected”, with controls to minimise risk from third party software hosted on the vehicle.

Solid Sands SuperTest is a compiler test and validation suite; the SuperTest Qualification Suite packages the evidence for tool qualification; SuperGuard is the library safety qualification suite covering the standard library the application links against. A manufacturer that has verified its source with static analysis and unit test, but has never established that the toolchain preserves that behaviour, has a gap it may reasonably be asked about.

Cryptography, secure boot and secure update

R155 para 7.3.8 requires cryptographic modules to be in line with consensus standards, or the manufacturer must justify their use. Annex 5 adds M10 on message authenticity and integrity, M6 on security by design, M11 on key storage, M12 on protecting confidential data in transit, M16 on secure software update procedures, M20 on remote-access controls and M21 on software integrity. R156 para 7.2.1.1 requires the authenticity and integrity of software updates to be protected, and para 7.1.3.2 extends protection to the update delivery system itself.

• SEGGER emCrypt provides AES, SHA-2 and SHA-3, ECDSA, Ed25519, RSA-PSS and ECDH, and is the cryptographic engine underneath the SEGGER security stack. It is the component that R155 para 7.3.8 and mitigations M10, M11 and M12 are talking about. M6, by contrast, is a security-by-design obligation on the system, not a cryptographic primitive, so no library discharges it.
• SEGGER emSecure and emBoot-Secure verify RSA and ECDSA firmware signatures and establish a secure boot chain of trust from boot ROM to application. With emLoad for the bootloader and update path, they map to R156 para 7.2.1.1 and to Annex 5 M16 and M21. One caution: emBoot-Secure’s rollback protection reverts to the last known-good image if a new one fails validation, which is anti-downgrade behaviour at the device level. It is not the same thing as the R156 para 7.2.2.1.1 obligation on the vehicle to restore systems to their previous version or reach a safe state, and the two should not be equated in a compliance argument.
• SEGGER emSSL and emSSH protect the channel, mapping to M12 and M20 and to protecting the update delivery path under R156 para 7.1.3.2.
• SEGGER Flasher Secure stores decryption keys in a tamper-resistant hardware secure element, decrypts firmware only inside that hardware, provisions unique device certificates during programming and keeps a signed audit trail. That maps to Annex 5 M11 on cryptographic key storage, and to the production phase the CSMS must cover under R155 para 7.2.2.1(b).

Requirements, test and change evidence

R156 para 7.1.1.1 requires documentation to be securely held and available to the Authority on request, and R156 para 7.1.2 sets out the record set behind every RXSWIN and every update. R155 paras 3.3(a) and 3.3(b) require the Annex 1 documentation package to remain available for at least 10 years after production of the type is definitively discontinued.

Perforce Helix ALM manages requirements, test cases and issues with the traceability that record set implies. A 10-year retention obligation is a tooling decision as much as a filing decision.

---

What GSAS does not do

Being useful here means being clear about the boundary.

GSAS is not a Type Approval Authority and not a Technical Service. GSAS does not issue CSMS or SUMS Certificates of Compliance; those are issued by an Approval Authority after its own assessment (R155 paras 6.1 and 6.5, R156 paras 6.1 and 6.5). GSAS does not audit management systems. GSAS carries no TARA product, no penetration-testing tool, no fuzzing platform and no vulnerability-intelligence feed. No tool GSAS supplies delivers, provides or accelerates certification.

What GSAS does supply and support is the verification tooling and the embedded security components described above, with local field application engineering behind them.

---

India: a supply-chain obligation, not a domestic mandate

India is not a Contracting Party to the UNECE 1958 Agreement. The United Nations Treaty Collection status page for Chapter XI-B-16 lists 62 Parties, and India does not appear among them. India acceded to the 1998 Agreement, the Agreement concerning the Establishing of Global Technical Regulations for Wheeled Vehicles, on 21 February 2006. That agreement produces UN Global Technical Regulations and carries no mutual recognition of type approvals, so it does not bring R155 or R156 into Indian domestic type approval.

R155 and R156 still reach Indian engineering teams, and the route is contractual rather than regulatory. R155 para 7.2.2.5 makes the vehicle manufacturer responsible for demonstrating how its CSMS manages dependencies with contracted suppliers, service providers and sub-organizations, and R155 para 7.3.2 requires supplier-related risks to be identified and managed for the vehicle type. A manufacturer seeking EU type approval has to satisfy those clauses across its whole supply base. The requirement then flows down through development interface agreements to Tier-1 and Tier-2 suppliers and to offshore engineering centres, wherever they sit. An Indian team writing ECU software for a programme headed for EU type approval is inside that perimeter whether or not India ever adopts the regulations domestically.

The practical consequence for an Indian supplier is evidence. Static analysis results, unit test and coverage records, requirements traceability, cryptographic design justification and update-path security documentation all have to survive an OEM’s audit and end up in a package the Approval Authority can inspect under R155 para 5.1.1(b).

GSAS Micro Systems is an engineering partner working with 25 technology partners, among them Perforce, Razorcat, SEGGER and Solid Sands, and supports the tools above from 11 physical locations in Bengaluru, Chennai, Coimbatore, Delhi NCR, Hyderabad, Mumbai, Pune, Vadodara and Visakhapatnam. That means field application engineering on the toolchain itself, on site, in the same time zone as the build that failed. Automotive and embedded teams in Bengaluru, Chennai, Pune, Hyderabad and Delhi NCR reach a GSAS application engineer directly rather than through an overseas support queue.

---

Frequently asked questions

What is the difference between UN R155 and ISO/SAE 21434?

R155 is a UN Regulation and a condition of vehicle type approval. ISO/SAE 21434, “Road Vehicles - Cybersecurity Engineering”, is a standard that, in its own words, “specifies engineering requirements for cybersecurity risk management” and “does not prescribe specific technology or solutions related to cybersecurity”. R155 does not make conformity with ISO/SAE 21434 a compliance route. The only mention of ISO/SAE 21434 anywhere in R155 is footnote (1) to paragraph 5.3.1(a), which is about the competence of the Approval Authority’s and Technical Service’s own personnel and reads “E.g. ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434.” Many teams adopt ISO/SAE 21434 as their engineering method, which is a reasonable choice, but the evidence still has to be assessed against R155’s own clauses.

Does R155 apply to vehicles sold in India?

Not through Indian domestic law. India is not among the 62 Parties listed for the UNECE 1958 Agreement in the UN Treaty Collection. India acceded to the 1998 Agreement on 21 February 2006, which produces Global Technical Regulations and carries no mutual recognition of type approvals. R155 and R156 reach Indian suppliers and engineering centres through OEM programmes instead, because R155 paras 7.2.2.5 and 7.3.2 make the vehicle manufacturer responsible for supplier dependencies and supplier-related risks in the vehicle type it is getting approved.

How long is a CSMS certificate valid, and what happens if it lapses?

Verbatim, R155 para 6.7: “The Certificate of Compliance for CSMS shall remain valid for a maximum of three years from the date of deliverance of the certificate unless it is withdrawn.” On a positive re-assessment the Authority issues a new certificate or extends validity for a further three years (para 6.10). If it expires or is withdrawn, that is treated for the vehicle types concerned as a modification of approval under paragraph 8, “which may include the withdrawal of the approval if the conditions for granting the approval are not met anymore” (para 6.11). Note that R156 works differently: under R156 para 6.10, “Existing vehicle type approvals shall not lose their validity due to the expiration of the manufacturer’s Certificate of Compliance for Software Update Management System.”

Do R155 and R156 share an EU enforcement timeline?

No, and treating them as one timeline is a planning error. R155’s EU dates come from Regulation (EU) 2019/2144, Annex II row D4 with date code B: 6 July 2022 for refusal to grant EU type-approval, 7 July 2024 for prohibition of registration and of placing components and separate technical units on the market. R156 is not in that Annex at all. It was brought in by Commission Delegated Regulation (EU) 2022/2236, whose Article 2 sets a qualified 6 July 2022 date for new types where the manufacturer executes post-registration software updates affecting type-approved characteristics, then 7 July 2024, 7 July 2026 and 7 July 2029 triggers for different vehicle categories and completion stages.

What does R155 say about software testing?

Three places. R155 para 7.2.2.2(e) requires the manufacturer to demonstrate “The processes used for testing the cyber security of a vehicle type” as part of its CSMS. R155 para 7.3.6 states verbatim: “The vehicle manufacturer shall perform, prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented”, and para 5.1.3(d) makes failure to do so an explicit ground for refusing type approval. And Annex 5 Part B Table B6, mitigation M23 against threat 28.1, asks for “Cybersecurity testing with adequate coverage”. R156 para 7.1.3.3 adds the corresponding software-update requirement: “The processes used to verify and validate software functionality and code for the software used in the vehicle are appropriate.”

Does R155 or R156 require an SBOM?

No. Neither regulation contains an SBOM requirement. R156 para 7.1.2.3 does require an auditable register describing all software relevant to each RXSWIN before and after an update, including software versions and their integrity validation data, and R156 para 7.1.1.2 requires unique identification of all initial and updated software versions. Those are software identification and integrity obligations, and they are narrower than an SBOM. If your programme needs an SBOM, cite the instrument that actually requires it.

How do R155 and R156 affect over-the-air updates?

R156 para 7.2.2 is the OTA clause. The vehicle must be able to restore systems to their previous version after a failed or interrupted update, or reach a safe state (7.2.2.1.1). Updates must execute only with enough power to complete, including recovery or safe state (7.2.2.1.2). Safe execution must be demonstrated by technical means (7.2.2.1.3). Five specified items of user information must be given before execution (7.2.2.2), the vehicle must not be drivable during an unsafe execution (7.2.2.3), the user must be told whether the update succeeded and what changed (7.2.2.4), and preconditions must be met before execution (7.2.2.5). Alongside these, R156 para 7.2.1.1 requires the authenticity and integrity of updates to be protected, and R155 Annex 5 M16 requires that “Secure software update procedures shall be employed”.

Which vehicle categories are in scope?

R155 para 1.1, verbatim: “This Regulation applies to vehicles, with regard to cyber security, of Categories L, M, N and O, if fitted with at least one electronic control unit.” R156 para 1.1, verbatim: “This Regulation applies to vehicles of Categories M, N, O, R, S and T that permit software updates.” The two are not identical. R156 covers agricultural categories R, S and T, which R155 does not, and R155 covers Category L, which R156 does not. In EU law, Annex I of Regulation (EU) 2019/2144 lists UN Regulation 155 with scope M, N, O.

---

Talk to a GSAS engineer

If you are carrying R155 or R156 flow-down requirements from an OEM programme, the useful conversation is about evidence: which static analysis and unit test configuration will satisfy your customer’s audit, how coverage records get produced repeatably from CI, and which cryptographic and secure-update components fit your target.

Talk to a Compliance Specialist

Bring your target standard, your MCU family and your existing pipeline. GSAS engineers will scope a toolchain against the clauses above and run an evaluation on your own codebase before you commit.

---

Related compliance pages: ISO 26262 Functional Safety | MISRA & AUTOSAR Compliance | EU Cyber Resilience Act

Related solutions: Automotive Solutions | Security Engineering