Tier-2 → Tier-1 → OEM Cybersecurity Evidence-Handover Playbook

Most automotive cybersecurity guidance is written from the OEM’s perspective. The OEM authors a CSMS, runs a TARA per vehicle type, owns the type-approval submission, and treats the supply chain as a black box that emits evidence on request.

The reality on the ground is messier. A modern vehicle ships with components from 5–15 Tier-1 suppliers, who themselves source firmware, modules, and software stacks from a long tail of Tier-2 vendors — semiconductor companies, RTOS vendors, AUTOSAR stack providers, infotainment middleware, V2X stacks, ADAS perception libraries, HSM module makers, and increasingly an open-source dependency graph that runs hundreds of layers deep.

Cybersecurity evidence has to flow up that chain in a defensible form. ISO/SAE 21434 Clause 7 (“Distributed Cybersecurity Activities”) defines the principle but not the format. UNECE R155 demands that the OEM demonstrate supply-chain coverage but does not standardize the interface. EU CRA Article 13 imposes vulnerability-handling obligations on every level of the chain. GB 44495 adds a Chinese-specific overlay.

This playbook is for the engineers who actually have to make that handover work — from both ends of the chain. It defines who owns what, what artifacts must travel, in what format, and what to do when the chain breaks down.

The handover problem in plain terms

An OEM signs a cybersecurity interface agreement with a Tier-1. The agreement says, in legal language, that the Tier-1 will provide cybersecurity evidence covering the components it integrates. Six months into the program, the OEM’s type-approval lead asks for the TARA covering the brake-system ECU. The Tier-1 forwards a 47-page PDF that includes:

• Brake-system threat scenarios and risk ratings — written in the Tier-1’s internal threat-ID format.
• An “assumption-of-use” appendix saying that the OEM is responsible for downstream ECUs the brake controller talks to.
• A note that the underlying RTOS came from a Tier-2 vendor, who issued a security argument for the kernel that the Tier-1 has “reviewed and accepted.”
• An SBOM in CycloneDX 1.4 format with 312 components.

The OEM’s type-approval lead now has to:

• Reconcile the Tier-1’s threat IDs against the OEM’s vehicle-level TARA.
• Validate the “assumption-of-use” against the actual integration architecture.
• Decide whether “reviewed and accepted” from the Tier-1 is enough audit-evidence for the Tier-2 RTOS, or whether to chase the original Tier-2 security argument.
• Map the 312-component SBOM against the OEM’s NVD/GHSA monitoring — and find that 14 components are not currently tracked.

This is one Tier-1, one ECU, one type-approval submission. Multiply by 5–15 Tier-1s and 50–200 ECUs, and the handover problem is the single largest source of evidence drift in automotive cybersecurity programs.

What each link in the chain owns

The cleanest way to think about handover is to define ownership boundaries at each tier — what each role must author, must forward, and can rely on the next tier to handle.

Tier-2 ownership

Tier-2 is the component, module, or software vendor whose product is incorporated into a Tier-1 system. Examples: a microcontroller vendor supplying an MCU + bootrom, an RTOS vendor supplying a kernel + BSP, a stack vendor supplying an AUTOSAR Adaptive runtime, a crypto library vendor, an OSS foundation publishing a critical dependency.

Tier-2 owns:

• Component-level cybersecurity case — an argument structured around the component’s own asset boundaries, expected use, and security claims.
• Component SBOM — if the Tier-2 product is itself a software stack, a complete SBOM down to its own dependencies.
• Vulnerability handling commitment — a defined SLA for vulnerability disclosure, fix availability, and end-of-support date for the component.
• Assumption-of-use document — an explicit list of integration assumptions that the Tier-1 must satisfy for the component-level claims to hold (e.g. “memory protection unit must be configured before secure-boot completion”, “HSM requires write-once provisioning of root keys before first boot”).
• Component test evidence — reports of penetration testing, fuzz testing, and any standards-aligned validation (e.g. CC EAL, FIPS 140-3) that the Tier-1 can rely on.

Tier-2 does not own:

• Vehicle-level threat scenarios (no visibility into deployment context).
• Integration testing in the Tier-1 system.
• Field monitoring of incidents involving its component (must cooperate via disclosure, but cannot operate the SOC).

Tier-1 ownership

Tier-1 is the system integrator. Examples: a brake controller integrator combining MCU + actuators + firmware, a domain controller vendor combining SoC + AUTOSAR + applications, an HMI vendor combining the QNX/Linux stack + Qt + the OEM’s middleware.

Tier-1 owns:

• System-level TARA — threat scenarios at the integrated-system level, accepting Tier-2 component-level claims and adding integration-specific threats.
• Tier-2 evidence aggregation — a coherent argument that Tier-2 cybersecurity cases plus Tier-1 system controls combine to mitigate the system-level risks.
• Verification of Tier-2 assumption-of-use claims — explicit verification that each Tier-2 assumption is met by the Tier-1 integration.
• Aggregated SBOM — combining Tier-2 SBOMs with Tier-1-authored software, yielding the integrated-system SBOM.
• Integration testing — penetration testing at the system level, including interactions between Tier-2 components.
• Disclosure forwarding — a process to forward Tier-2 vulnerability advisories to the OEM with integration impact analysis.
• Field-incident response — participating in incident response coordination with the OEM, including the Tier-2 if the root cause is at component level.

Tier-1 does not own:

• Vehicle-level threat scenarios spanning multiple ECUs (only the OEM has the full architecture).
• The CSMS audit (the OEM is audited; Tier-1 supports).
• Type-approval submission.

OEM ownership

OEM owns:

• Vehicle-level TARA — threat scenarios at the whole-vehicle level, integrating Tier-1 system-level claims and adding cross-system threats (e.g. attack chains spanning the IVI + telematics + brake-system ECUs).
• CSMS — the organizational cybersecurity management system audited by the type-approval body.
• Supplier governance — framework agreements with all Tier-1s, with cybersecurity interface agreements that flow down to Tier-2 obligations.
• Type-approval submission — the formal cybersecurity argument submitted to the regulator.
• Field SOC — vehicle-fleet monitoring and incident response coordination.
• Vulnerability handling for the vehicle population — the OEM owns the OTA infrastructure, the per-VIN deployment cadence, and the regulator-facing reporting.

The artifacts that must travel up the chain

For the handover to be auditable, certain artifacts must move from Tier-2 to Tier-1 to OEM in a defined format. The minimum set:

Artifact	Tier-2 owes Tier-1	Tier-1 owes OEM	Recommended format
SBOM	Component SBOM with all 3rd-party dependencies, license, version, supplier	Aggregated system SBOM (Tier-2 SBOMs merged with Tier-1 authored software)	CycloneDX 1.6 (preferred) or SPDX 3.0 (SPDX 2.3 still widely deployed)
VEX statements	Per-CVE assertions: affected, not_affected (with justification), under_investigation, fixed	Aggregated and annotated VEX covering the integrated system	CycloneDX 1.6 (CDX-VEX), CSAF 2.0 with the csaf_vex profile, or OpenVEX 0.2.0
Cybersecurity case / argument	Component-level argument: claims, evidence, residual risk	System-level argument: aggregating Tier-2 claims into an integrated case	Structured assurance case (GSN-style) + source TARA artifact
Assumption of use	Explicit list of integration preconditions for component claims	Explicit list of OEM-side preconditions for system claims	Plain text, numbered, machine-readable annotations preferred
Test evidence	Component pen-test, fuzz reports, formal verification (where applicable)	Integration test reports, system-level pen-test, regression trail	SARIF 2.1.0 (machine-readable findings) + signed PDF report
Vulnerability handling SLA	Disclosure window, fix-availability SLA, end-of-support date	Aggregated SLA matrix; OEM-facing escalation path	Contract clause + machine-readable vendor metadata
Threat ID mapping	Internal Tier-2 threat IDs mapped to ISO 21434 / R155 / GB 44495 catalog IDs	System-level Tier-1 threats mapped against vehicle-level OEM threat catalog	JSON lookup table or CycloneDX threat extension
Incident notification template	Pre-agreed format for vulnerability disclosure to Tier-1	Pre-agreed format for incident escalation to OEM	CSAF advisory format + email/API hand-off

