Proposal to amend UN R155 and UN R156 regarding approval authority requirements:

• Add a refusal ground to para. 5.1.3. of UN R155 where the Certificate of Compliance for the Cyber Security Management System has not been issued by the same approval authority granting type approval
• Insert new para. 5.4. into UN R156 to provide that approval authorities shall not grant any type approval if the Certificate of Compliance for the Software Update Management System has not been issued by the same approval authority granting type approval.

Proposal to amend para. 5.1.3., insert new paras. 5.1.5. and 5.1.5.1. requiring the Approval Authority to refuse type approval unless the Certificate of Compliance for the Cyber Security Management System is issued by the same Approval Authority granting vehicle type approval, while permitting referencing of certificates from other Approval Authorities under specific conditions with documented agreements and clarified responsibilities, and insert new paras. 5.4. and 5.4.1. with equivalent requirements for the Software Update Management System Certificate of Compliance.

Proposal to amend paragraph AI to introduce a link between existing text in Part A and new text in Part C regarding vehicle transformations, and insert new Part C providing guidance for the application of UN Regulation No. 155 to transformed vehicles. The proposal adds section 6 clarifying that the requirement for the Certificate of Compliance and type approval to be issued by the same Approval Authority applies only within the scope of the type approval granted to the manufacturer concerned, and does not restrict another manufacturer from obtaining a separate type approval and associated Certificate of Compliance from the responsible Approval Authority.

Proposal to amend UN R155 by inserting new para. 5.1.3.(e) establishing that the Certificate of Compliance for the Cyber Security Management System shall not be issued by a different Approval Authority than the one granting type approval, and amend UN R156 by inserting new para. 5.4. establishing that Approval Authorities shall not grant type approval if the Certificate of Compliance for the Software Update Management System has not been issued by the same Approval Authority granting type approval. Justification includes ensuring holistic cybersecurity assessment, clarifying reporting obligations under para. 7.2.2.2.(g), addressing unharmonized mutual recognition of management system certificates, maintaining consistency between regulations, and upholding the fundamental principle that approval authorities retain responsibility for all aspects of type approval.

This document presents an initial concept for approvals of devices as components or separate technical units according to UN R155, and the installation of such devices on vehicles already holding UN R155 approval, based on Supplement 3 to the original series. The regulation applies to vehicles of categories L₁–L₇, M₁–M₃, N₁–N₃, and O₁–O₄ with electronic control units, and to approval of components and separate technical units with regard to their cyber security. Approval authorities shall grant type approval only to vehicle or electrical/electronic sub-assembly types that satisfy the regulation’s requirements through document checks and testing. Manufacturers must demonstrate cyber security management systems covering development, production, and post-production phases, including risk assessment, mitigation implementation, monitoring, and response to cyber-attacks. Certificates of Compliance for Cyber Security Management Systems remain valid for three years.

TFCS-37-08 presents proposals to amend UN R155 to establish approval routes for electrical/electronic sub-assemblies and separate technical units. The regulation introduces three parts: Part I covers vehicle cyber security approval; Part II covers component and separate technical unit approval; Part III covers installation approval of approved components and separate technical units in vehicles. Updates include new definitions, application procedures by manufacturers or their representatives, approval conditions specifying connection limitations, and cyber security management system requirements. The proposal requests colleague review and feedback.

Proposal to amend Table A1 of Annex 5 to include high level and sub-level descriptions of vulnerability and threat including spoofing of messages, Sybil attacks, communication channels permitting code injection, manipulation, overwrite and erasure of vehicle held data and code, denial of service attacks, unauthorized access to vehicle systems, viruses in communication media, and malicious messages, and amend Table B1 of Annex 5 to provide corresponding mitigation measures. This proposal is a further elaboration of TFCS-35-07.

UN R155 addresses operator risks in automated driving systems. The ADS Regulation enables operators to offer services using automation and permits remote termination of the ADS. UN R155 mandates that supplier-related risks are managed, but operators are customers, not suppliers, creating downstream risks. An automated vehicle could be susceptible to unauthorised requests from an operator experiencing cyber attack. UN R155 does not define how downstream organisational risks are managed. Manufacturers should identify risks posed by operators and inform Third Party Operators of risks involved and expected minimum-security controls for workstations interfacing with an ADS. This could be achieved via Annex 5.

