Skip to main content
Customer Case Study — Tier-1 Supplier

Inside a Real Tier-1 Cybersecurity Engineering Program

How a European Tier-1 supplier engineered ISO/SAE 21434 + UNECE R155 + GB 44495 evidence for four domain-controller ECUs on a single global B-segment EV SUV program — with ThreatZ as the single source of truth from architecture import through type-approval submission.

Contact Sales
4
Domain-controller ECUs in scope
14
Cross-ECU attack paths surfaced
23
Sub-tier suppliers SBOM-onboarded
0
Major findings at the 21434 process assessment

How we measure these →

Program at a Glance — ThreatZ Enterprise

European Tier-1 Supplier — 4 Domain-Controller ECUs, 1 Global EV SUV Program

Engineered to ISO/SAE 21434, UNECE R155, and GB 44495 from a single ThreatZ knowledge graph. Customer name and OEM identity withheld at the customer's request; all metrics below are extracted directly from the customer's ThreatZ tenant.

Vehicle
B-segment EV SUV
Global program — EU, China, ROW
OEM customer
Premium European OEM
Single OEM, multi-region SOP
Tier-1 scope
4 domain controllers
CGW · VDC · ADC · BMS
Compliance regimes
ISO/SAE 21434 · R155 · GB 44495
21434 process assessed at the Tier-1; the OEM holds the R155 CSMS certificate with KBA
Sub-tier suppliers
23 onboarded
SoC, OS, AUTOSAR stacks, V2X, sensors
Engineering team
22 engineers
4 cyber leads + 18 ECU embedded engineers
Project award
2024-Q2
ThreatZ adopted 2024-09
Start of production
2026-Q4 (target)
Type-approval submission 2026-Q2
E/E architecture in scope

A central gateway routes all backbone traffic between three domain controllers (vehicle, ADAS, body) and isolates the high-voltage battery domain over a private CAN-FD link. The Tier-1's scope covers all four ECUs plus the cellular, V2X, and high-power charging interfaces. Buses shown: Automotive Ethernet 1000BASE-T1 backbone (solid teal), CAN-FD (dashed grey), private CAN-FD HV-isolation link (dotted cyan).

E/E architecture diagram of the four domain controllers in scope Central Gateway connects to Vehicle Domain Controller, ADAS Domain Controller, and Battery Management System. External interfaces include 5G modem, V2X, sensors, and HV charging. Buses are Automotive Ethernet 1000BASE-T1, CAN-FD, and a private CAN-FD link to the BMS. 5G NR & C-V2X cellular Uu, PC5 sidelink Sensors 6× camera, 5× radar, 1× LiDAR Body & comfort doors / lights / HVAC / seats Central Gateway CGW · firewall, IDPS, OTA download 5G NR + C-V2X termination Vehicle Domain Controller VDC · chassis, body proxy, OTA orchestration QNX hypervisor + Ethernet switch fabric ADAS Controller ADC · L2+/L3 driving DRIVE Orin-class fusion Battery Management System BMS · HV pack, cell monitor, charge supervision private CAN-FD HV trust boundary HV charging port CCS (PLC) / GB/T (CAN) 1000BASE-T1 10GBASE-T1 (VDC sw.) body CAN-FD 5G / PC5 GMSL3 / radar / LiDAR Eth private CAN-FD (HV isolation) PLC + classic CAN
Automotive Ethernet (backbone) CAN-FD (general) CAN-FD private (HV isolation)
Tier-1 scope — the four ECUs above plus their cellular, V2X, sensor, and HV-charging interfaces. Body domain controller (top right) is supplied by another Tier-1 and consumed only via CAN-FD signals.
The challenge

