See Full Document Text
Official Journal EN
of the European Union L series
2025/5 10.1.2025
Only the original UN/ECE texts have legal effect under international public law. The status and date of entry into force of this Regulation
should be checked in the latest version of the UN/ECE status document TRANS/WP.29/343, available at: https://unece.org/status-
1958-agreement-and-annexed-regulations
UN Regulation No. 155 - Uniform provisions concerning the approval of vehicles with regards to cyber security
and cyber security management system [2025/5]
Incorporating all valid text up to:
Supplement 3 to the original version of the Regulation – Date of entry into force: 10 January 2025
This document is meant purely as documentation tool. The authentic and legally binding texts are:
— ECE/TRANS/WP.29/2020/79 (as amended by ECE/TRANS/WP.29/2020/94 and ECE/TRANS/WP.29/2020/97)
— ECE/TRANS/WP.29/2022/54
— ECE/TRANS/WP.29/2023/70 and
— ECE/TRANS/WP.29/2024/55
CONTENTS
Regulation
1. Scope
2. Definitions
3. Application for approval
4. Markings
5. Approval
6. Certificate of Compliance for Cyber Security Management System
7. Specifications
8. Modification of vehicle type and extension of type approval
9. Conformity of production
10. Penalties for non-conformity of production
11. Production definitively discontinued
12. Names and addresses of Technical Services responsible for conducting approval test, and of Type Approval
Authorities
Annexes
1 Information document
2 Communication
3 Arrangement of approval mark
4 Model of Certificate of Compliance for CSMS
5 List of threats and corresponding mitigations
ELI: http://data.europa.eu/eli/reg/2025/5/oj 1/30EN
OJ L, 10.1.2025
1. Scope
1.1. 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.
1.2. This Regulation is without prejudice to other UN Regulations, regional or national legislations governing the access
by authorized parties to the vehicle, its data, functions and resources, and conditions of such access. It is also without
prejudice to the application of national and regional legislation on privacy and the protection of natural persons
with regard to the processing of their personal data.
1.3. This Regulation is without prejudice to other UN Regulations, national or regional legislation governing the
development and installation/system integration of replacement parts and components, physical and digital, with
regards to cybersecurity.
2. Definitions
For the purpose of this Regulation the following definitions shall apply:
2.1. "Vehicle type" means vehicles which do not differ in at least the following essential respects:
(a) The manufacturer’s designation of the vehicle type;
(b) Essential aspects of the electric/electronic architecture and external interfaces with respect to cyber security.
2.2. "Cyber security" means the condition in which road vehicles and their functions are protected from cyber threats to
electrical or electronic components.
2.3. "Cyber Security Management System (CSMS)" means a systematic risk-based approach defining organisational
processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them
from cyber-attacks.
2.4. "System" means a set of components and/or sub-systems that implements a function or functions.
2.5. "Development phase" means the period before a vehicle type is type approved.
2.6. "Production phase" refers to the duration of production of a vehicle type.
2.7. "Post-production phase" refers to the period in which a vehicle type is no longer produced until the end-of-life of all
vehicles under the vehicle type. Vehicles incorporating a specific vehicle type will be operational during this phase
but will no longer be produced. The phase ends when there are no longer any operational vehicles of a specific
vehicle type.
2.8. "Mitigation" means a measure that is reducing risk.
2.9. "Risk" means the potential that a given threat will exploit vulnerabilities of a vehicle and thereby cause harm to the
organization or to an individual.
2.10. "Risk Assessment" means the overall process of finding, recognizing and describing risks (risk identification), to
comprehend the nature of risk and to determine the level of risk (risk analysis), and of comparing the results of risk
analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable (risk
evaluation).
2.11. "Risk Management" means coordinated activities to direct and control an organization with regard to risk.
2/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
2.12. "Threat" means a potential cause of an unwanted incident, which may result in harm to a system, organization or
individual.
2.13. "Vulnerability" means a weakness of an asset or mitigation that can be exploited by one or more threats.
3. Application for approval
3.1. The application for approval of a vehicle type with regard to cyber security shall be submitted by the vehicle
manufacturer or by their duly accredited representative.
3.2. It shall be accompanied by the undermentioned documents in triplicate, and by the following particulars:
3.2.1. A description of the vehicle type with regard to the items specified in Annex 1 to this Regulation.
3.2.2. In cases where information is shown to be covered by intellectual property rights or to constitute specific know-how
of the manufacturer or of their suppliers, the manufacturer or their suppliers shall make available sufficient
information to enable the checks referred to in this Regulation to be made properly. Such information shall be
treated on a confidential basis.
3.2.3. The Certificate of Compliance for CSMS according to paragraph 6 of this Regulation.
3.3. Documentation shall be made available in two parts:
(a) The formal documentation package for the approval, containing the material specified in Annex 1 which shall
be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval
application. This documentation package shall be used by the Approval Authority or its Technical Service as
the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that
this documentation package remains available for at least 10 years counted from the time when production of
the vehicle type is definitively discontinued.
(b) Additional material relevant to the requirements of this regulation may be retained by the manufacturer, but
made open for inspection at the time of type approval. The manufacturer shall ensure that any material made
open for inspection at the time of type approval remains available for at least a period of 10 years counted
from the time when production of the vehicle type is definitively discontinued.
4. Marking
4.1. There shall be affixed, conspicuously and in a readily accessible place specified on the approval form, to every vehicle
conforming to a vehicle type approved under this Regulation an international approval mark consisting of:
4.1.1. A circle surrounding the Letter "E" followed by the distinguishing number of the country which has granted
approval.
4.1.2. The number of this Regulation, followed by the letter "R", a dash and the approval number to the right of the circle
described in paragraph 4.1.1. above.
4.2. If the vehicle conforms to a vehicle type approved under one or more other Regulations annexed to the Agreement
in the country which has granted approval under this Regulation, the symbol prescribed in paragraph 4.1.1. above
need not be repeated; in this case the Regulation and approval numbers and the additional symbols of all the
Regulations under which approval has been granted in the country which has granted approval under this
Regulation shall be placed in vertical columns to the right of the symbol prescribed in paragraph 4.1.1. above.
ELI: http://data.europa.eu/eli/reg/2025/5/oj 3/30EN
OJ L, 10.1.2025
4.3. The approval mark shall be clearly legible and shall be indelible.
4.4. The approval mark shall be placed on or close to the vehicle data plate affixed by the Manufacturer.
4.5. Annex 3 to this Regulation gives examples of the arrangements of the approval mark.
5. Approval
5.1. Approval Authorities shall grant, as appropriate, type approval with regard to cyber security, only to such vehicle
types that satisfy the requirements of this Regulation.
5.1.1. The Approval Authority or the Technical Service shall verify by means of document checks that the vehicle
manufacturer has taken the necessary measures relevant for the vehicle type to:
(a) Collect and verify the information required under this Regulation through the supply chain so as to demonstrate
that supplier-related risks are identified and are managed;
(b) Document risks assessment (conducted during development phase or retrospectively), test results and
mitigations applied to the vehicle type, including design information supporting the risk assessment;
(c) Implement appropriate cyber security measures in the design of the vehicle type;
(d) Detect and respond to possible cyber security attacks;
(e) Log data to support the detection of cyber-attacks and provide data forensic capability to enable analysis of
attempted or successful cyber-attacks.
5.1.2. The Approval Authority or the Technical Service shall verify by testing of a vehicle of the vehicle type that the vehicle
manufacturer has implemented the cyber security measures they have documented. Tests shall be performed by the
Approval Authority or the Technical Service itself or in collaboration with the vehicle manufacturer by sampling.
Sampling shall be focused but not limited to risks that are assessed as high during the risk assessment.
5.1.3. The Approval Authority or Technical Service shall refuse to grant the type approval with regard to cyber security
where the vehicle manufacturer has not fulfilled one or more of the requirements referred to in paragraph 7.3.,
notably:
(a) The vehicle manufacturer did not perform the exhaustive risk assessment referred to in paragraph 7.3.3.;
including where the manufacturer did not consider all the risks related to threats referred to in Annex 5, Part A;
(b) The vehicle manufacturer did not protect the vehicle type against risks identified in the vehicle manufacturer’s
risk assessment or proportionate mitigations were not implemented as required by paragraph 7.;
(c) The vehicle manufacturer did not put in place appropriate and proportionate measures to secure dedicated
environments on the vehicle type (if provided) for the storage and execution of aftermarket software, services,
applications or data;
(d) The vehicle manufacturer did not perform, prior to the approval, appropriate and sufficient testing to verify the
effectiveness of the security measures implemented.
5.1.4. The assessing Approval Authority shall also refuse to grant the type approval with regard to cyber security where the
Approval Authority or Technical Service has not received sufficient information from the vehicle manufacturer to
assess the cyber security of the vehicle type.
5.2. Notice of approval or of extension or refusal of approval of a vehicle type pursuant to this Regulation shall be
communicated to the Parties to the 1958 Agreement which apply this Regulation, by means of a form conforming
to the model in Annex 2 to this Regulation.
4/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
5.3. Approval Authorities shall not grant any type approval without verifying that the manufacturer has put in place
satisfactory arrangements and procedures to manage properly the cyber security aspects as covered by this
Regulation.
5.3.1. The Approval Authority and its Technical Services shall ensure, in addition to the criteria laid down in Schedule 2 of
the 1958 Agreement that they have:
(a) Competent personnel with appropriate cyber security skills and specific automotive risk assessments
knowledge;(1)
(b) Implemented procedures for the uniform evaluation according to this Regulation.
5.3.2. Each Contracting Party applying this Regulation shall notify and inform by its Approval Authority other Approval
Authorities of the Contracting Parties applying this UN Regulation about the method and criteria taken as a basis by
the notifying Authority to assess the appropriateness of the measures taken in accordance with this regulation and in
particular with paragraphs 5.1., 7.2. and 7.3.
This information shall be shared (a) only before granting an approval according to this Regulation for the first time
and (b) each time the method or criteria for assessment is updated.
This information is intended to be shared for the purposes of collection and analysis of the best practices and in view
of ensuring the convergent application of this Regulation by all Approval Authorities applying this Regulation.
5.3.3. The information referred to in paragraph 5.3.2 shall be uploaded in English language to the secure internet database
"DETA",(2)established by the United Nations Economic Commission for Europe, in due time and no later than 14
days before an approval is granted for the first time under the methods and criteria of assessment concerned. The
information shall be sufficient to understand what minimum performance levels the Approval Authority adopted
for each specific requirement referred to in paragraph 5.3.2 as well as the processes and measures it applies to verify
that these minimum performance levels are met.(3)
5.3.4. Approval Authorities receiving the information referred to in paragraph 5.3.2 may submit comments to the
notifying Approval Authority by uploading them to DETA within 14 days after the day of notification.
5.3.5. If it is not possible for the granting Approval Authority to take into account the comments received in accordance
with paragraph 5.3.4., the Approval Authorities having sent comments and the granting Approval Authority shall
seek further clarification in accordance with Schedule 6 to the 1958 Agreement. The relevant subsidiary Working
Party(4)of the World Forum for Harmonization of Vehicle Regulations (WP.29) for this Regulation shall agree on a
common interpretation of methods and criteria of assessment.(5) That common interpretation shall be
implemented and all Approval Authorities shall issue type approvals under this Regulation accordingly.
(1) E.g. ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434.
(2) https://www.unece.org/trans/main/wp29/datasharing.html.
(3) Guidance for the detailed information (e.g. method, criteria, performance level) to be uploaded and the format shall be given in the
interpretation document which is under preparation by the Task Force on Cyber Security and Over-the-Air issues for the seventh
session of GRVA.
(4) The Working Party on Automated/Autonomous and Connected Vehicles (GRVA)
(5) This interpretation shall be reflected in the interpretation document referred to in the footnote to paragraph 5.3.3.
ELI: http://data.europa.eu/eli/reg/2025/5/oj 5/30EN
OJ L, 10.1.2025
5.3.6. Each Approval Authority granting a type approval pursuant to this Regulation shall notify other Approval
Authorities of the approval granted. The type approval together with the supplementing documentation shall be
uploaded in English language by the Approval Authority within 14 days after the day of granting the approval to
DETA.(6)
5.3.7. The Contracting Parties may study the approvals granted based on the information uploaded according to paragraph
5.3.6. In case of any diverging views between Contracting Parties this shall be settled in accordance with Article 10
and Schedule 6 of the 1958 Agreement. The Contracting Parties shall also inform the relevant subsidiary Working
Party of the World Forum for Harmonization of Vehicle Regulations (WP.29) of the diverging interpretations within
the meaning of Schedule 6 to the 1958 Agreement. The relevant Working Party shall support the settlement of the
diverging views and may consult with WP.29 on this if needed
5.4. For the purpose of paragraph 7.2. of this Regulation, the manufacturer shall ensure that the cyber security aspects
covered by this Regulation are implemented.
6. Certificate of Compliance for Cyber Security Management System
6.1. Contracting Parties shall appoint an Approval Authority to carry out the assessment of the manufacturer and to
issue a Certificate of Compliance for CSMS.
6.2. An application for a Certificate of Compliance for Cyber Security Management System shall be submitted by the
vehicle manufacturer or by their duly accredited representative.
6.3. It shall be accompanied by the undermentioned documents in triplicate, and by the following particular:
6.3.1. Documents describing the Cyber Security Management System.
6.3.2. A signed declaration using the model as defined in Appendix 1 to Annex 1.
6.4. In the context of the assessment, the manufacturer shall declare using the model as defined in Appendix 1 to Annex
1 and demonstrate to the satisfaction of the Approval Authority or its Technical Service that they have the necessary
processes to comply with all the requirements for cyber security according to this Regulation.
6.5. When this assessment has been satisfactorily completed and in receipt of a signed declaration from the manufacturer
according to the model as defined in Appendix 1 to Annex 1, a certificate named Certificate of Compliance for CSMS
as described in Annex 4 to this Regulation (hereinafter the Certificate of Compliance for CSMS) shall be granted to
the manufacturer.
6.6. The Approval Authority or its Technical Service shall use the model set out in Annex 4 to this Regulation for the
Certificate of Compliance for CSMS.
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.
6.8. The Approval Authority which has granted the Certificate of Compliance for CSMS may at any time verify that the
requirements for it continue to be met. The Approval Authority shall withdraw the Certificate of Compliance for
CSMS if the requirements laid down in this Regulation are no longer met.
(6) Further information on the minimum requirements for the documentation package will be developed by GRVA during its seven
session.
6/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
6.9. The manufacturer shall inform the Approval Authority or its Technical Service of any change that will affect the
relevance of the Certificate of Compliance for CSMS. After consultation with the manufacturer, the Approval
Authority or its Technical Service shall decide whether new checks are necessary.
6.10. In due time, permitting the Approval Authority to complete its assessment before the end of the period of validity
of the Certificate of Compliance for CSMS, the manufacturer shall apply for a new or for the extension of the
existing Certificate of Compliance for CSMS. The Approval Authority shall, subject to a positive assessment, issue
a new Certificate of Compliance for CSMS or extend its validity for a further period of three years. The Approval
Authority shall verify that the CSMS continue to comply with the requirements of this Regulation. The Approval
Authority shall issue a new certificate in cases where changes have been brought to the attention of the Approval
Authority or its Technical Service and the changes have been positively re-assessed.
6.11. The expiry or withdrawal of the manufacturer’s Certificate of Compliance for CSMS shall be considered, with
regard to the vehicle types to which the CSMS concerned was relevant, as modification of approval, as referred to
in paragraph 8, which may include the withdrawal of the approval if the conditions for granting the approval are
not met anymore.
7. Specifications
7.1. General specifications
7.1.1. The requirements of this Regulation shall not restrict provisions or requirements of other UN Regulations.
7.2. Requirements for the Cyber Security Management System
7.2.1. For the assessment the Approval Authority or its Technical Service shall verify that the vehicle manufacturer has a
Cyber Security Management System in place and shall verify its compliance with this Regulation.
7.2.2. The Cyber Security Management System shall cover the following aspects:
7.2.2.1. The vehicle manufacturer shall demonstrate to an Approval Authority or Technical Service that their Cyber
Security Management System applies to the following phases:
(a) Development phase;
(b) Production phase;
(c) Post-production phase.
7.2.2.2. The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management
System ensure security is adequately considered, including risks and mitigations listed in Annex 5. This shall
include:
(a) The processes used within the manufacturer’s organization to manage cyber security;
(b) The processes used for the identification of risks to vehicle types. Within these processes, the threats in Annex
5, Part A, and other relevant threats shall be considered;
(c) The processes used for the assessment, categorization and treatment of the risks identified;
(d) The processes in place to verify that the risks identified are appropriately managed;
(e) The processes used for testing the cyber security of a vehicle type;
(f) The processes used for ensuring that the risk assessment is kept current;
ELI: http://data.europa.eu/eli/reg/2025/5/oj 7/30EN
OJ L, 10.1.2025
(g) The processes used to monitor for, detect and respond to cyber-attacks, cyber threats and vulnerabilities on
vehicle types and the processes used to assess whether the cyber security measures implemented are still
effective in the light of new cyber threats and vulnerabilities that have been identified.
(h) The processes used to provide relevant data to support analysis of attempted or successful cyber-attacks.
7.2.2.3. The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management
System will ensure that, based on categorization referred to in paragraph 7.2.2.2 (c) and 7.2.2.2 (g), cyber threats
and vulnerabilities which require a response from the vehicle manufacturer shall be mitigated within a reasonable
timeframe.
7.2.2.4. The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management
System will ensure that the monitoring referred to in paragraph 7.2.2.2 (g) shall be continual. This shall:
(a) Include vehicles after first registration in the monitoring;
(b) Include the capability to analyse and detect cyber threats, vulnerabilities and cyber-attacks from vehicle data
and vehicle logs. This capability shall respect paragraph 1.3. and the privacy rights of car owners or drivers,
particularly with respect to consent.
7.2.2.5. The vehicle manufacturer shall be required to demonstrate how their Cyber Security Management System will
manage dependencies that may exist with contracted suppliers, service providers or manufacturer’s sub-
organizations in regards of the requirements of paragraph 7.2.2.2.
7.3. Requirements for vehicle types
7.3.1. The manufacturer shall have a valid Certificate of Compliance for the Cyber Security Management System relevant
to the vehicle type being approved. However, for type approvals of vehicles of Categories M, N and O first issued
before 1 July 2024, and for type approvals of vehicles of Category L first issued before 1 July 2029, and for each
extension thereof, if the vehicle manufacturer can demonstrate that the vehicle type could not be developed in
compliance with the CSMS, then the vehicle manufacturer shall demonstrate that cyber security was adequately
considered during the development phase of the vehicle type concerned..
7.3.2. The vehicle manufacturer shall identify and manage, for the vehicle type being approved, supplier-related risks.
7.3.3. The vehicle manufacturer shall identify the critical elements of the vehicle type and perform an exhaustive risk
assessment for the vehicle type and shall treat/manage the identified risks appropriately. The risk assessment shall
consider the individual elements of the vehicle type and their interactions. The risk assessment shall further
consider interactions with any external systems. While assessing the risks, the vehicle manufacturer shall consider
the risks related to all the threats referred to in Annex 5, Part A, as well as any other relevant risk.
7.3.4. The vehicle manufacturer shall protect the vehicle type against risks identified in the vehicle manufacturer’s risk
assessment. Proportionate mitigations shall be implemented to protect the vehicle type. The mitigations
implemented shall include all mitigations referred to in Annex 5, Part B and C which are relevant for the risks
identified. However, if a mitigation referred to in Annex 5, Part B or C, is not relevant or not sufficient for the risk
identified, the vehicle manufacturer shall ensure that another appropriate mitigation is implemented.
8/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
In particular, for type approvals of vehicles of Categories M, N and O first issued before 1 July 2024, and for type
approvals of vehicles of Category L first issued before 1 July 2029, and for each extension thereof, the vehicle
manufacturer shall ensure that another appropriate mitigation is implemented if a mitigation measure referred to
in Annex 5, Part B or C is technically not feasible. The respective assessment of the technical feasibility shall be
provided by the manufacturer to the approval authority.
7.3.5. The vehicle manufacturer shall put in place appropriate and proportionate measures to secure dedicated
environments on the vehicle type (if provided) for the storage and execution of aftermarket software, services,
applications or data.
7.3.6. The vehicle manufacturer shall perform, prior to type approval, appropriate and sufficient testing to verify the
effectiveness of the security measures implemented.
7.3.7. The vehicle manufacturer shall implement measures for the vehicle type to:
(a) Detect and prevent cyber-attacks against vehicles of the vehicle type;
(b) Support the monitoring capability of the vehicle manufacturer with regards to detecting threats,
vulnerabilities and cyber-attacks relevant to the vehicle type;
(c) Provide data forensic capability to enable analysis of attempted or successful cyber-attacks.
7.3.8. 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.
7.4. Reporting provisions
7.4.1. The vehicle manufacturer shall report at least once a year, or more frequently if relevant, to the Approval
Authority or the Technical Service the outcome of their monitoring activities, as defined in paragraph 7.2.2.2.(g)),
this shall include relevant information on new cyber-attacks. The vehicle manufacturer shall also report and
confirm to the Approval Authority or the Technical Service that the cyber security mitigations implemented for
their vehicle types are still effective and any additional actions taken.
7.4.2. The Approval Authority or the Technical Service shall verify the provided information and, if necessary, require
the vehicle manufacturer to remedy any detected ineffectiveness.
If the reporting or response is not sufficient the Approval Authority may decide to withdraw the CSMS in
compliance with paragraph 6.8.
8. Modification of vehicle type and extension of type approval
8.1. Every modification of the vehicle type which affects its technical performance with respect to cybersecurity and/or
documentation required in this Regulation shall be notified to the approval authority which approved the vehicle
type. The Approval Authority may then either:
8.1.1. Consider that the modifications made still comply with the requirements and documentation of existing type
approval; or
8.1.2. Proceed to necessary complementary assessment pursuant to paragraph 5, and require, where relevant, a further
test report from the Technical Service responsible for conducting the tests.
ELI: http://data.europa.eu/eli/reg/2025/5/oj 9/30EN
OJ L, 10.1.2025
8.1.3. Confirmation or extension or refusal of approval, specifying the alterations, shall be communicated by means of a
communication form conforming to the model in Annex 2 to this Regulation. The Approval Authority issuing the
extension of approval shall assign a series number for such an extension and inform there of the other Parties to
the 1958 Agreement applying this Regulation by means of a communication form conforming to the model in
Annex 2 to this Regulation.
9. Conformity of production
9.1. The Conformity of Production Procedures shall comply with those set out in the 1958 Agreement, Schedule 1 (E/
ECE/TRANS/505/Rev.3) with the following requirements:
9.1.1. The holder of the approval shall ensure that results of the conformity of production tests are recorded and that the
annexed documents remain available for a period determined in agreement with the Approval Authority or its
Technical Service. This period shall not exceed 10 years counted from the time when production is definitively
discontinued;
9.1.2. The Approval Authority which has granted type approval may at any time verify the conformity control methods
applied in each production facility. The normal frequency of these verifications shall be once every three years.
10. Penalties for non-conformity of production
10.1. The approval granted in respect of a vehicle type pursuant to this Regulation may be withdrawn if the
requirements laid down in this Regulation are not complied with or if sample vehicles fail to comply with the
requirements of this Regulation.
10.2. If an Approval Authority withdraws an approval it has previously granted, it shall forthwith so notify the
Contracting Parties applying this Regulation, by means of a communication form conforming to the model in
Annex 2 to this Regulation.
11. Production definitively discontinued
11.1. If the holder of the approval completely ceases to manufacture a type of vehicle approved in accordance with this
Regulation, he shall so inform the authority which granted the approval. Upon receiving the relevant
communication that authority shall inform thereof the other Contracting Parties to the Agreement applying this
Regulation by means of a copy of the approval form bearing at the end, in large letters, the signed and dated
annotation "PRODUCTION DISCONTINUED".
12. Names and addresses of Technical Services responsible for conducting approval test, and of Type Approval
Authorities
12.1. The Contracting Parties to the Agreement which apply this Regulation shall communicate to the United Nations
Secretariat the names and addresses of the Technical Services responsible for conducting approval tests and of the
Type Approval Authorities which grant approval and to which forms certifying approval or extension or refusal or
withdrawal of approval, issued in other countries, are to be sent.
10/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
ANNEX 1
Information document
The following information, if applicable, shall be supplied in triplicate and include a list of contents. Any drawings shall be
supplied in appropriate scale and in sufficient detail on size A4 or on a folder of A4 format. Photographs, if any, shall show
sufficient detail.
1. Make (trade name of manufacturer): ...................................................................................
2. Type and general commercial description(s): ...........................................................................
3. Means of identification of type, if marked on the vehicle: ..............................................................
4. Location of that marking: ..............................................................................................
5. Category(ies) of vehicle: ................................................................................................
6. Name and address of manufacturer/ manufacturer's representative: ...................................................
7. Name(s) and Address(es) of assembly plant(s): .........................................................................
8. Photograph(s) and/or drawing(s) of a representative vehicle: ...........................................................
9. Cyber Security
9.1. General construction characteristics of the vehicle type, including:
(a) The vehicle systems which are relevant to the cyber security of the vehicle type;
(b) The components of those systems that are relevant to cyber security;
(c) The interactions of those systems with other systems within the vehicle type and external interfaces.
9.2. Schematic representation of the vehicle type
9.3. The number of the Certificate of Compliance for CSMS: ...............................................................
9.4. Documents for the vehicle type to be approved describing the outcome of its risk assessment and the identified
risks: ...................................................................................................................
9.5. Documents for the vehicle type to be approved describing the mitigations that have been implemented on the
systems listed, or to the vehicle type, and how they address the stated risks: ..........................................
9.6. Documents for the vehicle type to be approved describing protection of dedicated environments for aftermarket
software, services, applications or data: ................................................................................
9.7. Documents for the vehicle type to be approved describing what tests have been used to verify the cyber security of
the vehicle type and its systems and the outcome of those tests: .......................................................
9.8. Description of the consideration of the supply chain with respect to cyber security: ..................................
ELI: http://data.europa.eu/eli/reg/2025/5/oj 11/30EN
OJ L, 10.1.2025
Annex 1 - Appendix 1
Model of Manufacturer’s Declaration of Compliance for CSMS
Manufacturer’s declaration of compliance with the requirements for the Cyber Security Management System
Manufacturer Name: ..........................................................................................................
Manufacturer Address: ........................................................................................................
......................................................................................................... (Manufacturer Name)
attests that the necessary processes to comply with the requirements for the Cyber Security Management System laid down
in paragraph 7.2 of UN Regulation 155 are installed and will be maintained.
Done at: ................................................................................................................(place)
Date: ..........................................................................................................................
Name of the signatory: ........................................................................................................
Function of the signatory: .....................................................................................................
(Stamp and signature of the manufacturer’s representative)
12/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
ANNEX 2
Communication
(Maximum format: A4 (210 × 297 mm))
issued by: Name of administration:
..................................
..................................
..................................
()
Concerning:(2) Approval granted
Approval extended
Approval withdrawn with effect from dd/mm/yyyy
Approval refused
Production definitively discontinued
of a vehicle type, pursuant to UN Regulation No. 155
Approval No.: .................................................................................................................
Extension No.: .................................................................................................................
Reason for extension: .........................................................................................................
1. Make (trade name of manufacturer): ...................................................................................
2. Type and general commercial description(s) ...........................................................................
3. Means of identification of type, if marked on the vehicle: ..............................................................
3.1. Location of that marking: ..............................................................................................
4. Category(ies) of vehicle: ................................................................................................
5. Name and address of manufacturer / manufacturer’s representative: ..................................................
6. Name(s) and Address(es) of the production plant(s) ....................................................................
7. Number of the certificate of compliance for cyber security management system: .....................................
8. Technical Service responsible for carrying out the tests: ...............................................................
9. Date of test report: .....................................................................................................
10. Number of test report: .................................................................................................
11. Remarks: (if any). ......................................................................................................
12. Place: ...................................................................................................................
(1) Distinguishing number of the country which has granted/extended/refused/withdrawn approval (see approval provisions in the
Regulation).
(2) Strike out what does not apply.
ELI: http://data.europa.eu/eli/reg/2025/5/oj 13/30EN
OJ L, 10.1.2025
13. Date: ...................................................................................................................
14. Signature: ..............................................................................................................
15. The index to the information package lodged with the Approval Authority, which may be obtained on request is
attached:
14/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
ANNEX 3
Arrangement of approval mark
MODEL A
(See paragraph 4.2 of this Regulation)
a = 8 mm min.
The above approval mark affixed to a vehicle shows that the road vehicle type concerned has been approved in the
Netherlands (E 4), pursuant to Regulation No.155, and under the approval number 001234. The first two digits of the
approval number indicate that the approval was granted in accordance with the requirements of this Regulation in its
original form (00).
ELI: http://data.europa.eu/eli/reg/2025/5/oj 15/30EN
OJ L, 10.1.2025
ANNEX 4
MODEL OF CERTIFICATE OF COMPLIANCE FOR CSMS
Certificate of compliance for cyber security management system
With UN Regulation No. 155
Certificate Number [Reference number]
[……Approval Authority]
Certifies that
Manufacturer: .................................................................................................................
Address of the manufacturer: .................................................................................................
complies with the provisions of paragraph 7.2 of Regulation No. 155
Checks have been performed on: ..............................................................................................
by (name and address of the Approval Authority or Technical Service): ....................................................
Number of report: ...........................................
The certificate is valid until [.......................... Date]
Done at [.............................................. Place]
On [................................................... Date]
[................................................... Signature]
Attachments: description of the Cyber Security Management System by the manufacturer.
16/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
ANNEX 5
List of threats and corresponding mitigations
1. This annex consists of three parts. Part A of this annex describes the baseline for threats, vulnerabilities and attack
methods. Part B of this annex describes mitigations to the threats which are intended for vehicle types. Part C
describes mitigations to the threats which are intended for areas outside of vehicles, e.g. on IT backends.
2. Part A, Part B, and Part C shall be considered for risk assessment and mitigations to be implemented by vehicle
manufacturers.
3. The high-level vulnerability and its corresponding examples have been indexed in Part A. The same indexing has
been referenced in the tables in Parts B and C to link each of the attack/vulnerability with a list of corresponding
mitigation measures.
4. The threat analysis shall also consider possible attack impacts. These may help ascertain the severity of a risk and
identify additional risks. Possible attack impacts may include:
(a) Safe operation of vehicle affected;
(b) Vehicle functions stop working;
(c) Software modified, performance altered;
(d) Software altered but no operational effects;
(e) Data integrity breach;
(f) Data confidentiality breach;
(g) Loss of data availability;
(h) Other, including criminality.
PART A
Vulnerability or attack method related to the threats
High level descriptions of threats and relating vulnerability or attack method are listed in Table A1.
Table A1
List of vulnerability or attack method related to the threats
High level and sub-level descriptions of vulnerability/ threat Example of vulnerability or attack method
4.3.1. Threats 1 Back-end servers used as a 1.1 Abuse of privileges by staff (insider attack)
regarding means to attack a vehicle or
1.2 Unauthorized internet access to the server (enabled
back-end extract data
for example by backdoors, unpatched system
servers
software vulnerabilities, SQL attacks or other means)
related to
vehicles in the
1.3 Unauthorized physical access to the server
field
(conducted by for example USB sticks or other media
connecting to the server)
2 Services from back-end server 2.1 Attack on back-end server stops it functioning, for
being disrupted, affecting the example it prevents it from interacting with vehicles
operation of a vehicle and providing services they rely on
ELI: http://data.europa.eu/eli/reg/2025/5/oj 17/30EN
OJ L, 10.1.2025
High level and sub-level descriptions of vulnerability/ threat Example of vulnerability or attack method
3 Vehicle related data held on 3.1 Abuse of privileges by staff (insider attack)
back-end servers being lost or
compromised ("data breach")
3.2 Loss of information in the cloud. Sensitive data may
be lost due to attacks or accidents when data is stored
by third-party cloud service providers
3.3 Unauthorized internet access to the server (enabled
for example by backdoors, unpatched system
software vulnerabilities, SQL attacks or other means)
3.4 Unauthorized physical access to the server
(conducted for example by USB sticks or other media
connecting to the server)
3.5 Information breach by unintended sharing of data
(e.g. admin errors)
4.3.2 Threats to 4 Spoofing of messages or data 4.1 Spoofing of messages by impersonation (e.g. V2X
vehicles received by the vehicle cooperative awareness or manoeuvre coordination
regarding messages, GNSS messages, etc.)
their
communica-
4.2 Sybil attack (in order to spoof other vehicles as if
tion channels
there are many vehicles on the road)
5 Communication channels 5.1 Communications channels permit code injection, for
used to conduct unauthorized example tampered software binary might be injected
manipulation, deletion or into the communication stream
other amendments to vehicle
held code/data
5.2 Communications channels permit manipulate of
vehicle held data/code
5.3 Communications channels permit overwrite of
vehicle held data/code
5.4 Communications channels permit erasure of vehicle
held data/code
5.5 Communications channels permit introduction of
data/code to the vehicle (write data code)
6 Communication channels 6.1 Accepting information from an unreliable or
permit untrusted/unreliable untrusted source
messages to be accepted or are
vulnerable to session
6.2 Man in the middle attack/ session hijacking
hijacking/replay attacks
6.3 Replay attack, for example an attack against a
communication gateway allows the attacker to
downgrade software of an ECU or firmware of the
gateway
7 Information can be readily 7.1 Interception of information / interfering radiations /
disclosed. For example, monitoring communications
through eavesdropping on
communications or through
7.2 Gaining unauthorized access to files or data
allowing unauthorized access
to sensitive files or folders
18/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
High level and sub-level descriptions of vulnerability/ threat Example of vulnerability or attack method
8 Denial of service attacks via 8.1 Sending a large number of garbage data to vehicle
communication channels to information system, so that it is unable to provide
disrupt vehicle functions services in the normal manner
8.2 Black hole attack, in order to disrupt communication
between vehicles the attacker is able to block
messages between the vehicles
9 An unprivileged user is able to 9.1 An unprivileged user is able to gain privileged access,
gain privileged access to for example root access
vehicle systems
10 Viruses embedded in 10.1 Virus embedded in communication media infects
communication media are vehicle systems
able to infect vehicle systems
11 Messages received by the 11.1 Malicious internal (e.g. CAN) messages
vehicle (for example X2V or
diagnostic messages), or
11.2 Malicious V2X messages, e.g. infrastructure to
transmitted within it, contain
vehicle or vehicle-vehicle messages (e.g. CAM,
malicious content
DENM)
11.3 Malicious diagnostic messages
11.4 Malicious proprietary messages (e.g. those normally
sent from OEM or component/system/function
supplier)
4.3.3. Threats to 12 Misuse or compromise of 12.1 Compromise of over the air software update
vehicles update procedures procedures. This includes fabricating the system
regarding update program or firmware
their update
procedures
12.2 Compromise of local/physical software update
procedures. This includes fabricating the system
update program or firmware
12.3 The software is manipulated before the update
process (and is therefore corrupted), although the
update process is intact
12.4 Compromise of cryptographic keys of the software
provider to allow invalid update
13 It is possible to deny legitimate 13.1 Denial of Service attack against update server or
updates network to prevent rollout of critical software
updates and/or unlock of customer specific features
4.3.4. Threats to 15 Legitimate actors are able to 15.1 Innocent victim (e.g. owner, operator or
vehicles take actions that would maintenance engineer) being tricked into taking an
regarding unwittingly facilitate a cyber- action to unintentionally load malware or enable an
unintended attack attack
human
actions
15.2 Defined security procedures are not followed
facilitating a
cyber attack
ELI: http://data.europa.eu/eli/reg/2025/5/oj 19/30EN
OJ L, 10.1.2025
High level and sub-level descriptions of vulnerability/ threat Example of vulnerability or attack method
4.3.5. Threats to 16 Manipulation of the 16.1 Manipulation of functions designed to remotely
vehicles connectivity of vehicle operate systems, such as remote key, immobilizer,
regarding functions enables a cyber- and charging pile
their external attack, this can include
connectivity telematics; systems that
16.2 Manipulation of vehicle telematics (e.g. manipulate
and permit remote operations;
temperature measurement of sensitive goods,
connections and systems using short range
remotely unlock cargo doors)
wireless communications
16.3 Interference with short range wireless systems or
sensors
17 Hosted 3rd party software, 17.1 Corrupted applications, or those with poor software
e.g. entertainment security, used as a method to attack vehicle systems
applications, used as a means
to attack vehicle systems
18 Devices connected to external 18.1 External interfaces such as USB or other ports used as
interfaces e.g. USB ports, OBD a point of attack, for example through code injection
port, used as a means to attack
vehicle systems
18.2 Media infected with a virus connected to a vehicle
system
18.3 Diagnostic access (e.g. dongles in OBD port) used to
facilitate an attack, e.g. manipulate vehicle
parameters (directly or indirectly)
4.3.6. Threats to 19 Extraction of vehicle data/ 19.1 Extraction of copyright or proprietary software from
vehicle data/ code vehicle systems (product piracy)
code
19.2 Unauthorized access to the owner’s privacy
information such as personal identity, payment
account information, address book information,
location information, vehicle’s electronic ID, etc.
19.3 Extraction of cryptographic keys
20 Manipulation of vehicle data/ 20.1 Illegal/unauthorized changes to vehicle’s electronic
code ID
20.2 Identity fraud. For example, if a user wants to display
another identity when communicating with toll
systems, manufacturer backend
20.3 Action to circumvent monitoring systems (e.g.
hacking/ tampering/ blocking of messages such as
ODR Tracker data, or number of runs)
20.4 Data manipulation to falsify vehicle’s driving data
(e.g. mileage, driving speed, driving directions, etc.)
20.5 Unauthorized changes to system diagnostic data
21 Erasure of data/code 21.1 Unauthorized deletion/manipulation of system
event logs
22 Introduction of malware 22.2 Introduce malicious software or malicious software
activity
20/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
High level and sub-level descriptions of vulnerability/ threat Example of vulnerability or attack method
23 Introduction of new software 23.1 Fabrication of software of the vehicle control system
or overwrite existing software or information system
24 Disruption of systems or 24.1 Denial of service, for example this may be triggered
operations on the internal network by flooding a CAN bus, or by
provoking faults on an ECU via a high rate of
messaging
25 Manipulation of vehicle 25.1 Unauthorized access of falsify the configuration
parameters parameters of vehicle’s key functions, such as brake
data, airbag deployed threshold, etc.
25.2 Unauthorized access of falsify the charging
parameters, such as charging voltage, charging
power, battery temperature, etc.
4.3.7. Potential 26 Cryptographic technologies 26.1 Combination of short encryption keys and long
vulnerabil- can be compromised or are period of validity enables attacker to break
ities that insufficiently applied encryption
could be
exploited if
26.2 Insufficient use of cryptographic algorithms to
not
protect sensitive systems
sufficiently
protected or
hardened 26.3 Using already or soon to be deprecated
cryptographic algorithms
27 Parts or supplies could be 27.1 Hardware or software, engineered to enable an attack
compromised to permit or fails to meet design criteria to stop an attack
vehicles to be attacked
28 Software or hardware 28.1 Software bugs. The presence of software bugs can be
development permits a basis for potential exploitable vulnerabilities. This
vulnerabilities is particularly true if software has not been tested to
verify that known bad code/bugs is not present and
reduce the risk of unknown bad code/bugs being
present
28.2 Using remainders from development (e.g. debug
ports, JTAG ports, microprocessors, development
certificates, developer passwords, …) can permit
access to ECUs or permit attackers to gain higher
privileges
29 Network design introduces 29.1 Superfluous internet ports left open, providing
vulnerabilities access to network systems
29.2 Circumvent network separation to gain control.
Specific example is the use of unprotected gateways,
or access points (such as truck-trailer gateways), to
circumvent protections and gain access to other
network segments to perform malicious acts, such as
sending arbitrary CAN bus messages
31 Unintended transfer of data 31.1 Information breach. Personal data may be leaked
can occur when the car changes user (e.g. is sold or is used as
hire vehicle with new hirers)
ELI: http://data.europa.eu/eli/reg/2025/5/oj 21/30EN
OJ L, 10.1.2025
High level and sub-level descriptions of vulnerability/ threat Example of vulnerability or attack method
32 Physical manipulation of 32.1 Manipulation of electronic hardware, e.g.
systems can enable an attack unauthorized electronic hardware added to a vehicle
to enable "man-in-the-middle" attack
Replacement of authorized electronic hardware (e.g.,
sensors) with unauthorized electronic hardware
Manipulation of the information collected by a
sensor (for example, using a magnet to tamper with
the Hall effect sensor connected to the gearbox)
PART B
Mitigations to the threats intended for vehicles
1. Mitigations for "Vehicle communication channels"
Mitigations to the threats which are related to "Vehicle communication channels" are listed in Table B1.
Table B1
Mitigation to the threats which are related to "Vehicle communication channels"
Table A1
Threats to "Vehicle communication channels" Ref Mitigation
reference
4.1 Spoofing of messages (e.g. V2X M10 The vehicle shall verify the authenticity and
cooperative awareness or manoeuvre integrity of messages it receives
coordination messages, GNSS messages,
etc.) by impersonation
4.2 Sybil attack (in order to spoof other M11 Security controls shall be implemented for storing
vehicles as if there are many vehicles on cryptographic keys (e.g., use of Hardware Security
the road) Modules)
5.1 Communication channels permit code M10 The vehicle shall verify the authenticity and
injection into vehicle held data/code, for M6 integrity of messages it receives
example tampered software binary Systems shall implement security by design to
might be injected into the minimize risks
communication stream
5.2 Communication channels permit M7 Access control techniques and designs shall be
manipulation of vehicle held data/code applied to protect system data/code
5.3 Communication channels permit
overwrite of vehicle held data/code
5.4 Communication channels permit
21.1 erasure of vehicle held data/code
5.5 Communication channels permit
introduction of data/code to vehicle
systems (write data code)
22/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
Table A1
Threats to "Vehicle communication channels" Ref Mitigation
reference
6.1 Accepting information from an M10 The vehicle shall verify the authenticity and
unreliable or untrusted source integrity of messages it receives
6.2 Man in the middle attack / session M10 The vehicle shall verify the authenticity and
hijacking integrity of messages it receives
6.3 Replay attack, for example an attack
against a communication gateway allows
the attacker to downgrade software of an
ECU or firmware of the gateway
7.1 Interception of information / interfering M12 Confidential data transmitted to or from the
radiations / monitoring vehicle shall be protected
communications
7.2 Gaining unauthorized access to files or M8 Through system design and access control it
data should not be possible for unauthorized personnel
to access personal or system critical data. Example
of Security Controls can be found in OWASP
8.1 Sending a large number of garbage data M13 Measures to detect and recover from a denial of
to vehicle information system, so that it service attack shall be employed
is unable to provide services in the
normal manner
8.2 Black hole attack, disruption of M13 Measures to detect and recover from a denial of
communication between vehicles by service attack shall be employed
blocking the transfer of messages to
other vehicles
9.1 An unprivileged user is able to gain M9 Measures to prevent and detect unauthorized
privileged access, for example root access access shall be employed
10.1 Virus embedded in communication M14 Measures to protect systems against embedded
media infects vehicle systems viruses/malware should be considered
11.1 Malicious internal (e.g. CAN) messages M15 Measures to detect malicious internal messages or
activity should be considered
11.2 Malicious V2X messages, e.g. M10 The vehicle shall verify the authenticity and
infrastructure to vehicle or vehicle- integrity of messages it receives
vehicle messages (e.g. CAM, DENM)
11.3 Malicious diagnostic messages
11.4 Malicious proprietary messages (e.g.
those normally sent from OEM or
component/system/function supplier)
ELI: http://data.europa.eu/eli/reg/2025/5/oj 23/30EN
OJ L, 10.1.2025
2. Mitigations for "Update process"
Mitigations to the threats which are related to "Update process" are listed in Table B2.
Table B2
Mitigations to the threats which are related to "Update process"
Table A1
Threats to "Update process" Ref Mitigation
reference
12.1 Compromise of over the air software M16 Secure software update procedures shall be
update procedures. This includes employed
fabricating the system update program or
firmware
12.2 Compromise of local/physical software
update procedures. This includes
fabricating the system update program or
firmware
12.3 The software is manipulated before the
update process (and is therefore corrupted),
although the update process is intact
12.4 Compromise of cryptographic keys of the M11 Security controls shall be implemented for
software provider to allow invalid update storing cryptographic keys
13.1 Denial of Service attack against update M3 Security Controls shall be applied to back-end
server or network to prevent rollout of systems. Where back-end servers are critical to
critical software updates and/or unlock of the provision of services there are recovery
customer specific features measures in case of system outage. Example
Security Controls can be found in OWASP
3. Mitigations for "Unintended human actions facilitating a cyber attack"
Mitigations to the threats which are related to "Unintended human actions facilitating a cyber attack" are listed in
Table B3.
Table B3
Mitigations to the threats which are related to "Unintended human actions facilitating a cyber attack"
Table A1
Threats relating to "Unintended human actions" Ref Mitigation
reference
15.1 Innocent victim (e.g. owner, operator or M18 Measures shall be implemented for defining and
maintenance engineer) is tricked into controlling user roles and access privileges,
taking an action to unintentionally load based on the principle of least access privilege
malware or enable an attack
24/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
Table A1
Threats relating to "Unintended human actions" Ref Mitigation
reference
15.2 Defined security procedures are not M19 Organizations shall ensure security procedures
followed are defined and followed including logging of
actions and access related to the management of
the security functions
4. Mitigations for "External connectivity and connections"
Mitigations to the threats which are related to "external connectivity and connections" are listed in Table B4.
Table B4
Mitigation to the threats which are related to "external connectivity and connections"
Table A1 Threats to "External connectivity and
Ref Mitigation
reference connections"
16.1 Manipulation of functions designed to M20 Security controls shall be applied to systems that
remotely operate vehicle systems, such as have remote access
remote key, immobiliser, and charging pile
16.2 Manipulation of vehicle telematics (e.g.
manipulate temperature measurement of
sensitive goods, remotely unlock cargo
doors)
16.3 Interference with short range wireless
systems or sensors
17.1 Corrupted applications, or those with poor M21 Software shall be security assessed,
software security, used as a method to authenticated and integrity protected.
attack vehicle systems Security controls shall be applied to minimise
the risk from third party software that is
intended or foreseeable to be hosted on the
vehicle
18.1 External interfaces such as USB or other M22 Security controls shall be applied to external
ports used as a point of attack, for example interfaces
through code injection
18.2 Media infected with viruses connected to
the vehicle
18.3 Diagnostic access (e.g. dongles in OBD M22 Security controls shall be applied to external
port) used to facilitate an attack, e.g. interfaces
manipulate vehicle parameters (directly or
indirectly)
ELI: http://data.europa.eu/eli/reg/2025/5/oj 25/30EN
OJ L, 10.1.2025
5. Mitigations for "Potential targets of, or motivations for, an attack"
Mitigations to the threats which are related to "Potential targets of, or motivations for, an attack" are listed in
Table B5.
Table B5
Mitigations to the threats which are related to "Potential targets of, or motivations for, an attack"
Table A1 Threats to "Potential targets of, or motivations
Ref Mitigation
reference for, an attack"
19.1 Extraction of copyright or proprietary M7 Access control techniques and designs shall be
software from vehicle systems (product applied to protect system data/code. Example
piracy / stolen software) Security Controls can be found in OWASP
19.2 Unauthorized access to the owner’s privacy M8 Through system design and access control it
information such as personal identity, should not be possible for unauthorized
payment account information, address personnel to access personal or system critical
book information, location information, data. Examples of Security Controls can be
vehicle’s electronic ID, etc. found in OWASP
19.3 Extraction of cryptographic keys M11 Security controls shall be implemented for
storing cryptographic keys e.g. Security Modules
20.1 Illegal/unauthorised changes to vehicle’s M7 Access control techniques and designs shall be
electronic ID applied to protect system data/code. Example
Security Controls can be found in OWASP
20.2 Identity fraud. For example, if a user wants
to display another identity when
communicating with toll systems,
manufacturer backend
20.3 Action to circumvent monitoring systems M7 Access control techniques and designs shall be
(e.g. hacking/ tampering/ blocking of applied to protect system data/code. Example
messages such as ODR Tracker data, or Security Controls can be found in OWASP.
number of runs) Data manipulation attacks on sensors or
transmitted data could be mitigated by
correlating the data from different sources of
20.4 Data manipulation to falsify vehicle’s
information
driving data (e.g. mileage, driving speed,
driving directions, etc.)
20.5 Unauthorised changes to system diagnostic
data
21.1 Unauthorized deletion/manipulation of M7 Access control techniques and designs shall be
system event logs applied to protect system data/code. Example
Security Controls can be found in OWASP.
22.2 Introduce malicious software or malicious M7 Access control techniques and designs shall be
software activity applied to protect system data/code. Example
Security Controls can be found in OWASP.
23.1 Fabrication of software of the vehicle
control system or information system
26/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
Table A1 Threats to "Potential targets of, or motivations
Ref Mitigation
reference for, an attack"
24.1 Denial of service, for example this may be M13 Measures to detect and recover from a denial of
triggered on the internal network by service attack shall be employed
flooding a CAN bus, or by provoking faults
on an ECU via a high rate of messaging
25.1 Unauthorized access to falsify M7 Access control techniques and designs shall be
configuration parameters of vehicle’s key applied to protect system data/code. Example
functions, such as brake data, airbag Security Controls can be found in OWASP
deployed threshold, etc.
25.2 Unauthorized access to falsify charging
parameters, such as charging voltage,
charging power, battery temperature, etc.
6. Mitigations for "Potential vulnerabilities that could be exploited if not sufficiently protected or hardened"
Mitigations to the threats which are related to "Potential vulnerabilities that could be exploited if not sufficiently
protected or hardened" are listed in Table B6.
Table B6
Mitigations to the threats which are related to "Potential vulnerabilities that could be exploited if not
sufficiently protected or hardened"
Threats to "Potential vulnerabilities that could be
Table A1
exploited if not sufficiently protected or Ref Mitigation
reference
hardened"
26.1 Combination of short encryption keys and M23 Cybersecurity best practices for software and
long period of validity enables attacker to hardware development shall be followed
break encryption
26.2 Insufficient use of cryptographic algorithms
to protect sensitive systems
26.3 Using deprecated cryptographic algorithms
27.1 Hardware or software, engineered to enable M23 Cybersecurity best practices for software and
an attack or fail to meet design criteria to hardware development shall be followed
stop an attack
28.1 The presence of software bugs can be a basis M23 Cybersecurity best practices for software and
for potential exploitable vulnerabilities. This hardware development shall be followed.
is particularly true if software has not been Cybersecurity testing with adequate coverage
tested to verify that known bad code/bugs is
not present and reduce the risk of unknown
bad code/bugs being present
ELI: http://data.europa.eu/eli/reg/2025/5/oj 27/30EN
OJ L, 10.1.2025
Threats to "Potential vulnerabilities that could be
Table A1
exploited if not sufficiently protected or Ref Mitigation
reference
hardened"
28.2 Using remainders from development (e.g.
debug ports, JTAG ports, microprocessors,
development certificates, developer
passwords, …) can permit an attacker to
access ECUs or gain higher privileges
29.1 Superfluous internet ports left open,
providing access to network systems
29.2 Circumvent network separation to gain M23 Cybersecurity best practices for software and
control. Specific example is the use of hardware development shall be followed.
unprotected gateways, or access points Cybersecurity best practices for system design
(such as truck-trailer gateways), to and system integration shall be followed
circumvent protections and gain access to
other network segments to perform
malicious acts, such as sending arbitrary
CAN bus messages
7. Mitigations for "Data loss / data breach from vehicle"
Mitigations to the threats which are related to "Data loss / data breach from vehicle" are listed in Table B7.
Table B7
Mitigations to the threats which are related to "Data loss / data breach from vehicle"
Table A1
Threats of "Data loss / data breach from vehicle" Ref Mitigation
reference
31.1 Information breach. Personal data may be breached M24 Best practices for the protection of data
when the car changes user (e.g. is sold or is used as integrity and confidentiality shall be
hire vehicle with new hirers) followed for storing personal data.
8. Mitigations for "Physical manipulation of systems to enable an attack"
Mitigation to the threats which are related to "Physical manipulation of systems to enable an attack" are listed in
Table B8.
Table B8
Mitigations to the threats which are related to "Physical manipulation of systems to enable an attack"
Table A1 Threats to "Physical manipulation of systems to
Ref Mitigation
reference enable an attack"
32.1 Manipulation of OEM hardware, e.g. M9 Measures to prevent and detect unauthorized
unauthorised hardware added to a vehicle access shall be employed
to enable "man-in-the-middle" attack
28/30 ELI: http://data.europa.eu/eli/reg/2025/5/ojEN
OJ L, 10.1.2025
PART C
Mitigations to the threats outside of vehicles
1. Mitigations for "Back-end servers"
Mitigations to the threats which are related to "Back-end servers" are listed in Table C1.
Table C1
Mitigations to the threats which are related to "Back-end servers"
Table A1
Threats to "Back-end servers" Ref Mitigation
reference
1.1 & 3.1 Abuse of privileges by staff (insider M1 Security Controls are applied to back-end systems to
attack) minimise the risk of insider attack
1.2 & 3.3 Unauthorised internet access to the M2 Security Controls are applied to back-end systems to
server (enabled for example by minimise unauthorised access. Example Security
backdoors, unpatched system Controls can be found in OWASP
software vulnerabilities, SQL attacks
or other means)
1.3 & 3.4 Unauthorised physical access to the M8 Through system design and access control it should
server (conducted by for example USB not be possible for unauthorised personnel to access
sticks or other media connecting to personal or system critical data
the server)
2.1 Attack on back-end server stops it M3 Security Controls are applied to back-end systems.
functioning, for example it prevents it Where back-end servers are critical to the provision of
from interacting with vehicles and services there are recovery measures in case of system
providing services they rely on outage. Example Security Controls can be found in
OWASP
3.2 Loss of information in the cloud. M4 Security Controls are applied to minimise risks
Sensitive data may be lost due to associated with cloud computing. Example Security
attacks or accidents when data is Controls can be found in OWASP and NCSC cloud
stored by third-party cloud service computing guidance
providers
3.5 Information breach by unintended M5 Security Controls are applied to back-end systems to
sharing of data (e.g. admin errors, prevent data breaches. Example Security Controls can
storing data in servers in garages) be found in OWASP
2. Mitigations for "Unintended human actions"
Mitigations to the threats which are related to "Unintended human actions" are listed in Table C2.
ELI: http://data.europa.eu/eli/reg/2025/5/oj 29/30EN
OJ L, 10.1.2025
Table C2
Mitigations to the threats which are related to "Unintended human actions"
Table A1
Threats relating to "Unintended human actions" Ref Mitigation
reference
15.1 Innocent victim (e.g. owner, operator or M18 Measures shall be implemented for defining and
maintenance engineer) is tricked into controlling user roles and access privileges,
taking an action to unintentionally load based on the principle of least access privilege
malware or enable an attack
15.2 Defined security procedures are not M19 Organizations shall ensure security procedures
followed are defined and followed including logging of
actions and access related to the management of
the security functions
3. Mitigations for "Physical loss of data"
Mitigations to the threats which are related to "Physical loss of data" are listed in Table C3.
Table C3
Mitigations to the threats which are related to "Physical loss of data loss"
Table A1
Threats of "Physical loss of data" Ref Mitigation
reference
30.1 Damage caused by a third party. Sensitive data may M24 Best practices for the protection of data
be lost or compromised due to physical damages in integrity and confidentiality shall be
cases of traffic accident or theft followed for storing personal data.
Example Security Controls can be found
30.2 Loss from DRM (digital right management)
in ISO/SC27/WG5
conflicts. User data may be deleted due to DRM
issues
30.3 The (integrity of) sensitive data may be lost due to
IT components wear and tear, causing potential
cascading issues (in case of key alteration, for
example)
30/30 ELI: http://data.europa.eu/eli/reg/2025/5/oj