Reading R155 like a security engineer, not a lawyer

The first time I read UNECE R155 end to end, I came away convinced it was a procurement document. Long, careful, written in the kind of structured prose that compliance teams love and engineers ignore. I put it down and went back to writing detection rules. That was the mistake.

The mistake is that R155 is, in fact, an engineering document. It just doesn't read like one. The signals are there if you know where to look, and the clauses that actually constrain how you build a vehicle security programme are scattered across three different sections that compliance teams typically read in isolation. Read them together, and the regulation tells you what to build. Read them separately, and you end up with a Cybersecurity Management System that looks great on paper and fails on its first real incident.

This is a field guide for engineers who have been handed the R155 PDF and told to "make sure we comply." It is not legal advice. It is structural advice. If you understand the load-bearing clauses, the compliance work organises itself around them.

What R155 is, in one paragraph

UNECE Regulation No. 155 is a type-approval regulation for road vehicles, adopted in 2021 and applied progressively across UNECE-1958 contracting parties. It requires that the manufacturer of a new vehicle type have a certified Cybersecurity Management System (CSMS) covering the vehicle's full lifecycle, and that the specific vehicle type has been assessed against a defined threat list and the mitigations documented. Without both, no type approval. Without type approval, no sale.

That two-part structure is the first thing engineers usually miss. R155 is not one regulation. It is a process regulation (§7.2, the CSMS) bolted to a product regulation (§7.3, the vehicle type), with both clauses depending on each other in ways that aren't obvious from the table of contents.

The three clauses that actually constrain your work

§7.2 — Your processes have to exist before the vehicle does

The CSMS clause requires an organisation-wide process for managing cyber risk across design, development, production, post-production, and decommissioning. Five lifecycle phases, each with its own evidence requirements. The clause is not asking whether you have a security team. It is asking whether you have processes that produce evidence on every vehicle that ships.

The catch is in §7.2.2.2: the CSMS must include processes to identify risks "from suppliers, service providers or [the manufacturer's] sub-organisations." This is supplier risk inheritance. If your Tier 1 ships you an ECU with a vulnerability, your CSMS has to be the system that catches it, not theirs. Your contract clauses, your audits, your acceptance testing, your monitoring. The regulator does not care that your Tier 1 has ISO/SAE 21434 certification. They care whether your CSMS treats them as an input to your own risk model.

For an engineering team, this clause translates to: every supplier interface needs a documented threat model, an acceptance test that exercises the threat model, and a feedback loop that updates the model when something breaks in the field. If you cannot point to that for a given Tier 1, you have a CSMS gap.

§7.3 — Your specific vehicle has its own evidence file

Section 7.3 is where the per-type-approval work lives. For each vehicle type, the manufacturer must demonstrate that the threats listed in Annex 5 have been assessed and either mitigated or formally accepted. Annex 5 is a list of about seventy threat types organised by category: communication channels, update procedures, unintended human actions, external connectivity, vehicle data and code, and so on.

The honest reading of Annex 5 is that it is a baseline, not a ceiling. Most manufacturers add OEM-specific threats — anything tied to their proprietary ECUs, their cloud platform, their over-the-air pipeline — and document those alongside the Annex 5 entries. The regulator does not penalise you for finding more threats than the annex lists. They penalise you for missing threats the annex did list.

The subclause to memorise is §7.3.7: monitoring, detection, and response. Every type approval has to include a documented capability to detect and respond to cyber attacks on the vehicle in service. Not in theory. In service. This is the clause that demands a Vehicle Security Operations Centre, even though it never uses the word "VSOC."

§7.4 — The clause that keeps you up at night

The third load-bearing clause is the one most teams skim. §7.4 makes the type approval contingent on the manufacturer maintaining the CSMS in good standing for the life of the vehicle type. Not until the vehicle leaves the factory. Not until the warranty expires. For the life of the type, which on a typical platform means fifteen to twenty years.

This is where the regulation stops being a checklist and becomes a permanent operational burden. New threats appear, new attack tools appear, the platform's threat surface evolves with every OTA release, and §7.4 says all of that has to be tracked and the type approval evidence kept current. Miss the obligation and the approver can suspend the type approval, which is a more serious commercial event than most engineering teams realise.