Germany proposes that the TAA granting UN R155 or UN R156 type approvals shall be obliged to only use CSMS or SUMS certificates signed by the same TAA. Issues identified include that CSMS and SUMS are Management Systems covering entire manufacturers’ organizations, mandating the same TAA will have huge consequences for OEMs using multiple TAAs, and no such obligation exists for ISO 9001 and ISO 14001. A possible way forward in the short term is to keep text unchanged to allow different TAAs for Management Systems CoC and type approval based on voluntary acceptance and implement wording on information exchange and procedure if different TAAs involved.

Questions address whether minimum vehicle architecture approval should be required before Part III can be used for additional devices; whether approved ESAs can be incorporated in original vehicle approval or as an extension to Part I approval; whether different terminology should replace CSMS for Part III approvals; whether second Part III approvals are permissible for vehicles already approved to Parts I and III; and what implications arise from end-of-support by ESA manufacturers.

Answers to questions on separate technical unit approvals under UN R155 clarify that a base vehicle must already hold an R155 type approval before an ESA can be added at Part III; approval authorities for different parts may differ with mutual recognition applying; the end of support period for an ESA manufacturer must be communicated to the vehicle manufacturer, with implications to be discussed by the IWG; installation of ESAs must follow vehicle manufacturer instructions without necessarily requiring separate agreement; STU data sharing agreements are required; and after ESA installation, a whole vehicle cyber security risk assessment is not necessary, though Part III must consider risks where ESA and base vehicle interactions occur. A working document is planned for submission to GRVA in January 2027. The IWG will explore whether Part II components may include equipment from certificated base vehicles under UN R155 multi-stage categorization and discuss incorporating STU into original approvals.

Amend para. AI to replace the heading “Examples of documents/evidence that could be provided” with “Explanation of the requirement” and insert text stating that Part C of this document provides further guidance on the application of the Regulation to vehicles which have been modified by carrying out a transformation of the vehicle.

The document presents vehicle modification use cases categorized into four cases and additional scenarios. Case 1 covers components with negligible risk or cyber-relevant non-automotive devices. Case 2 addresses cyber-relevant automotive devices approved to specific regulatory requirements, requiring installation approval and vehicle type re-approval. Case 3a addresses cyber-relevant devices not approved to specific requirements, requiring component or STU approval. Case 3b covers devices controlling vehicle functions, also requiring component or STU approval. Case 4 encompasses invasive modifications or complex interactions not covered by other cases.

Proposal to amend Paragraph B to insert new requirement 5.1.3 establishing that the Approval Authority or Technical Service shall refuse to grant type approval regarding cyber security where the vehicle manufacturer has not fulfilled requirements in paragraph 7.3., notably that the Certificate of Compliance for the Cyber Security Management System has not been issued by the same Approval Authority granting the type approval, add explanatory text clarifying that this ensures Article 2(2) of the 1958 Agreement compliance while permitting cooperation between Approval Authorities and acceptance of prior documentation, amend Paragraph K to remove existing guidance text in paragraphs 6.1 and 7.1 regarding Certificate of Compliance issuance and inter-Authority arrangements, and insert statement that no guidance is included regarding paragraph 6 requirements. These changes support proposal GRVA/2026/30.

This document presents a concept for approvals of electrical/electronic sub-assemblies (ESAs) as components according to UN R155, and the installation of such approved components on vehicles already holding UN R155 approval. The proposal removes the possibility of separate technical unit (STU) approvals as a first step, limiting coverage to components connected only to power and/or reading data through approved existing interfaces. The document restructures UN R155 into three parts: Part I covers vehicle type approvals; Part II covers ESA component approvals with cybersecurity requirements; Part III covers vehicle type approvals regarding installation of approved ESAs. Requirements include cybersecurity management systems, risk assessments, threat mitigations, and reporting provisions for development, production, and post-production phases.