Cybersecurity Interface Agreements with German OEMs: The Supplier’s Evidence Checklist

When an OEM nominates a supplier for a security-relevant component, the cybersecurity interface agreement (CIA) arrives early and the evidence requests follow for the rest of the programme. Our CIA template and negotiation guide covers how to structure and negotiate the agreement itself. This post covers the other half: what OEMs in Germany and the wider EU commonly ask suppliers to deliver once it is signed, what a defensible answer looks like, and the ISO/SAE 21434 clause each request traces back to.

Two caveats. Every OEM writes its own requirements; this post describes common patterns, not any named manufacturer’s terms. And it is process guidance from the engineering side, not legal advice on contract wording.

Why the Requests Look the Way They Do

UNECE R155 approves the vehicle manufacturer, not the supplier. But it pulls the supplier’s work into the manufacturer’s case. Paragraph 7.2.2.5 requires the manufacturer to demonstrate how its cybersecurity management system manages dependencies with contracted suppliers and service providers, and paragraph 7.3.2 requires it to identify and manage supplier-related risks for the vehicle type being approved. In Germany that case is assessed by technical services for the KBA — see how KBA cybersecurity type approval works with technical services. The OEM therefore needs supplier evidence it can put in front of an assessor, and it collects it through ISO/SAE 21434 Clause 7, under which distributed cybersecurity activities are specified in a cybersecurity interface agreement — work product WP-07-01.

German OEMs and suppliers also share a vocabulary for this. The VDA has published a recommendation for a Cyber Security Interface Agreement (CSIA) that walks the ISO/SAE 21434 work products with a RASI matrix — who is responsible, who approves, who supports, who is informed — and an exchange rule for each. For most work products the rule is a short version as a deliverable and the full version at the supplier’s location; the interface agreement itself and the cybersecurity specifications are delivered in full. If you have read it, OEM templates will look familiar.

The Supplier Evidence Checklist

The table is the list we prepare against before a nomination. Clause numbers refer to ISO/SAE 21434:2021. Not every OEM asks for every row, and the depth expected scales with the component’s exposure and any CAL assigned.

Capability Evidence Before Award

The first request often arrives before the CIA does. Clause 7 expects the customer to evaluate whether a supplier can perform its share of the cybersecurity work, and OEMs do this through questionnaires, document reviews or audits of the supplier’s organisational cybersecurity management. Have a summary of your Clause 5 evidence ready — policy, roles, competence and awareness management, tool management, the latest organisational audit — together with anonymised examples of past work products, such as a TARA summary or a verification report. Where an OEM audits, ISO/PAS 5112 sets out guidelines for auditing cybersecurity engineering, so preparing against it avoids surprises. List only certificates you actually hold, and be clear about what they show: a management-system certificate speaks to the organisation, not to the conformity of the component.

Summary at the OEM, Full at Your Site

Graded evidence packaging solves two problems at once: the OEM gets enough to argue its case to the technical service, and the supplier keeps proprietary design detail — algorithms, HSM integration, test tooling — under its own control. It only works if the summary is demonstrably the visible face of the full work product. Give every summary the identifier and version of the full document it summarises, agree in the CIA how a review of the full version happens (on site, remote screen-share, or a third-party assessor), and make sure the full version actually exists when the summary ships.

TARA Extracts, Assumptions and Claims

The OEM owns the item- and vehicle-level TARA. A supplier typically performs a component TARA — often out of context, as a generic analysis of the delivered component — and uses it to show that the OEM’s cybersecurity goals and requirements are met. The extract the OEM asks for should therefore lead with the parts that interact with its architecture: the assumptions you made about the operating environment, the threat scenarios at its interfaces, the risk-treatment decisions, and the cybersecurity claims you hand back — for example, that a gateway upstream filters diagnostic traffic. Every claim is a requirement on the OEM; it must be stated, and accepted, before it can be relied on. Where the OEM uses the informative CAL scheme of Annex E, show how your verification depth and independence follow from the assigned level.

Verification and Penetration-Test Evidence

