How to write an ECU security test plan

An ECU security test plan is a short document that turns the TARA into test cases you can run and check. It answers five questions before the first frame goes on the bus: what exactly is tested (item, variant, software version, interfaces), on which bench, which test cases cover which threat scenario, what result counts as a pass, and in which order the tests run so that a hung ECU does not cost you a day. A plan that only says “UDS fuzzing, SecurityAccess, penetration test” is a list of activities. A plan that says “TC-12: in extended session, 2E F1 8C with any payload must answer 7F 2E 33 while locked” is something two testers will run the same way.

Start from the TARA, not from the tool list

Every test case should exist because a threat scenario or a cybersecurity requirement asks for it. Take the threat scenarios from the TARA (ISO/SAE 21434 Clause 15), the cybersecurity goals and the requirements derived from them, and ask for each one: which observable behaviour on the bench would show that the control works?

Threat scenario	Requirement	Test case
Manipulation of ECU identification data	Identification DIDs writable only after SecurityAccess	TC-12: write probe on F18C, F190 while locked
Unauthorised reprogramming	RequestDownload (0x34) only after SecurityAccess	TC-20: 10 02 then 34 without unlock
Brute force of SecurityAccess	Lockout after 3 invalid keys, delay 10 s	TC-31: invalid key series, expect 7F 27 36 then 7F 27 37
Denial of service via diagnostics	ECU survives malformed requests	TC-40: UDS fuzzing campaign, liveness after each iteration

Generic surface checks that every ECU gets (enumeration of sessions and services, identification DIDs, SecurityAccess quality) go in as well, even when the TARA is silent, because they are cheap and they catch what the TARA missed.

Fix the scope and the bench

The scope section names the ECU variant, hardware revision and the software version as the ECU reports it (22 F1 89, 22 F1 95), the interfaces in scope and the ones explicitly out of scope. The bench section is what lets someone else reproduce a finding six months later:

• Interface and adapter, bitrate and, for CAN FD, data bitrate and sample point.
• Request and response IDs (for example 0x7E0 and 0x7E8), addressing mode, ISO-TP padding byte.
• For DoIP: logical addresses and the routing activation type. For an IVI: build fingerprint and ADB transport.
• The ODX, CDD or DBC revision you test against, and the credentials you hold (security levels, keys).
• A recovery path: how to reflash, how to power cycle remotely, who to call when the ECU stays dead.

Write pass criteria in bytes

A pass criterion that cannot be checked by comparing a response is an opinion. Write the request, the expected response and the condition under which it applies.

TC-20  RequestDownload requires SecurityAccess
Pre:   default session, security locked
Step:  10 02            -> 50 02 ...   (or 7F 10 22 if conditions apply)
Step:  34 00 44 00 00 00 00 00 01 00 00
Pass:  7F 34 33 (securityAccessDenied)
Fail:  74 ...  (download accepted while locked)

For campaigns, write the coverage instead of a single response: “SIDs 0x00 to 0xFE in sessions 01, 03 and every vendor session that answered”, “10,000 UDS fuzzing iterations per selected SID, seed recorded, TesterPresent liveness after every iteration”. The coverage figure is what an assessor uses to judge whether the testing was sufficient under ISO/SAE 21434 Clause 10.4.2.

Order by risk to the ECU

The order matters more than people expect. Run the tests that only read first, then the ones that write, then the ones that can break the ECU.

1. Discovery. Endpoint scan, session discovery, service sweep, DID read. Non-destructive and the input for everything after it.
2. Access control. SecurityAccess seed quality, attempt counter and delay, write probes on DIDs and routine probes.
3. Session and reset handling. Session fallback, S3 timeout, security state after reset.
4. Robustness. UDS and CAN fuzzing, malformed ISO-TP frames.
5. Manual work. The pentester’s deeper tests on what the earlier steps surfaced.

Steps 1 and 2 are where most findings come from on the benches we work on. Steps 3 and 4 can leave the ECU in a fault state, which is why they come later and carry an approval note.

Plan the evidence before you test

Decide up front what you keep per test case: the raw bus log, the request and response, the tool version, the date and the software version under test. Decide how a finding is rated (one scheme, named) and where it goes afterwards (ticket, ALM reference). A test case that passed is evidence too: record it, because the clean results are what prove that a mitigation works.

Re-test is part of the plan

Most ECUs are tested more than once: after a fix, after a new software release, before the start of production. Keep test case identifiers stable across runs, so that TC-12 on software 0x0142 and TC-12 on 0x0143 can be compared line by line. If the repeatable cases run automatically on every release, the manual effort goes into what changed.

Where AutoST fits

AutoST covers the repeatable part of such a plan: discovery, ODX- and CDD-driven DID and routine probing, SecurityAccess checks, UDS and CAN fuzzing, DoIP, SOME/IP and Android IVI checks, each with recorded requests, responses and coverage, and a PDF and SARIF output per run. It does not write the plan or the TARA for you, and the manual test cases stay with a penetration tester. What it changes is that the same test cases run identically every time, which is exactly what a re-test needs.