AutoST for Tier-1 Suppliers: Test Your ECU Before the OEM Does

The job

A Tier-1 supplier receives a cybersecurity requirements specification from the OEM, builds the ECU, and has to show in a verification report that each requirement is met. Under ISO/SAE 21434 Clause 7 the split of work is written down in a cybersecurity interface agreement: who does the TARA, who verifies which control, who delivers which work product. Testing almost always lands on the supplier side, for every sample phase, for every OEM variant and for every software release after start of production.

The reality on the bench looks different from the agreement. In penetration tests of power-electronics ECUs for Tier-1 suppliers, a DC/DC converter and an on-board charger among them, we found SecurityAccess seeds that were constant or derived from uptime, no attempt counter after wrong keys, identification DIDs such as serial number and fingerprints writable without SecurityAccess, and resets on malformed ISO-TP first frames. None of this had been caught internally, because the only test before the pentest was the diagnostic tester checking that the specified services work.

What the role needs from a test run

The supplier’s test and cybersecurity engineers need a run that fits the sample cadence and gives developers something to act on.

• A repeatable profile per sample phase. The same enumeration of sessions, services and DIDs, the same SecurityAccess (0x27) checks and the same seeded fuzzing before A, B and C samples, so a regression between releases is visible as a diff and not as a surprise in the OEM lab.
• The supplier’s own diagnostic description. ODX or CDD import names every DID and calls the routines the ECU actually defines. The write probing of DIDs (0x2E) checks what the ECU accepts, with confirmation before anything is written.
• SecurityAccess checks that match what is implemented. Seed randomness over many requests, key recovery for weak algorithms and a catalogue of default keys, lockout after wrong keys, sequence enforcement and the optional reset probe. The supplier wrote the algorithm; the run tells them whether it holds.
• Reproducible fuzzing. A stored seed per run and the exact payload per finding, so the firmware developer can replay the ISO-TP frame or the oversized TransferData that hung the ECU.
• Developer-facing output. Fix Plan tasks ranked by severity with what, risk and fix, exported as SARIF, CSV or JSON into the tracker the team already uses, and a PDF for the OEM.

Typical setup

The bench already exists: ECU, power supply, residual bus simulation, a CAN interface. The Carbyne agent runs on the bench PC, on Windows with Vector hardware through the XL driver library or on Linux with PEAK, Kvaser or any other SocketCAN interface; for ECUs on automotive Ethernet, DoIP and SOME/IP run over the normal network port. The agent polls the backend over HTTPS.

Most Tier-1s install AutoST on their own servers because OEM diagnostic descriptions and firmware details are confidential; smaller sites use the instance hosted by Zyberum in the EU and keep the agent local. The cybersecurity manager owns the test profile and the risk weighting, the test engineer runs the scans at the end of each integration cycle, and the firmware team works the Fix Plan. Licensing is per tested component, so one ECU family with several OEM variants is one conversation, not several.

A sensible first project

Pilot on one ECU that is in the B-sample phase and has a cybersecurity requirements specification you can map to.

1. Week 1: scope. Choose the ECU, attach its ODX or CDD, list the SecurityAccess levels and the services that must only be reachable in extended or programming session. Install and pair the agent on the existing bench.
2. Week 2: baseline run. Enumeration across sessions, DID and routine scan, SecurityAccess checks. Walk through the findings with the firmware lead and agree what is a bug, what is accepted and what the OEM needs to know.
3. Weeks 3 and 4: fuzzing. Seeded UDS fuzzing on the services the ECU exposes, with TesterPresent liveness and DTC monitoring. Reproduce every crash once before it goes into the Fix Plan.
4. Weeks 5 and 6: fix and retest. Developers work the ranked tasks; the same profile runs again. Accepted risks and comments carry over, so the second PDF shows exactly what was closed.
5. Hand-over. Attach the PDF to the verification report for the C sample and decide whether the profile becomes part of every release.

How results feed ISO/SAE 21434 and UN R155

ISO/SAE 21434:2021 Clause 10.4.2 requires that the implementation is verified against the cybersecurity specification ([RQ-10-09]) and recommends component testing with fuzz testing and vulnerability scanning ([RC-10-12]). The AutoST PDF with its dated scan history is the component-level evidence behind that verification report, and the Fix Plan’s ALM/PLM reference links each finding to the requirement or ticket it belongs to. Clause 11 validation ([RQ-11-01]) names penetration testing; AutoST is the baseline for it, not a substitute. Clause 8.5 treats vulnerability analysis as a continuous activity, which a profile run before every release gives you without extra process.

UN R155 is addressed to the vehicle manufacturer, but paragraph 7.2.2.5 requires the manufacturer to show how its CSMS manages the dependencies on suppliers, which is why OEMs ask for supplier test evidence against the Annex 5 threats. UN R156 does the same for every software update after approval. Supporting an R155 audit at a Tier-1, the gap was never the testing itself; it was showing which test covered which requirement and when it last ran. A per-component history with reproducible runs closes that gap. AutoST is not a certification and does not make the ECU compliant; it produces the evidence the agreement with your OEM asks for.