The four domain controllers had to ship with a synchronised cybersecurity case to the OEM's CSMS auditor: a single TARA covering all four ECUs and their interactions, threat-driven security requirements traceable to test evidence, SBOM coverage of every binary across 23 sub-tier suppliers, and continuous CVE monitoring through SOP and into series production. The previous approach — a TARA spreadsheet per ECU plus a shared Polarion module for requirements — created four siloed views that missed cross-ECU attack chains and produced inconsistent evidence between the ISO/SAE 21434 audit and the R155 / GB 44495 type-approval packs.

The ThreatZ rollout

ThreatZ Enterprise was deployed eight weeks after architecture freeze. ARXML, DBC, and SysML XMI exports from the four ECU teams were imported in a single 3-day workshop, producing a unified system model with 1,840 signals across the four buses shown above. The TARA was performed once across all four ECUs together, with the AI-assist surfacing 14 cross-ECU attack paths the per-ECU TARAs had missed. Sub-tier SBOMs flowed in via the supplier portal in CycloneDX (preferred) or SPDX, normalised to a single internal representation. The same underlying knowledge graph generated three distinct evidence packs — ISO/SAE 21434 work-product set, UNECE R155 type-approval annex, and GB 44495 cybersecurity report — with section-by-section traceability.

The four ECUs — cybersecurity scope per controller

Each domain controller has its own TARA scope, but findings, threats, and security requirements are shared across all four through the ThreatZ knowledge graph.

ECU 1 of 4

Central Gateway

CGW · the only ECU with direct external connectivity

HW: octa-core ARM Cortex-A55 (S32G3-class) + HSE-B HSM + lockstep Cortex-M7 control core
SW: Linux Yocto on the application cluster + AUTOSAR Classic on the M7 (firewall, secure-boot, IDPS hooks)
Buses: 4-port 1000BASE-T1 switch + host MAC, 6× CAN-FD, 1× LIN, 5G NR + C-V2X PC5/Uu

Cybersecurity scope
  • External attack surface (cellular, C-V2X, OTA bootstrap)
  • VLAN / firewall policy on the in-built Ethernet switch
  • IDPS rules + V-SOC connector (telemetry to OEM VSOC per ISO 21434 §10)
  • Secure-boot chain, key custody, certificate revocation
Threats correlated
  • 72 distinct threats (12 critical, 28 high)
  • Anchors 8 of the 14 cross-ECU attack paths

ECU 2 of 4

Vehicle Domain Controller

VDC · chassis, body proxy, OTA orchestration

HW: quad-core ARM Cortex-A78AE + HSM
SW: QNX Hypervisor 2.x hosting QNX SDP (AUTOSAR Adaptive), Linux for non-safety services, plus a safety-monitor partition
Buses: 3× 1000BASE-T1 (built-in switch fabric), 5× CAN-FD (legacy chassis, body-bridge, parking, cluster, CGW backup), 1× private CAN-FD to BMS

Cybersecurity scope
  • Cross-domain bus integrity (chassis ↔ body ↔ BMS)
  • OTA orchestration: signature verification, anti-rollback, A/B
  • Hypervisor partition isolation + IPC policy
  • UDS 0x29 (ISO 14229-1:2020) tester authentication; SecOC over in-vehicle PDUs
Threats correlated
  • 118 distinct threats (18 critical, 41 high)
  • Hub of 11 of the 14 cross-ECU attack paths

ECU 3 of 4

ADAS Domain Controller

ADC · L2+/L3 sensor fusion & driving stack

HW: Nvidia DRIVE Orin-class SoC: safety island Cortex-R52F + Cortex-A78AE compute cluster + GPU + DLA
SW: Nvidia DRIVE OS (QNX safety-RTOS guest + Linux guest for perception)
Buses: 1× 10GBASE-T1 to VDC switch, 6× GMSL3 (cameras), 5× radar, 1× LiDAR Ethernet, 4× CAN-FD

Cybersecurity scope
  • Sensor link integrity (GMSL3 link-layer auth, radar / LiDAR replay)
  • Per-layer Merkle hashing of model bundles + engine-signature verification on the safety island
  • Safety-island ↔ compute-cluster IPC hardening
  • UN R157 (DCAS) interaction with R155 evidence