Requests here split into the integration and verification specification, the verification reports, and — for connected or security-relevant components — a penetration-test report. The VDA recommendation lists requirements tests, fuzz testing of vehicle interfaces, penetration tests, a vulnerability report and hardware and software bill-of-materials information among typical Tier-1 verification deliverables, and notes that the OEM may run its own penetration test as part of validation. A report that holds up has a scope derived from the TARA, testing on production-representative hardware and software, each finding mapped to a threat scenario with a severity, retest evidence for fixes, and a documented treatment decision for anything still open. The R155 Annex 5 penetration testing checklist shows how to lay out coverage so the same report serves the OEM’s type-approval evidence.

Vulnerabilities, Incidents and the SBOM

These are the commitments that run for the life of the vehicle, and the place where vague wording fails first. Replace “without undue delay” with clocks: time to acknowledge a report, to triage, to issue an advisory to the OEM, and to deliver a fix or mitigation, each tied to severity. Remember why the OEM needs speed — R155 obliges it to monitor and respond to cyber-attacks and vulnerabilities, and to report the outcome of its monitoring to the approval authority or technical service at least once a year under paragraph 7.4.1 — and that an incident on your own enterprise systems may also start your NIS2 reporting clock; our NIS2UmsuCG checklist for automotive suppliers covers that side. For the SBOM, agree format, granularity (per ECU software release, including third-party and open-source components), delivery trigger and confidentiality once, in the CIA. Flow the same clocks down to sub-suppliers, or your own commitments depend on advisories you cannot force.

End of Cybersecurity Support

Clause 14 of ISO/SAE 21434 expects procedures for communicating the end of cybersecurity support, and OEMs ask for it because vehicles stay on the road long after series production ends. Offer a date or a defined trigger, say what stops afterwards — vulnerability analysis, updates — and how and when you will tell the OEM. The VDA recommendation adds a useful reciprocal clause: both parties inform each other of changes in their ability to support, for example when a silicon vendor ends support for a chip family.

TISAX and the Information-Sharing Rules

Before an OEM shares specifications, it commonly requires a TISAX label at the assessment level and objectives it specifies. TISAX is governed by the ENX Association and based on the VDA ISA catalogue; per ENX, labels are valid for three years and results are shared with selected partners through the ENX portal rather than published. A label covers the site’s handling of information and, where relevant, prototypes — not product cybersecurity — so it sits beside the CIA, not inside it. Align the CIA’s information-sharing section (channels, classification, retention, disposal) with what the label covers; our TISAX guide for automotive suppliers explains assessment levels and labels.

Five Habits That Keep the Pack Defensible

• One identifier scheme. Every deliverable carries the ISO/SAE 21434 work-product reference, a version and the ID of the full document it summarises.
• A live responsibility matrix. Update the RASI or RASIC rows when the architecture, a sub-supplier or the programme phase changes, not at the annual review.
• Cascade before you sign. Check that every clock and audit right you accept can be flowed down to Tier-2 silicon and software vendors.
• Claims in writing.Every assumption about the OEM’s environment is listed, owned and accepted.
• Audit-ready by default. If an OEM or its assessor follows ISO/PAS 5112 audit guidelines, the evidence for your organisational processes should already be indexed.

For a worked example of the workflow on a connected-ECU programme, see the Tier-1 ECU cybersecurity interface agreement scenario.

Take-Aways

The evidence an OEM requests under a CIA is predictable because it follows ISO/SAE 21434 and the OEM’s own R155 obligations. Prepare the pack before nomination, deliver summaries that trace to full work products kept at your site, put numbers on every vulnerability, incident and support commitment, and keep TISAX and NIS2 obligations consistent with the CIA without merging them into it. That turns each request from a scramble into a retrieval.

Primary sources: VDA CSIA recommendation (ISO/SAE 21434); UN Regulation No 155 (EUR-Lex); ISO/SAE 21434:2021; ISO/PAS 5112:2022; ENX TISAX.

This checklist describes common industry patterns and is not legal advice; it does not reproduce the terms of any named manufacturer. Agnile Technologies prepares ISO/SAE 21434 work products, TARA and penetration-test evidence for automotive suppliers and OEMs.