The standard interface formats — in 2026

One reason handover is fragile is that there is no single standardized interchange format. There are several, each authoritative in some part of the chain.

CycloneDX 1.6 + VEX

The current industry-leading SBOM exchange format (CycloneDX 1.6, June 2024). Compared to SPDX, CycloneDX has stronger support for VEX assertions, automotive-specific metadata extensions, and component dependency graphs. The 1.4/1.5/1.6 line refined first-class VEX-component coupling that automotive cybersecurity teams need to forward Tier-2 vulnerability stances cleanly; 1.6 is the current target for new programs, with 1.5 still widely deployed.

SPDX 3.0 (with 2.3 in the field)

Strong in open-source license tracking. SPDX 3.0 (released April 2024) added the “Security Profile” that aligns SPDX with the cybersecurity use case. Note that ISO/IEC 5962:2021 covers SPDX 2.2.1, with a 3.0-aligned ISO revision in progress; SPDX 2.3 remains widely deployed and is acceptable when both ends of the handover support it. Where the Tier-2 is OSS-heavy, SPDX is often the native format; conversion to CycloneDX for automotive handover is a routine step.

CSAF 2.0 (Common Security Advisory Framework)

The format for vulnerability advisories. When a Tier-2 issues a security advisory, CSAF is the OASIS-standardized JSON format that downstream tooling can ingest automatically. The automotive industry is rapidly converging on CSAF for advisory exchange between Tier-2s and Tier-1s, and Tier-1s and OEMs.

SARIF 2.1.0

Static Analysis Results Interchange Format — not specifically a cybersecurity format, but the standard way to forward findings from analysis tools (SAST, DAST, fuzz harnesses) up the chain. Increasingly used as the “test evidence” serialization that survives across tool ecosystems.

ReqIF 1.2

For requirements-engineering handover. ALM/MBSE tools like DOORS, Polarion, Codebeamer, and PREEvision all support ReqIF import/export. The cybersecurity goals and requirements that the OEM passes down the chain to Tier-1s are typically forwarded as ReqIF, not as PDF.

STIX 2.1 (automotive extensions in flight)

For threat intelligence exchange. Automotive-specific custom properties (under STIX’s standard x_ namespace convention) are emerging via Auto-ISAC working groups and the SAE J3061-successor work; treat them as pre-publication conventions rather than a settled namespace. Used primarily for forward-deployed-fleet threat sharing rather than design-time TARA, but increasingly relevant for the post-production handover loop.

The cybersecurity interface argument: what it is and how to build one

The cybersecurity case at each level is structured around an interface argument that ties the next-level-down claims into the current-level claims. ISO/SAE 21434 Clause 7.5 calls this the “cybersecurity interface argument”.

Anatomy of an interface argument

A workable interface argument has four explicit sections:

1. Scope. What component or sub-system this argument covers, with explicit asset boundaries.
2. Inherited claims. What the next-level-down (Tier-2 to Tier-1, Tier-1 to OEM) is asserting, plus the evidence references for those assertions.
3. Verifications. What the receiving level has done to verify each inherited claim — could be inspection, test, third-party attestation, or argued rationale.
4. Assumptions of use. What the receiving level commits to, in exchange for the inherited claims being valid.

If any of these four are missing or sloppy, the audit trail is broken. The most common failure mode is silently absorbed claims — Tier-1 says “the Tier-2 component is secure” without listing the Tier-2 claims, the verification, or the assumptions. An auditor cannot trace evidence; the OEM’s cybersecurity case has a gap.

Example: HSM module from Tier-2 to Tier-1

A Tier-2 vendor supplies a hardware security module to a Tier-1 brake-controller integrator. The Tier-1’s interface argument for this component might read:

1. Scope. HSM module (vendor part number XYZ-1234, firmware revision 4.2.1) integrated as the secure-boot root-of-trust for the brake-controller ECU.
2. Inherited claims (from Tier-2 cybersecurity case).
   • HSM enforces secure boot per FIPS 140-3 Level 2.
   • Root keys are write-once, provisioned at the Tier-2 production line.
   • Side-channel resistance per the vendor’s pen-test report (link to artifact).
   • Firmware updates require signature verification using the OEM-controlled key.
   • End-of-support date: 2032-12-31.