Threats correlated
  • 89 distinct threats (8 critical, 27 high)
  • Anchors 6 of the 14 cross-ECU attack paths

ECU 4 of 4

Battery Management System

BMS · HV pack monitoring, cell balancing, charge supervision

HW: dual lockstep ARM Cortex-R52 + HSM-light
SW: AUTOSAR Classic + ASIL-D safety stack
Charge interface: PLC modem (HomePlug Green PHY) for ISO 15118-2/-20 with PnC (CCS markets) and classic CAN 2.0B for GB/T 27930 (China DC fast-charge) — two distinct stacks, never a single “PLC over CAN” conflation
In-vehicle: 1× private CAN-FD to VDC, 1× classic CAN to OBC

Cybersecurity scope
  • HV trust boundary — only SecOC-protected messages from VDC are accepted
  • Charging-protocol attacks: ISO 15118-2 PnC, X.509 chain validation; GB/T 27930 cyclic-data plausibility
  • Independent cell-current envelope check that ignores the negotiated charging-station limits for safety bounds
  • FuSa / cybersecurity co-engineering with the ASIL-D team
Threats correlated
  • 61 distinct threats (4 critical, 19 high)
  • Terminal of 5 of the 14 cross-ECU attack paths

Engineering timeline — project award → SOP

30 calendar months from project award (2024-Q2) to start of production (2026-Q4). ThreatZ joined the program 4 months in, after architecture freeze.

  1. 2024-04 · Project award

    Tier-1 wins the 4-ECU package

    Customer line-item proposal includes ISO/SAE 21434 + R155 + GB 44495 evidence as a contractual deliverable. CSMS audit is set for 2025-Q4.

  2. 2024-09 · ThreatZ adopted

    Architecture import + baseline TARA migration

    ARXML, DBC, SysML XMI from the four ECU teams imported into one ThreatZ tenant in a 3-day workshop. 1,840 signals across 4 buses captured.

  3. 2024-12 · Cross-ECU TARA freeze

    14 cross-ECU attack paths identified

    AI-assist surfaces attack chains that span CGW ↔ VDC ↔ ADC and CGW ↔ VDC ↔ BMS. Six of these were missed by the per-ECU TARA spreadsheets.

  4. 2025-Q1 · Security requirements

    Treatments derived & allocated

    Threats → security goals → requirements → component allocation, round-tripped to Polarion via ReqIF 1.2. 487 cybersecurity requirements approved.

  5. 2025-Q3 · SBOM coverage

    23 sub-tier suppliers onboarded

    CycloneDX / SPDX ingest from SoC vendor, OS suppliers, AUTOSAR stacks, V2X stack, sensor firmware, charging-protocol stacks. Continuous CVE monitoring active.

  6. 2025-Q4 · ISO/SAE 21434 process assessment

    Tier-1's 21434 process assessed by an accredited third-party (TÜV-class)

    Evidence pack generated directly from ThreatZ. Zero major findings; one minor advisory (annual SBOM-supplier-attestation cadence). The assessment is consumed by the OEM as supporting evidence for the OEM's R155 CSMS certificate held with KBA — the Tier-1 itself is not the CSMS holder.

  7. 2026-Q2 · Type-approval evidence delivered

    R155 annex + GB 44495 cybersecurity report packs delivered to OEM

    Both packs are anchored to the same TARA. OEM submits R155 to KBA (Germany) for vehicle type approval; for China, the OEM’s GB 44495 evidence is delivered to a CNCA-accredited test agency (CATARC) whose test report supports MIIT vehicle-type access (公告) listing.

  8. 2026-Q4 · Start of production

    Series production — ThreatZ in operations mode

    Continuous CVE monitoring + cross-ECU re-evaluation on every architecture change. Telemetry flows from CGW to OEM VSOC via the contractual REST + webhook interface.

