A vehicle manufacturer that cannot show an approval authority a working, certified cyber security management system cannot get new vehicle types approved in the markets that apply UN Regulation No. 155. R155 is a type-approval regulation under the UNECE 1958 Agreement, and it turns automotive cyber security from engineering good practice into a legal condition of market access. This guide walks through the regulation clause by clause: who it binds, what paragraph 7 actually requires of the CSMS and of each vehicle type, the transitional dates, what happens when a manufacturer falls short, and how to build the evidence an assessor will ask for. It is written for product security leads at manufacturers, Tier 1 suppliers who must feed that evidence, and compliance teams. For the wider engineering picture (in-vehicle networks, R156 updates, fleet monitoring) see the Automotive Cybersecurity Guide.
Status line: checked 27 October 2026 against UN Regulation No. 155, Supplement 3 to the original version, as published in the EU Official Journal (OJ L 2025/5, entry into force 10 January 2025). The authentic texts are the ECE/TRANS/WP.29 documents, and WP.29 can adopt further supplements at any session, so confirm the current version before relying on a paragraph number.
Key takeaways
- Two approvals, not one. R155 needs a CSMS certificate for the organisation (valid for at most three years) and a separate type approval for each vehicle type that relies on it.
- The CSMS spans the whole life of the type. Paragraph 7.2.2.1 covers development, production and post-production, which runs until no vehicles of the type remain in operation.
- Annex 5 is the minimum threat catalogue. Every threat in Annex 5 Part A must be considered for the vehicle type, and relevant mitigations from Parts B and C implemented or replaced with a justified alternative.
- Reporting never stops. Paragraph 7.4.1 requires a monitoring report to the approval authority at least once a year, and paragraph 6.8 lets the authority withdraw the CSMS certificate if the response is insufficient.
- Suppliers and back ends are in scope. Paragraph 7.2.2.5 makes the manufacturer show how it manages dependencies on suppliers and service providers, and Annex 5 lists back-end servers as the first threat group, so credentials held by suppliers, cloud services and tools are part of the audit.
Scope: who and what is covered
Paragraph 1.1 of the Supplement 3 text applies R155 to vehicles of categories L, M, N and O with regard to cyber security. In practice that is passenger cars (M1), buses and coaches (M2, M3), vans and trucks (N1 to N3), trailers with electronics (O) and, on the later timetable described below, powered two and three wheelers and quadricycles (L). The text applies without prejudice to other UN Regulations, to regional or national rules on access to vehicle data and on privacy, and to rules on replacement parts (paragraphs 1.2 and 1.3).
The legal duty sits with the manufacturer that applies for approval. Suppliers are not approved under R155, but they are drawn in contractually because the manufacturer must evidence the risk management of everything it integrates.
| Party | How R155 reaches it | What it typically has to produce |
|---|---|---|
| Vehicle manufacturer (OEM) | Applicant for the CSMS certificate and vehicle type approval | CSMS processes, vehicle type risk assessment, test evidence, annual monitoring report |
| Approval authority and technical service | Assess the CSMS (7.2.1), verify the type (7.3), receive reports (7.4) | Certificate of compliance for CSMS, type approval, findings and remedial demands |
| Tier 1 and Tier 2 suppliers | Supplier dependencies under 7.2.2.5 and supplier risks under 7.3.2 | Component risk analysis, vulnerability handling commitments, interface agreements, test reports |
| Back-end and service providers | Annex 5 Part A threats to back-end servers, communication channels and update procedures | Security controls and incident data for telematics, apps, OTA and remote services |
| Aftermarket software providers | Paragraph 7.3.5 on dedicated environments for aftermarket software and services | Isolation evidence where the vehicle offers such an environment |
A vehicle type, for R155 purposes, is defined in paragraph 2.1 by the manufacturer's designation and essential aspects of the electrical and electronic architecture. A new telematics unit or a new external interface can therefore mean a new or extended approval, which is why architecture change control belongs inside the CSMS.
Geographically, R155 binds the Contracting Parties to the 1958 Agreement that choose to apply it. The EU applies it through its General Safety Regulation framework (Regulation (EU) 2019/2144, which itself applies from 6 July 2022), and other Contracting Parties apply it on their own timelines. Markets outside the 1958 Agreement, notably the United States, are not bound, although many manufacturers run one global CSMS.
Key obligations
The cyber security management system (paragraph 7.2)
Paragraph 2.3 defines the CSMS as a systematic, risk-based approach defining organisational processes, responsibilities and governance. Paragraph 7.2.2.2 lists what the processes must cover:
- (a) Governance: processes for managing cyber security within the organisation.
- (b) Risk identification: identifying risks to vehicle types, including the Annex 5 Part A threats and other relevant threats.
- (c) Risk treatment: assessing, categorising and treating identified risks.
- (d) Verification: checking that identified risks are appropriately managed.
- (e) Testing: testing the cyber security of a vehicle type.
- (f) Currency: keeping the risk assessment current.
- (g) Monitoring and response: monitoring for, detecting and responding to attacks, threats and vulnerabilities, and assessing whether measures remain effective.
- (h) Forensic data: providing relevant data to support analysis of attempted or successful attacks.
Paragraph 7.2.2.3 requires threats and vulnerabilities that need a response to be mitigated within a reasonable timeframe. Paragraph 7.2.2.4 requires continual monitoring to include vehicles after first registration and the ability to analyse threats from vehicle data and logs, within privacy limits and consent. Paragraph 7.2.2.5 requires the manufacturer to show how the CSMS manages dependencies on contracted suppliers, service providers and sub-organisations.
The vehicle type (paragraph 7.3)
| Paragraph | Requirement in plain terms | Evidence an assessor expects |
|---|---|---|
| 7.3.1 | A valid CSMS certificate relevant to the type | Certificate reference, scope covering this type |
| 7.3.2 | Identify and manage supplier-related risks for the type | Supplier risk records, interface agreements, flow-down clauses |
| 7.3.3 | Identify critical elements, run an exhaustive risk assessment including interactions with external systems, consider all Annex 5 Part A threats | Threat analysis and risk assessment (TARA) with Annex 5 traceability |
| 7.3.4 | Implement proportionate mitigations, including relevant Annex 5 Parts B and C mitigations, or justified alternatives | Mitigation register mapped to M1 to M24, feasibility rationale |
| 7.3.5 | Secure dedicated environments for aftermarket software, services, applications or data, where provided | Isolation architecture and test results |
| 7.3.6 | Appropriate and sufficient testing before approval | Test plans, penetration test reports, defect closure |
| 7.3.7 | Detect and prevent attacks, support monitoring, provide data forensic capability | Intrusion detection design, logging specification, fleet monitoring link |
| 7.3.8 | Cryptographic modules follow consensus standards, or use is justified | Crypto inventory with algorithm and standard references |
Annex 5: the threat and mitigation catalogue
Annex 5 Part A lists threats grouped under back-end servers, vehicle communication channels, update procedures, unintended human actions, external connectivity and connections, the data and code of the vehicle, and potential vulnerabilities that could be exploited. The Supplement 3 table carries 30 numbered high-level threats (some numbers are not used), each with sub-level examples. Part B maps vehicle-side mitigations to those threats, and Part C covers mitigations outside the vehicle, such as back-end server protection. Mitigations are numbered M1 to M24. Treat Annex 5 as a floor: paragraph 7.2.2.2(b) also requires "other relevant threats", which is where newer attack surfaces such as charging, digital keys and AI features enter.
Reporting (paragraph 7.4)
The manufacturer must report the outcome of its monitoring activities to the approval authority or technical service at least once a year, or more often if relevant, including new cyber attacks and confirmation that mitigations remain effective. The authority verifies the report and may require remediation.
Timeline and current status
| Date | Event | Source |
|---|---|---|
| 6 July 2022 | Regulation (EU) 2019/2144 applies, bringing R155 into EU type approval for new types | Regulation (EU) 2019/2144, Article 19 |
| Before 1 July 2024 | For M, N and O types first approved before this date, the manufacturer could rely on a development-phase demonstration where the CSMS could not be applied, and justify infeasible Annex 5 mitigations | R155 paragraphs 7.3.1 and 7.3.4 |
| July 2024 | In the EU, R155 compliance extended to newly registered vehicles in scope, including older types still in production, on the General Safety Regulation timetable (check Annex II of Regulation (EU) 2019/2144 for the exact date) | EU General Safety Regulation timetable |
| 10 January 2025 | Supplement 3 to the original version enters into force (EU Official Journal 2025/5) | OJ L 2025/5 |
| Before 1 July 2029 | Equivalent transitional relief for category L types first approved before this date | R155 paragraphs 7.3.1 and 7.3.4 |
Two practical consequences follow. First, the transitional relief for cars, vans, trucks and trailers has ended, so any new M, N or O approval now needs full CSMS evidence. Second, L-category manufacturers have until mid-2029 for full application, and many are building their CSMS now. The engineering standard most manufacturers use as evidence, ISO/SAE 21434:2021, has been marked "to be revised" by ISO, so expect a new edition during the life of current certificates. See the ISO/SAE 21434 Automotive Cybersecurity Engineering Guide.
Enforcement and penalties
R155 is enforced through type approval rather than fines written into the regulation itself.
- No certificate, no approval: without a valid CSMS certificate (7.3.1) the authority cannot grant type approval, which in practice blocks sale and registration of new vehicles of that type.
- Withdrawal at any time: paragraph 6.8 lets the approval authority verify at any time that the CSMS requirements continue to be met, and provides for withdrawal of the CSMS certificate where they are not. Paragraph 7.4.2 links insufficient reporting or response directly to that withdrawal route.
- Renewal is a reassessment: the certificate lasts at most three years (6.7) and is renewed only after a positive reassessment (6.10). A manufacturer that let its processes decay finds out at renewal.
- EU framework penalties: in the EU, type approval sits under Regulation (EU) 2018/858, whose recitals provide for Member State penalties that are effective, proportionate and dissuasive and for harmonised administrative fines imposed by the Commission on economic operators. The amounts and procedures are in that regulation and national law, not in R155.
- Market surveillance: a vulnerability exploited in the field can lead to corrective action and recall under the applicable type approval framework, which is usually far more costly than any fine.
What it means for AI agents and non-human identities
R155 never uses the phrase non-human identity, but most of its Annex 5 threats are realised through one. Back-end servers, update procedures and external connectivity are all authenticated by keys, certificates and tokens held by machines, suppliers and tools.
| Machine credential | Annex 5 threat area it maps to | Control that answers the assessor |
|---|---|---|
| Telematics and mobile app back-end API keys and service accounts | Back-end servers; external connectivity | Vaulted secrets, short-lived tokens, per-service accounts, access logging. See the Secrets Management Guide. |
| ECU identity keys and certificates, V2X and charging certificates | Vehicle communication channels; data and code | Per-device keys from a managed PKI, no shared symmetric fleet keys, certificate lifecycle. See the Machine Identity, PKI and Certificate Lifecycle Guide. |
| Software signing keys for OTA and workshop flashing | Update procedures | Hardware security modules, separation of signing roles, key ceremony records. See the UNECE R156 Software Update Management System Guide. |
| Diagnostic tool and workshop credentials, security access seeds and keys | Unintended human actions; external connectivity | Authenticated diagnostics, per-technician accounts, rate limiting of security access |
| Supplier and contractor CI/CD tokens and repository access | Supplier dependencies (7.2.2.5); data and code | Secret scanning, token expiry, access reviews in supplier agreements |
The cost of getting this wrong is not theoretical. In the Toyota T-Connect key exposure, a subcontractor published source code containing a data server access key to a public repository, where it stayed from December 2017 to September 2022. That is exactly the supplier dependency and back-end server risk that paragraphs 7.2.2.5 and Annex 5 ask a manufacturer to manage.
AI agents add two new questions. Inside the vehicle, an assistant or agent that can call vehicle functions or back-end APIs is an external connectivity path and a new "other relevant threat" under 7.2.2.2(b): its permissions, the tools it can invoke and the data it can reach belong in the TARA. Outside the vehicle, agents used for fleet monitoring triage, code review or test generation hold credentials to logs, repositories and back ends, and those credentials need the same ownership, scoping and expiry as any service account. Record agent use in the CSMS so the annual report can show it is controlled.
Compliance steps
- Confirm scope and approval routes. List vehicle types, categories, markets and the approval authority for each, and record which version of R155 each approval was granted under.
- Write the CSMS against 7.2.2.2 (a) to (h). Map each lettered item to a named process, owner and record. Most manufacturers use ISO/SAE 21434 organisational clauses for this, and a gap there becomes a finding here.
- Build Annex 5 traceability. Create a matrix from every Part A threat to the TARA entries of each vehicle type and to the mitigation chosen (Annex 5 M number or alternative with justification).
- Flow requirements to suppliers. Put vulnerability notification, evidence delivery, credential handling and support periods into contracts and interface agreements, and test that suppliers can actually deliver incident data.
- Inventory machine credentials and crypto. For each type, list keys, certificates, back-end service accounts and signing keys, their owners, storage and rotation, and the consensus standard for each cryptographic module (7.3.8).
- Test before approval. Run component and vehicle-level testing including penetration testing of external interfaces, and close or risk-accept findings with records the technical service can follow.
- Stand up post-production monitoring. Connect vehicle logs, back-end telemetry and vulnerability intelligence to a vehicle security operations function with defined response timeframes, so that 7.2.2.3 and 7.2.2.4 are met in practice.
- Rehearse the annual report. Produce a dry-run report covering monitoring outcomes, new attacks, mitigation effectiveness and actions, and have it reviewed internally before the authority sees one.
- Plan renewal from day one. Track internal audit findings and process changes so the three-year reassessment is a confirmation, not a rebuild.
Measuring whether the CSMS works
- Annex 5 coverage: percentage of Part A threats with a traced TARA decision per vehicle type (target 100 percent).
- Vulnerability response time: median days from intake to mitigation decision, and to deployed fix, by severity.
- Supplier evidence completeness: share of in-scope suppliers with current interface agreements and tested notification channels.
- Credential hygiene: share of back-end and supplier credentials with a named owner, expiry and storage in a vault or HSM.
- Monitoring reach: share of the registered fleet whose security events reach the monitoring function.
Where R155 sits against other frameworks
| R155 provision | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| 7.2.2.2(a) governance | GV.RM-01, GV.OC-03 | PM-9 |
| 7.2.2.2(b) to (d), 7.3.3 risk assessment | ID.RA-05 | RA-3 |
| 7.2.2.5, 7.3.2 suppliers | GV.SC-05, GV.SC-07 | SR-3, SR-6 |
| 7.3.6 testing | ID.IM-01 | SA-11 |
| 7.2.2.2(g), 7.3.7 monitoring and forensics | DE.CM-01, DE.AE-02 | SI-4, AU-2 |
| 7.3.8 cryptography | PR.DS-02 | SC-13 |
| 7.4 reporting | RS.CO-02 | IR-6 |
Common failure patterns
- A CSMS on paper only: process documents exist but no vehicle type TARA traces to them, so the technical service cannot see 7.2.2.2 working on a real type.
- Annex 5 treated as the whole threat model: new interfaces such as digital keys, charging and in-car assistants are missed because they are not named in Part A.
- Supplier evidence that cannot be produced on demand: contracts promise vulnerability notification but nobody has tested the channel, and incident data never arrives in the format monitoring needs.
- Back-end credentials outside the CSMS: cloud and API keys are owned by IT or a contractor and never reach the vehicle risk assessment, the pattern in the Toyota T-Connect case.
- Post-production monitoring that stops at the fleet: vehicle logs are collected but back-end and supplier telemetry are not, so the annual report under 7.4.1 is thin.
Practitioner checklist
- Record the R155 version (Supplement 3 or later) and approval authority for each vehicle type.
- Map each of 7.2.2.2 (a) to (h) to a named process, owner and record.
- Maintain an Annex 5 Part A to TARA to mitigation (M1 to M24 or alternative) matrix per type.
- Put vulnerability notification, evidence delivery and credential rules into every in-scope supplier agreement.
- Inventory back-end service accounts, API keys, ECU keys and signing keys with owner, storage and rotation.
- Justify each cryptographic module against a consensus standard under 7.3.8.
- Run pre-approval penetration tests on every external interface and close findings with records.
- Feed vehicle, back-end and supplier events into one monitoring and response function with defined timeframes.
- Produce a dry-run annual report and track it to the three-year renewal.
- Add in-vehicle AI features and AI agents used in engineering or monitoring to the TARA and credential inventory.
Standards and references
- EUR-Lex: UN Regulation No. 155 on cyber security and cyber security management systems (OJ 2025/5)
- EUR-Lex: Regulation (EU) 2019/2144 on type-approval requirements for motor vehicles (General Safety Regulation)
- EUR-Lex: Regulation (EU) 2018/858 on approval and market surveillance of motor vehicles
- ISO: ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering
- NIST: Cybersecurity Framework (CSF) 2.0
- ISO: ISO 24089:2023 Road vehicles, Software update engineering
Related NHI Mgmt Group resources: Automotive Cybersecurity Guide · ISO/SAE 21434 Automotive Cybersecurity Engineering Guide · UNECE R156 Software Update Management System Guide · Connected and Autonomous Vehicle Security Guide · Secrets Management Guide. This guide summarises UN Regulation No. 155 and is not legal advice.