Annex 5 Was Written for a Car. Your Fleet Isn't One.

Annex 5 Was Written for a Car. Your Fleet Isn't One.

Open UN R155's threat catalog and you'll find seven categories, sixty-nine attack vectors, and not a single line that distinguishes a passenger sedan from a forty-tonne artic or a city bus carrying eighty people. That's not an oversight buried in the footnotes — it's the whole document. Category M, N, and O vehicles all get assessed against the same list.

During a recent TARA session for our city bus platform, we hit this exact wall. Annex 5's network isolation mitigation — M11, keep every third-party device off the core control network — reads fine on paper. Then you meet ITxPT. Public transport authorities increasingly mandate it as the open architecture for bus ICT, and it exists precisely so ticketing systems, telematics boxes, and passenger information displays from different vendors can sit on the same Ethernet backbone without the OEM gatekeeping every connection. Lock that backbone down the way M11 wants, and you've just made your own bus non-compliant with the tender requirements that got it purchased in the first place. Annex 5 assumes a closed vehicle. A modern city bus, increasingly, is not one.

Here's the part that should bother anyone running TARA on a commercial vehicle program. Passenger cars mostly still run proprietary CAN — every OEM builds its own message set, its own signal definitions, its own little walled garden that at least makes reverse-engineering an attacker's first job. Heavy vehicles don't have that luxury, and honestly, they never asked for it. SAE J1939 is an open, published standard. The parameter group numbers are documented. The message structure is the same whether the ECU came from a supplier in Stuttgart or one three buildings down from yours. Standardization is exactly why fleets can mix components from different manufacturers and still run a coherent driveline — and it's exactly why an attack chain built against one J1939 network tends to transfer to the next one with very little modification.

This isn't hypothetical. In 2016, a team at the University of Michigan took a Class 8 semi-tractor and a school bus, both running standard J1939, and showed they could send messages that disabled the engine brake and manipulated instrument readings while the vehicle was moving. Two completely different vehicle types, same protocol, same class of attack. NMFTA has been making a related point for years: fleet homogeneity — thousands of near-identical trucks sharing the same supplier components across model years — turns a single vulnerability into a fleet-wide one. Annex 5's "communication channels" category talks about spoofed messages and malicious CAN traffic in the abstract. It does not tell you that a J1939 broadcast bus has no source authentication built in by design, or that the same PGN means the same thing on a competitor's truck.

So what does a commercial-vehicle TARA actually need that a generic Annex 5 walkthrough won't give you?

Start with the diagnostic and telematics boundary, not the in-vehicle bus. Fleet operators plug third-party dongles into the same port service technicians use, and that port sits on the same J1939 backbone that carries brake and powertrain commands — there is rarely a gateway doing the isolating work that a central gateway architecture does on a modern passenger platform. Then look at supplier commonality across your own vehicle family, not just within one type. If your chassis and three competitors' chassis share an ECU from the same tier-one, a threat scenario against that component isn't a single-vehicle-type risk anymore, and your TARA should say so explicitly, not bury it under "external connectivity."

There's a similar blind spot with O-category trailers. R155 pulls O3 and O4 into scope, but a trailer is often a separate type-approval object, built by a different manufacturer than the tractor, exchanging brake and lighting data over the tractor-trailer interface. Whoever writes the trailer's TARA is rarely the same team that wrote the tractor's, and that interface is exactly the kind of seam Annex 5's category boundaries don't handle well.

And then there's the question nobody wants to own: multistage builds. A bus built on a base chassis with a separate body manufacturer creates a threat boundary that doesn't map cleanly onto Annex 5 at all — whose TARA covers the interface between chassis CAN and body-builder-added electronics? R155 covers M2 and M3 vehicles explicitly. It says very little about who does the threat analysis when two separate legal entities build one type-approved vehicle.

None of this means Annex 5 is wrong. It's a floor, not a ceiling, and treating it as a checklist rather than a starting hypothesis is where commercial vehicle programs get into trouble at audit time. A technical service reviewing your submission package is going to ask why your threat model looks identical to a passenger car OEM's when your architecture, your protocol, your service life, and your ownership model are all different. "We followed Annex 5" is not going to be a satisfying answer, and it shouldn't be.

Research interest in commercial vehicle security is finally catching up — the CyberTruck Challenge exists now as a hacking competition built specifically around heavy vehicles, which it didn't a decade ago. But most of the published research, the tooling, the threat intelligence feeds, still assume a passenger car target. Until that changes, the extra work of adapting TARA for J1939 architectures, fleet-scale supplier commonality, and multistage builds falls on whoever is running cybersecurity for a truck or bus program. Which, if you're reading this, might be you.

The next Annex 5 revision cycle is the moment to raise this. Waiting for someone else to write the commercial-vehicle threat catalog first is a plan, technically — just not a very good one.