UN R155 and the supply chain: flow-down to Tier-1s and Tier-2s

The problem R155 flow-down solves

Supply-chain flow-down is how UN R155 obligations reach the parts of the vehicle the OEM did not build. The regulation places the type approval on the vehicle manufacturer. But almost no OEM writes its own connected stack end to end — the vehicle is assembled from Tier-1 and Tier-2 components, each with its own software and its own vulnerabilities. That produces a structural asymmetry: accountability sits at the top, capability is spread across the chain.

R155 resolves this by requiring the OEM's CSMS to manage supplier-related risks — to impose cyber security requirements on suppliers and to verify, with evidence, that those requirements were met. Suppliers are not directly type-approved. Their obligations flow down from the OEM, contractually and technically. This is a core process of any working CSMS, not an add-on, as we set out in what is a CSMS.

Accountability does not delegate

The single most important principle is that the OEM's accountability to the approval authority does not leave the OEM. A vulnerability three tiers down is still the OEM's problem to manage. You can share the work; you cannot outsource the accountability.

That is uncomfortable but clarifying. It means the OEM cannot accept a supplier's assurance at face value and consider the box ticked. If the assessor asks for evidence that a component meets its requirements, "the supplier told us it does" is not evidence. The OEM needs the actual records — and needs the right to obtain them — which is exactly what flow-down has to secure in advance.

The cybersecurity interface agreement

The instrument that makes flow-down concrete comes from ISO/SAE 21434: the cybersecurity interface agreement (CIA). It divides cyber security responsibilities between two parties — who performs which activities, what evidence each provides, and how information is exchanged across the boundary.

Without a CIA, flow-down is a vague expectation. With one, it is an auditable split of work. The agreement is where you write down that the supplier will perform its own TARA on the component, will provide verification records, will report vulnerabilities discovered after delivery, and will support the OEM's monitoring obligations. It also records what the OEM provides in return — the item definition, the assumptions of use, the requirements the component must meet.

Aspect	OEM responsibility	Supplier responsibility
Requirements	Define and impose cyber security requirements	Meet them and confirm scope
Analysis	Vehicle-level TARA	Component-level TARA and assumptions
Evidence	Assemble the type-approval dossier	Provide verification and test records
Vulnerabilities	Manage fleet-level risk and response	Report and support fixes post-delivery
Interface	Own the CIA and the overall approval	Fulfil the CIA obligations

The exact division shifts with the commercial relationship and how much of the design each party owns, but every boundary in the chain needs one of these agreements — OEM to Tier-1, and Tier-1 to Tier-2.

Flow-down is requirements and evidence

It helps to see flow-down as two currents moving in opposite directions. Requirements flow down the chain: the OEM's cyber security requirements reach the Tier-1, which flows the relevant parts to the Tier-2. Evidence flows back up: the Tier-2 produces verification records that the Tier-1 integrates and passes to the OEM, who assembles them into the dossier the assessor opens.

Both currents have to work. Requirements that flow down but produce no evidence flowing back leave the OEM unable to prove anything. Evidence collected without clear requirements to test against is noise. The relationship between the regulation and the engineering standard that structures this is worth reading in ISO/SAE 21434 vs UN R155.

Where flow-down breaks at assessment

Weak supplier flow-down is one of the recurring reasons a first CSMS assessment stalls, a pattern we cover in the gaps that fail a first UN R155 CSMS assessment. The failures are predictable.

The most common is the evidence gap: requirements were sent to suppliers, but no records came back, or the OEM never verified what it received. Another is the missing agreement: work was assumed to be split a certain way, but nothing recorded who owned which activity, so at assessment neither party can show it was done. A third is the stale interface: an agreement exists but was never updated when the component changed, so it describes a division of work that no longer matches reality. A fourth is depth: the OEM manages its Tier-1s but has no visibility into the Tier-2s beneath them, where the actual vulnerable code may live.

Each of these is avoidable, but only if flow-down is treated as an ongoing process with records — not a clause dropped into a purchase order at the start and never revisited.

The AutoSifu view

Supplier flow-down is where a CSMS most often turns out to be thinner than it looks — agreements missing, evidence never collected, Tier-2s invisible. AutoSifu builds flow-down as one route: the interface agreements, the requirements and the evidence pipeline back up the chain, assembled into a dossier that holds together at assessment — with our partner CIRT, a named test agency, engaged from the start, so the chain of evidence is built to be opened rather than explained after the fact.