UN R155 Annex 5, decoded: the automotive threat catalogue

Annex 5 as a working checklist

Annex 5 is the part of UN R155 that turns the abstract phrase "cyber threats" into a structured list you can actually work through. It is where the regulation says, in effect: here is the landscape of things that can go wrong with a connected vehicle, and here is what you are expected to do about each of them.

It has three parts. Part A enumerates the threats and the vulnerabilities they exploit. Parts B and C set out mitigations — Part B for threats to vehicles, Part C for threats outside the vehicle, such as the back-end. Read together, they form a threat-to-mitigation map that a manufacturer maps its own analysis against.

The point of Annex 5 is not that you copy it. The point is coverage. When an assessor asks whether your risk assessment missed a category, Annex 5 is the reference you both hold. If your analysis has nothing to say about, for instance, update procedures or external connectivity, that gap is visible immediately.

The high-level categories

Part A organises threats into seven high-level categories. The table below states each and gives a representative example of what sits under it.

Annex 5 high-level category	Representative threat
Back-end servers	Compromise of servers used to operate or update vehicles; data exfiltration or abuse of server access
Communication channels	Spoofing, injection or interception of messages between vehicle and infrastructure; manipulation of in-vehicle network traffic
Vehicle update procedures	A malicious or corrupted software update; a failed update leaving the vehicle in an unsafe state
Unintended human actions	Legitimate actors misconfiguring or mishandling systems; social engineering enabling access
External connectivity and connections	Attacks via diagnostic ports, telematics, charging, or any external interface into the vehicle
Potential targets of, or motivations for, an attack	Extraction of code, data, credentials or intellectual property held on the vehicle
Vulnerabilities that could be exploited	Weak or absent authentication, poor cryptography, unhardened software that underlies the above

Each category expands into specific, numbered threat descriptions in the regulation text. The value of the seven-way split is that it forces breadth: a team that has done deep work on the in-vehicle network but nothing on the back-end has an obvious hole.

From category to real attack

The categories are not academic. The communication channels category, for example, is exactly where a CAN bus attack lives — the in-vehicle network has no built-in authentication, so with bus access an attacker can inject, spoof or fuzz messages. We work through those techniques in CAN bus attacks explained. The external connectivity category is where diagnostic access over OBD-II, telematics interfaces and charging inlets belong. The update procedures category is the reason UN R156 and a Software Update Management System exist alongside R155.

Reading Annex 5 this way — each category as a doorway to concrete attacks your product must resist — is more useful than reading it as a compliance list to be ticked.

How Annex 5 meets the TARA

Annex 5 tells you what to worry about. It does not tell you how heavily to worry, for your specific design. That is the job of the threat analysis and risk assessment (TARA), defined in ISO/SAE 21434 clause 15.

The relationship is straightforward. The TARA identifies your assets, builds threat scenarios, analyses attack paths, rates impact and feasibility, and determines risk for the vehicle type in front of you. Annex 5 is then used as a coverage check: for every relevant high-level category, is there a corresponding entry in your analysis, and a mitigation traced to it? The full method sits in TARA, step by step.

This is where the two documents complement each other. A TARA without Annex 5 coverage might be deep but narrow. Annex 5 without a TARA is a generic list with no bearing on your actual risk. The regulation expects both: your own risk-based analysis, demonstrably reconciled against the common catalogue.

Mitigations, and proving they run

Parts B and C list the mitigations expected against the Part A threats. But listing a mitigation is not the same as demonstrating it. For each threat you claim to have treated, an R155 assessment expects to see the mitigation designed into the product and evidence that it works — a test result, a verification record, a monitoring capability that produces data.

That is the recurring theme across UN R155: the difference between describing a control and proving it operates. A row in your Annex 5 mapping that says "message authentication" needs the design and the test behind it, not just the phrase.

Annex 5 also does not stand still in practice. Post-production monitoring — required by the CSMS — feeds new threats back into the picture, and a mitigation that was adequate at approval can be overtaken. The mapping is a living document, revisited as the fleet ages and as new attack techniques surface.

The AutoSifu view

An Annex 5 mapping is where a lot of first assessments quietly fail — categories left blank, mitigations named but never evidenced, a TARA that never reconciled against the catalogue. AutoSifu runs Annex 5 as one connected route: we build the TARA, reconcile it against every category, design and test the mitigations, and assemble the evidence for CoC and vehicle type approval — with our partner CIRT, a named test agency, reviewing the mapping as it is built rather than after it is submitted.