3. Verifications by Tier-1.
   • Reviewed FIPS 140-3 certificate at Tier-1 incoming inspection.
   • Validated root-key provisioning evidence per Tier-2 production records.
   • Re-tested side-channel resistance in the Tier-1 integration with the actual application; results in test report TR-BRK-2026-04-15.
   • End-to-end secure-boot path tested under the Tier-1 application and validated against Annex F threat scenarios THRT-BRK-001 through THRT-BRK-008.
4. Assumptions of use (Tier-1 commits to).
   • HSM physical access controls per Tier-2 mechanical integration guide section 4.2.
   • HSM communication only via the protected SPI bus — verified by architectural inspection.
   • Memory protection unit configured before secure-boot completion — verified in startup-sequence test.
   • Firmware-update key rotation per OEM key-management procedure (passed through to OEM’s assumption).

The OEM, receiving this from the Tier-1, can either accept the argument (writing it into the vehicle-level case) or push back on specific claims with a request for additional evidence. Either outcome is auditable — which is the entire point.

What to do when the chain breaks down

Five common breakdown modes, with practical responses.

1. Tier-2 refuses to provide a cybersecurity case

This still happens, especially with smaller commodity-component vendors and some legacy semiconductor products that pre-date ISO/SAE 21434. The Tier-1 has three responses, in order of preference:

1. Push the Tier-2 to issue at minimum a component datasheet with security-relevant claims, even if not formatted as an ISO 21434 cybersecurity case. Then the Tier-1 authors the interface argument over those claims.
2. If even that fails, the Tier-1 must treat the component as untrusted in its TARA, with conservative threat assumptions. Risk assessment must explicitly assume the component could be compromised.
3. Last resort: replace the Tier-2. As the regulatory burden compounds, the cost of carrying a non-cooperative Tier-2 component grows; replacement becomes economically rational faster than it used to be.

2. Inherited claims have inconsistent threat-ID schemes

Tier-2 uses ISO 21434 IDs, Tier-1 uses an internal taxonomy, OEM uses a vehicle-class-specific catalog. Mapping each level into the next is mechanical but error-prone.

Best practice: maintain a catalog overlay at the OEM level that lets the same threat scenario be rendered in any of the catalogs in scope (ISO 21434 + R155 Annex 5 + GB 44495 Annex A). Tools that ship with multi-catalog overlays do this for you. Without tool support, this is engineer-weeks per type approval — and a regular source of drift between submissions.

3. Tier-2 vulnerability disclosure arrives without VEX

A Tier-2 issues a security advisory: “CVE-2026-12345 affects component XYZ versions 4.0–4.3.” The Tier-1 has to determine whether each integrated instance is affected, then forward to OEM, then OEM has to determine vehicle-population impact.

If the Tier-2 advisory does not include VEX statements, every level in the chain re-derives the same exploitability analysis. The fix is to require VEX in vulnerability-handling SLA contractually, and to push back on Tier-2s that issue bare CVE announcements without VEX.

4. SBOM levels disagree on component identity

Tier-2 SBOM lists OpenSSL 3.0.13. Tier-1 SBOM lists openssl 3.0.13-1.1 after a recompile. OEM SBOM lists openssl-fips 3.0.13 because it’s under the FIPS variant. Same library, three different identities — a vulnerability scanner sees three components and may miss the CVE on at least one.

The fix is to standardize on PURL (Package URL) identifiers across the chain. PURL gives a canonical name (pkg:generic/openssl@3.0.13) that survives recompiles and packaging variants. CycloneDX 1.6 includes PURL natively. SPDX 3.0 added it. If a Tier-2 SBOM lacks PURLs, push back.

5. End-of-support dates collide with vehicle lifecycle

A Tier-2 RTOS publishes an end-of-support date 5 years from now. The vehicle is in production for 7 years, with a 15-year service tail. The Tier-1 has accepted the Tier-2’s 5-year SLA without flagging the gap; the OEM only realizes years later that there’s a 10-year window with no Tier-2 vulnerability response.

