UN R155 CSMS requirements and the diagnostic channel
A certified Cyber Security Management System is now a condition of vehicle type approval, and the diagnostic channel is one of the few attack surfaces the regulation names outright. Here is what UN R155 actually requires, where diagnostics appears in its threat catalogue, and what the assessment examines.
The security sibling of R156
UN R155 and UN R156 were adopted together by the UNECE's World Forum for Harmonization of Vehicle Regulations (WP.29) in June 2020, and both entered into force on 22 January 2021. They are two halves of one idea: R156 governs how software reaches a vehicle — we unpacked its engineering standard in the ISO 24089 article — while R155 governs the cyber-security of the vehicle and of the organisation behind it. Its central instrument is the Cyber Security Management System: a systematic risk-based approach defining the organisational processes, responsibilities and governance that treat the risk of cyber threats to vehicles. The scope covers passenger cars and commercial vehicles, trailers with at least one ECU, and light four-wheelers with level-3-or-higher automated driving.
The teeth are in type approval. The manufacturer's CSMS is assessed by an approval authority and receives a Certificate of Compliance valid for at most three years — the same ceiling UN R156 sets for its Software Update Management System certificate — and withdrawn if its requirements are no longer met. Without a valid certificate there is no vehicle type approval, and an expired or withdrawn certificate puts the approvals that rested on it in question. In the EU the enforcement dates come from the General Safety Regulation rather than from R155 itself: type approval has been refused for new vehicle types since July 2022, and since July 2024 non-compliant new vehicles can no longer be registered, sold or enter into service.
Where diagnostics appears in the threat catalogue
Annex 5 of R155 is the regulation's threat catalogue. Part A is the baseline of threats, vulnerabilities and attack methods; Parts B and C list mitigations for the vehicle and for areas outside it, such as backends. The duty is explicit: the manufacturer shall perform an exhaustive risk assessment for the vehicle type that considers every threat in Part A, and shall implement every Part B and C mitigation relevant to the risks found.
Read Part A with diagnostics in mind and it appears in four of the seven threat groups. Under communication channels: malicious diagnostic messages. Under external connectivity: diagnostic access (e.g. dongles in OBD port) used to facilitate an attack, alongside other devices on external interfaces. Under threats to vehicle data and code: unauthorised changes to system diagnostic data. And under potential vulnerabilities: development remainders — debug and JTAG ports, development certificates, developer passwords — permitting access to ECUs or escalation of privilege. The channel every workshop legitimately uses is also one of the most explicitly catalogued attack surfaces in the regulation.
The corresponding mitigations are deliberately terse. Malicious diagnostic messages are answered by the requirement that the vehicle verify the authenticity and integrity of messages it receives; the OBD-port threats by a single sentence: security controls shall be applied to external interfaces. The regulation states what must be true and stops there. Everything below that sentence — which controls, on which services, with which cryptography — is engineering, and it is where the real work of R155 compliance on the diagnostic channel lives.
From one-sentence mitigations to protocol engineering
On the diagnostic channel, access control has for decades meant UDS service 0x27, SecurityAccess: a seed-key exchange gating the privileged services — reprogramming via RequestDownload, TransferData and RequestTransferExit, protected identifiers and routines. ISO 14229-1 does not standardise the seed-key algorithm, so the protection rests entirely on the secrecy of a manufacturer-specific scheme. Published security research documents how that goes wrong in practice: short seeds on legacy ECUs that can be brute-forced, static seeds that make replay possible, and algorithms that can be recovered from a firmware dump and reused across an entire ECU family. These are implementation weaknesses rather than defects in the standard's text — but a risk assessment has to judge the mechanism as deployed, not as intended.
The modern alternative is service 0x29, Authentication, introduced in ISO 14229-1:2020 precisely to address cyber-security: certificate-based, supporting mutual authentication, with roles and rights bound to certificates that can be revoked. The two services coexist — 0x29 is optional, and a large share of ECUs in the field still carry only 0x27 — so a defensible risk assessment must state which mechanism guards which services on which ECUs, and why that is proportionate to the threat. We compared the two mechanisms in depth in Securing the diagnostic channel.
The transport is now a network: DoIP and TLS
Modern off-board diagnostics increasingly rides on DoIP (ISO 13400), which makes the diagnostic channel a network endpoint in the ordinary IT sense. The 2019 edition of ISO 13400-2 added TLS for exactly that reason: unsecured diagnostic TCP traffic runs on port 13400, TLS-secured traffic on port 3496, while vehicle discovery over UDP remains unsecured.
Peer-reviewed analysis has drawn the uncomfortable conclusion: a 2022 study presented at the Computer Science in Cars Symposium found that the DoIP protocol cannot be considered secure by default, mainly because TLS and client authentication are optional in the standard. A DoIP implementation can be fully standard-conformant and still expose an unauthenticated, plaintext channel into the vehicle. That is precisely the kind of gap an exhaustive risk assessment exists to surface — conformance to the transport standard is not, by itself, a mitigation.
What the approval authority actually asks for
The CSMS assessment is organisational before it is technical. The manufacturer must demonstrate that its management system applies across the development, production and post-production phases, with processes that identify risks against Annex 5, assess and treat them, verify the treatment, test the cyber-security of the vehicle type, and keep the assessment current. Monitoring must be continual, must include vehicles after first registration, and must be able to detect threats and attacks from vehicle data and logs — with the outcome reported to the approval authority at least once a year. The manufacturer must also demonstrate data forensic capability, and the regulation's interpretation document counts diagnostic error codes among the data that capability may draw on.
The evidence is audit-shaped rather than certificate-shaped. R155's own text names ISO/SAE 21434 only in a footnote about the competence of the authorities' assessors; the official interpretation document maps the regulation's requirements onto ISO/SAE 21434:2021 clauses and work products while stressing that referenced standards are examples, not mandatory. In practice that mapping has made 21434's work products the de-facto currency of a CSMS audit: approval authorities describe the exercise as confirming documented processes and objective evidence — document review, interviews and sampled testing — not as proving absolute security. At vehicle-type level the information document then wants the concrete package: the risk-assessment outcome, the mitigations implemented, the test results, and how the supply chain was considered.
Where a diagnostics supplier fits
R155 binds the vehicle manufacturer — a tool vendor or software supplier holds neither the CSMS certificate nor the type approval. But the regulation reaches suppliers all the same: the manufacturer must demonstrate — paragraph 7.2.2.5 of the regulation — how its CSMS manages dependencies on contracted suppliers, service providers and sub-organisations, and must identify and manage supplier-related risks for every vehicle type it approves. In practice those paragraphs arrive as contract clauses, and a supplier whose components cannot support the manufacturer's evidence becomes the manufacturer's problem — briefly.
For the diagnostic channel, evidence-ready has a concrete shape: access control that can be defended in a risk assessment — 0x29-capable where the privilege level demands it — TLS-capable DoIP endpoints, a reflashing chain whose signatures and gates hold end to end, and logging that can feed the manufacturer's monitoring and forensic duties. Under all of it sits the cryptographic footing — keys, certificates and their hardware protection: the cryptographic and key-storage layer Encrypt abstracts behind the AUTOSAR Crypto Service Manager API. The one-sentence mitigation in Annex 5 turns out to be a full engineering stack — and the suppliers who arrive with that stack already argued are the ones who make their customers' audits shorter.
Key takeaways
- UN R155 makes a certified Cyber Security Management System a condition of vehicle type approval — adopted with R156 in June 2020, in force since January 2021, enforced in the EU for new types since July 2022 and for all new vehicles since July 2024 via the General Safety Regulation.
- The CSMS Certificate of Compliance is valid for at most three years, withdrawn if its requirements are no longer met, and its loss puts the vehicle-type approvals resting on it in question.
- Diagnostics is named across the Annex 5 threat catalogue — malicious diagnostic messages, OBD-port diagnostic access, unauthorised changes to diagnostic data and leftover debug ports — and the manufacturer's risk assessment must consider every Part A threat.
- The regulation's mitigations are one sentence each; the engineering lives in the stack: UDS 0x27's documented weaknesses, certificate-based 0x29 Authentication, and TLS on DoIP (optional in the standard, so conformance alone is not security).
- ISO/SAE 21434 is not mandated by R155, but the official interpretation document maps the regulation onto its clauses and work products — making them the de-facto evidence currency of a CSMS audit, which suppliers meet through the contracts that flow down from paragraph 7.2.2.5.
Common questions
Does UN R155 apply to diagnostic tools and suppliers?
Directly, UN R155 binds the vehicle manufacturer: it is the manufacturer that holds the CSMS certificate and the type approval. But paragraph 7.2.2.5 requires the manufacturer to demonstrate how its CSMS manages dependencies on contracted suppliers, service providers and sub-organisations, and supplier-related risks must be identified and managed for every vehicle type. In practice those obligations arrive at diagnostics and tooling suppliers contractually — components are expected to show up evidence-ready.
Is SecurityAccess 0x27 enough for UN R155?
The regulation never names UDS services — it requires an exhaustive risk assessment against the Annex 5 threat catalogue and proportionate, demonstrably effective mitigations. Published security research documents real 0x27 weaknesses: short seeds on legacy ECUs that can be brute-forced, static seeds that enable replay, and secret algorithms that can be extracted from firmware. Whether 0x27 survives a risk assessment depends on what it guards; for reprogramming and other high-privilege services on new designs, certificate-based 0x29 Authentication is the stronger answer.
What is the difference between UN R155 and UN R156?
They were adopted together in June 2020 and both entered into force on 22 January 2021. UN R155 covers cyber-security: a certified Cyber Security Management System spanning development, production and post-production, risk assessment against the Annex 5 threat catalogue, continual monitoring and reporting. UN R156 covers software updates: a certified Software Update Management System governing how software reaches vehicles. Both certificates are valid for at most three years, and both are preconditions for vehicle type approval.
Does UN R155 require ISO/SAE 21434 certification?
No. The regulation's text names ISO/SAE 21434 only once, in a footnote listing examples of competence standards for the authorities' own assessors. The official interpretation document maps R155's requirements onto ISO/SAE 21434:2021 clauses and work products while stating that referenced standards are examples, not mandatory. In practice 21434 is the de-facto evidence framework for a CSMS assessment — but the legally required artefact is the Certificate of Compliance issued by an approval authority, not a commercial standard certificate.