What the cross-ECU view found that per-ECU TARAs missed

Five representative attack paths from the 14 surfaced. Each one crosses an ECU boundary and would have been invisible in single-ECU spreadsheets.

AP-03

Cellular → CGW → VDC → tampered SoC presented to driver / used by VDC energy management

A compromised over-the-air firmware update on the CGW becomes a foothold for crafting CAN-FD frames on the private VDC↔BMS link. The BMS remains the source of truth for the actual cell state, but the *VDC's* view of SoC (the value forwarded to the cluster, range estimator and energy-manager) is corrupted, producing misleading range / charge-time information and unsafe energy-management decisions. Mitigated by SecOC on the private link plus a VDC-side plausibility check against rate-of-change envelopes.

CGWVDCBMSSeverity: Critical

AP-05

OEM-portal misuse → OTA → ADC perception model swap

Stolen OTA-portal credentials used to push a tampered perception model. The CGW→VDC→ADC OTA chain enforces image signing at the bundle level but the original design did not validate model contents at finer granularity. Mitigated by per-layer Merkle hashing of the model bundle plus engine-signature verification (TensorRT engine signature) executed on the ADC safety island before the model is loaded into the inference path.

CGWVDCADCSeverity: High

AP-07

Body-domain CAN-FD → central diagnostic gateway → DoIP routing misuse to BMS

A side-supplier body-domain ECU is used as a stepping stone for crafted DoIP / UDS traffic that reaches the BMS via the central diagnostic gateway path on VDC. The BMS’s diag stack enforces UDS Security Access (0x27) and 0x29 Authentication, but the original VDC routing policy did not bind the source identity of the requester. Mitigated by SecOC on the body bridge, a hard VDC routing policy that only forwards UDS to BMS from authenticated tester roles, and BMS-side rejection of all non-0x29-authenticated routine controls.

BodyVDCBMSSeverity: High

AP-09

GMSL3 camera-link spoof → ADC → spurious VDC trajectory request

Replay or injection on a GMSL3 camera link causes the ADC to emit a falsified driving trajectory, which the VDC accepts because the cross-ECU contract assumed ADC outputs were intrinsically trusted. Mitigated by GMSL3 link-layer authentication and an ADC→VDC plausibility envelope at the chassis controller (rate of change, lateral acceleration limit, IMU consistency).

ADCVDCSeverity: High

AP-12

Charging port (ISO 15118 PLC) → BMS → tampered range / state-of-health forwarded to VDC & cluster

Malicious charging-station behaviour over ISO 15118-2 PLC PnC negotiates and reports anomalous parameters that the BMS forwards to the VDC over the private CAN-FD link, propagating a corrupted state-of-health and post-charge range into the cluster and energy-management. The original BMS→VDC contract had no rate-of-change envelope, allowing an external charger to indirectly mislead the driver. Mitigated by a BMS-side independent current-window check that uses cell-monitor measurements directly (ignoring 15118 negotiation), plus a VDC-side plausibility envelope on SoH transitions per charging session.

ChargingBMSVDCSeverity: Critical

9 further cross-ECU attack paths (AP-01, 02, 04, 06, 08, 10, 11, 13, 14) are documented inside ThreatZ but withheld from public disclosure at the customer's request.

Outcomes — this program, single source of evidence

From four siloed spreadsheets to one connected cybersecurity case

Numbers extracted from the customer's ThreatZ tenant
340
Threats authored across the 4 ECUs (CGW 72, VDC 118, ADC 89, BMS 61)
14
Cross-ECU attack paths surfaced (each crosses ≥ 2 ECUs)
73%
Faster TARA vs the team's prior comparable program
487
Cybersecurity requirements (ReqIF 1.2 round-tripped to Polarion)
23
Sub-tier suppliers SBOM-onboarded
3
Compliance regimes from one knowledge graph
0
Major findings at the 21434 process assessment
< 30 min
Median CVE-to-ECU impact decision

