UN R155 Supplier Requirements: The Cybersecurity Evidence an OEM Can Request

A European vehicle manufacturer asks a Tier 1 supplier for cybersecurity evidence covering a gateway ECU. The supplier already has a TARA spreadsheet, a list of security controls and several test reports. The problem is not the absence of documents. The problem is proving that the records describe the same product revision and support the same risk decisions.

UN Regulation No. 155 addresses cybersecurity and the cybersecurity management system for relevant vehicle type approvals. Its requirements fall on the vehicle manufacturer in the approval process. The manufacturer must demonstrate how it manages dependencies involving contracted suppliers and service providers. ¹ A supplier can face detailed evidence demands through engineering agreements and procurement contracts.

Understand whose legal duty is being assessed

Do not describe every Tier 1 as directly holding a vehicle manufacturer's UN R155 type-approval obligation. The regulation places duties on the manufacturer for its cybersecurity management system and vehicle type. Suppliers contribute information and activities that the manufacturer needs to meet those duties.

That distinction affects contracts, evidence ownership and the questions asked at a supplier review. The relevant request concerns the product, interface and contribution to the vehicle system, not a generic certificate of “UN R155 compliance”.

Prepare evidence that answers a specific question

A supplier evidence package should answer five practical questions. What function is supplied? What interfaces expose it to attacks? What damage can follow loss of an asset? Which threats and attack paths were assessed? Which controls and decisions address the resulting risks?

A TARA becomes useful here only when the records connect. A control called “secure boot” has limited evidential value without its target ECU, defined security goal and current implementation state. A penetration test has limited scope outside the software and hardware version it examined.

Reviewers need dates, revisions, ownership and residual gaps. They need to distinguish a supplier claim from a verified engineering result.

Create a traceable supplier evidence package

Start with the ECU item definition and interface inventory. Include network and diagnostic interfaces that carry the relevant data or services. Record the cybersecurity assets and their security properties.

Next, link damage scenarios to the assets. Attach threat scenarios and attack paths with rated feasibility. Record treatment decisions, cybersecurity goals, controls and validation evidence. Preserve any open risks and assumptions that depend on the OEM's vehicle architecture.

For shared interfaces, mark responsibility clearly. A supplier can provide evidence of its ECU's authorization checks. The OEM can control the gateway policy that governs access to that ECU. The assessment should not silently attribute the gateway control to the supplier.

Handle changes during the vehicle program

The evidence package cannot remain static after a hardware or firmware revision. A new diagnostic routine can alter attack reachability. A new network connection can expose an additional entry point. A component vulnerability can trigger further analysis.

Record the changed artifact, affected assumptions and review outcome. Send the OEM a versioned change summary rather than a new spreadsheet with no reliable history. A controlled revision helps both parties understand whether an approved risk treatment still applies.

UN R155 includes lifecycle risk management and ongoing monitoring expectations. Its supplier-dependency provisions sit within that broader process. ¹

Separate cybersecurity evidence from unsupported promises

A supplier should not claim that ISO/SAE 21434 certification or one TARA report automatically satisfies a vehicle approval. ISO/SAE 21434 provides cybersecurity engineering requirements for vehicle electrical and electronic systems. The OEM and approval authority assess the actual applicability of regulatory obligations. ²

Contracts can ask for additional forms of evidence. The correct response is to trace each requested item to an accountable work product, not to copy a generic compliance statement.

Reduce the cost of answering repeated OEM requests

Suppliers often serve several customers. The same ECU platform can require customer-specific boundaries, interfaces or restrictions. Store a controlled baseline TARA and create reviewed variants for each program. Preserve the differences rather than merging all assumptions into one master assessment.

QuickTARA supports product revisions and controlled copies for customer departments, with connected risk, control and report records. Evaluate that workflow using one baseline ECU and one OEM-specific variant.

Book a QuickTARA supplier-evidence demonstration. Bring one anonymized customer evidence request and ask to trace every requested claim to its source record.

Frequently asked questions

Does UN R155 directly require every supplier to obtain its own CSMS certificate?

The regulation's vehicle type-approval and CSMS obligations concern the vehicle manufacturer. Supplier contracts and customer processes can introduce related evidence requirements. Check the agreement and applicable approval scope. ¹

Can one generic TARA satisfy every OEM program?

Not automatically. Vehicle context, interfaces, use conditions and customer responsibilities change the assessment. Reuse a reviewed baseline, then document program-specific differences.