The fix is to require end-of-support dates in the vendor metadata at incoming-inspection and reconcile against the program’s production + service window. Where the Tier-2 SLA is shorter than the vehicle lifecycle, the OEM and Tier-1 must explicitly plan for either a Tier-2 replacement, a long-tail support contract, or fork-and-maintain.

Practical contractual language

The cleanest interface agreements include the following clauses, in approximately this order:

1. Scope of cybersecurity activities — which deliverables this agreement covers (TARA, SBOM, vulnerability handling, incident response, test evidence).
2. Format and exchange schedule — CycloneDX 1.6 SBOM monthly, CSAF advisories within 72 hours of vendor disclosure, ISO 21434 cybersecurity case at every release.
3. Threat-ID alignment — the receiving party publishes its threat catalog; the supplying party maps deliverables to it.
4. Vulnerability-handling SLA — window for advisory issuance, window for fix availability, end-of-support date.
5. Disclosure protocol — named contact, CSAF format, escalation path, embargo handling.
6. Audit rights — receiving party reserves the right to audit cybersecurity activities; supplying party agrees to provide reasonable evidence.
7. Subcontractor flow-down — the supplier’s obligations flow down to its own suppliers (Tier-2 supplier flows to Tier-3 sub-suppliers).
8. Termination triggers — what happens if cybersecurity SLAs are repeatedly breached.

Most automotive OEMs have versions of these clauses in their cybersecurity interface agreements, but the language is often vague (“industry-standard format”) where it should be specific (“CycloneDX 1.6 with PURL identifiers and CDXVEX for affected/not_affected assertions”). The vague version produces vague evidence; the specific version produces clean handover.

What “good” looks like

An OEM with a working handover discipline can answer five questions in minutes, not weeks:

1. What components are in vehicle X, at what version, from what supplier? — Answer: aggregated SBOM by VIN.
2. For CVE Y published yesterday, which vehicles are affected? — Answer: VEX correlation across the SBOM.
3. What is each affected supplier’s SLA window for fix availability? — Answer: vendor metadata.
4. What threat scenarios reference component Z? — Answer: TARA query against the asset-threat graph.
5. Which Tier-2 components are within 12 months of end-of-support and require lifecycle planning? — Answer: vendor metadata report.

An OEM that cannot answer these in minutes has either a tooling gap, a handover-discipline gap, or both. Closing the discipline gap usually requires upgrading the contractual interface (specifying formats), the operational handoff (machine-readable artifacts, not PDF dumps), and the platform that aggregates evidence across tiers.

Key takeaways

1. The cybersecurity supply chain is real and getting more regulated. EU CRA Article 13, R155 Clause 7, ISO 21434 Clause 7.5, and GB 44495 supplier-governance expectations stack up; sloppy handover is now a compliance liability, not just a friction tax.
2. Each tier owns specific artifacts; clear ownership boundaries prevent “silently absorbed” claims that break audit trails.
3. Standardize on machine-readable interchange formats: CycloneDX 1.6 + VEX, CSAF 2.0, SARIF 2.1.0, ReqIF 1.2. PURL identifiers for components.
4. Build interface arguments with explicit Scope / Inherited Claims / Verifications / Assumptions of Use sections at every tier transition.
5. Specify formats in contracts. “Industry-standard” is too vague; “CycloneDX 1.6 with PURL + CDXVEX” is auditable.
6. Five common breakdown modes are predictable: non-cooperating Tier-2, inconsistent threat IDs, missing VEX, SBOM identity drift, end-of-support / lifecycle mismatch. Each has a known fix; bake them into the SOP.

Further reading

• ISO/SAE 21434 TARA Step-by-Step Guide
• CycloneDX vs SPDX for Automotive SBOMs
• Automotive SBOM Management Best Practices
• The Automotive Supplier Cybersecurity Questionnaire
• OEM-Supplier Vulnerability Disclosure
• OEM-Supplier Incident Escalation
• EU CRA Conformity Assessment for Automotive Components
• GB 44495 vs UNECE R155