What the law lets you skip, and what it does not

There is a quiet permissive structure inside R155 that the regulation never advertises. §7.3.4 lets you accept residual risk if the mitigation is "disproportionate to the risk." §7.3.6 lets you defer mitigation if the threat is being addressed in a subsequent vehicle type. The clauses do not give you a free pass; they give you a documented way to say "we considered this and chose not to mitigate it for these reasons."

The risk-acceptance pathway is a useful engineering tool when used carefully. We have seen it used responsibly on legacy CAN architectures where retrofitting a cryptographic envelope would have required a hardware change the platform could not absorb. We have also seen it abused as a way to declare every uncomfortable threat "accepted" and move on. The regulator's audit teams know the difference. They look at the trend: how many of your Annex 5 threats are documented as accepted versus mitigated, and how that ratio compares to your peers.

If a competitor mitigates 64 of 70 Annex 5 threats and you mitigate 28, the conversation you have with the type approver is structurally different. The clause that lets you accept risk is real. The clause that lets you abuse it does not exist.

What R155 does not actually require

There are three common misreadings worth flagging, because they distort programme priorities.

R155 does not require a specific SOC product, a specific SIEM, or a specific log retention period. §7.3.7 requires a capability. It does not name a product category. A small team running a tuned ELK stack with a clear runbook can be R155-compliant; a large team running a leading SIEM without operational discipline can fail. The audit looks at the runbook and the evidence trail, not the vendor.

R155 does not require continuous certificate transparency or specific cryptographic algorithms. This is the part that surprises post-quantum specialists. The regulation is algorithm-agnostic. What it does require is that you have documented your cryptographic choices and assessed the threats they address. If you cannot defend why you chose ECDSA P-256 in 2026, that is an audit finding. If you can show you considered the harvest-now-decrypt-later threat and have a migration plan, that is compliance.

R155 does not require you to disclose vulnerabilities publicly within a fixed window. The reading clauses around disclosure are softer than people assume. The hard requirement is that you have a process for handling disclosed and discovered vulnerabilities. CVE issuance, coordinated disclosure timing, public advisories — these are best practices and in some jurisdictions adjacent regulations, but they are not direct R155 requirements. Confusing the two has caused real programme decisions to be made on bad information.

How to read R155 if you are starting today

If you have been handed the regulation cold, here is the reading order that gets you to engineering decisions fastest.

Start with Annex 5. The threat list is the most concrete part of the regulation and the one your team will need to engage with line by line. Read it before you read the main clauses. You will have a much better sense of what the regulation actually expects when you reach §7.3.

Then read §7.3.7 specifically. This is the clause that determines whether your operational programme is plausible. If you can answer "how do we detect, how do we respond, how do we maintain the evidence trail" with named processes and named tools, you have the spine of a compliant programme. If you cannot, the rest of the regulation will not save you.

Then go back to §7.2 and read the CSMS clauses against the operational reality from §7.3.7. The processes the CSMS describes have to produce the artefacts §7.3.7 demands. If they do not, you have a process that exists on paper and a vehicle programme that fails in the field — which is exactly the failure mode the regulation is structured to catch.

Finally, read §7.4 and ask the uncomfortable question: who in your organisation is responsible for keeping the type approval current for the next fifteen years? If the answer is "the CSMS team," check whether that team has the funding model to exist for fifteen years. If the answer is "the security team," check whether they have authority over post-production changes. If the answer is "nobody owns that yet," your programme has a structural gap that no amount of clause-reading will close.

The reading that matters

R155 is a regulation written in compliance language about engineering work. The compliance language hides the engineering. If you read it as a checklist, you build a checklist programme, and the regulator's audit team finds the gap. If you read it as a set of engineering constraints on a vehicle programme, you build something that works on the road and survives the audit.

The clauses that matter are §7.2.2.2, §7.3.7, and §7.4. Everything else is structural support for those three. Read them in that order, with the threat list from Annex 5 open in another window, and the regulation stops being a document you comply with. It becomes a document you build to.

---

This piece is part of an ongoing series on automotive security regulation. We work with OEMs and Tier 1 suppliers on R155 / R156 readiness, ISO/SAE 21434 evidence pipelines, and the operational programmes that keep both current.