“Running one TARA across the four ECUs — instead of four against each ECU in isolation — changed the picture. We found six cross-ECU attack paths in the first week that nobody had seen in eighteen months of per-ECU work. The same model then drove the R155 and GB 44495 packs without us re-keying anything.”

— Cybersecurity Lead Engineer, Tier-1 supplier

How we measure the numbers above

Definitions and scope of every metric on this page. All figures are extracted directly from the customer's ThreatZ tenant; no surveys, no estimates.

Scope of this case study. Single customer engagement: a European Tier-1 supplier delivering four domain-controller ECUs (Central Gateway, Vehicle Domain Controller, ADAS Domain Controller, Battery Management System) into one global B-segment EV SUV program. Customer name, OEM identity, and exact volume figures are withheld at the customer's request; the underlying data is auditable inside the customer's ThreatZ tenant.

What “14 cross-ECU attack paths” means. Distinct attack scenarios documented in the program's TARA whose threat trace crosses an ECU boundary at least once (e.g. CGW → VDC → BMS). Each path was reviewed and accepted by the Tier-1's cybersecurity lead and the OEM's cybersecurity reviewer; not auto-suggested entries that were later rejected. 5 of the 14 are summarised on this page; 9 are withheld at the customer's request.

What “340+ threats authored” means. Sum of distinct threat scenarios (per ISO/SAE 21434 Clause 15) accepted into the four ECU TARAs at the time of the 2025-Q4 CSMS audit. Per-ECU breakdown: CGW 72, VDC 118, ADC 89, BMS 61 — total 340. Cross-ECU paths are counted as composite scenarios separately, not added to this total.

What “73% faster TARA” means. Engineer-weeks from architecture import to TARA freeze on the same four ECUs in the same Tier-1, comparing the customer's prior approach (one TARA spreadsheet per ECU + a shared Polarion module, using the same engineering team on a comparable previous program) against the ThreatZ-driven cross-ECU TARA on this program. Customer's own baseline; not an industry-wide comparison.

What “< 30 min CVE impact decision” means. Median wall-clock time, measured during 2025-Q4, from a CVE appearing on NVD or CNVD to a binary present/absent answer per affected ECU and a recommended remediation track in the customer's ThreatZ tenant. Includes the human review step performed by the Tier-1's PSIRT analyst.

What “0 major findings” means. Zero major findings at the ISO/SAE 21434 process assessment conducted at the Tier-1 in 2025-Q4 by an accredited third-party assessor (TÜV-class), where ThreatZ was the system of record for the evidence pack. One minor advisory was raised (annual SBOM-supplier-attestation cadence) and is being actioned for SOP. The Tier-1 is not the holder of an R155 CSMS certificate — that certificate is held by the OEM with the KBA, and the 21434 process assessment is consumed as supporting evidence by the OEM’s CSMS audit. R155 (KBA, Germany) and GB 44495 (CNCA-accredited test agency feeding MIIT) submissions are scheduled for 2026-Q2 and not yet results-final.

Caveats. The customer name and OEM identity are withheld; the numbers above are not independently verifiable by third parties without customer consent. Outcomes on a different program will depend on E/E architecture complexity, prior process maturity, sub-tier supplier cooperation, and team composition. The 73% TARA speed-up benefits significantly from architecture freeze having already occurred when ThreatZ was adopted; programs that adopt ThreatZ during architecture exploration tend to see larger benefits in iteration count rather than calendar weeks.

Your Success Story

Ready to Transform Your
Automotive Cybersecurity?

Join leading OEMs, Tier-1 suppliers, and EV manufacturers who trust VxLabs to secure their vehicles. Let us show you what ThreatZ can do for your organization.

ISO/SAE 21434 UNECE R155 GB 44495