Fuzzing vs Vulnerability Scanning on an ECU: What Each Method Finds

What is the difference?

A vulnerability scan sends an ECU requests it understands and reads the answers. 10 03 to open the extended session, 22 F1 90 to read the VIN, 27 01 to request a seed, each service identifier in each session, and the ECU replies with a positive response or a negative response code from ISO 14229-1 Annex A. The scan interprets those codes: 0x7F says the service exists in another session, 0x33 says it is behind SecurityAccess, 0x31 says the identifier is unknown. The weaknesses it finds are about what is allowed: a service reachable without a session change, a writable identification DID, a seed/key gate with no attempt counter, an XCP interface nobody meant to leave on.

Fuzzing sends the ECU input it does not expect. A ReadDataByIdentifier with 120 bytes of payload, an ISO-TP first frame announcing 4,000 bytes and never delivering them, random service identifiers, a TransferData block three times the agreed size, random CAN frames on the arbitration IDs from your DBC. Then it watches: does the ECU still answer TesterPresent, did the DTC count change, did a response time out. The weaknesses it finds are about how the ECU is built: buffer handling, length checks, state machines that get stuck, watchdog resets.

Both are automated. The difference is the question: “is this allowed?” versus “does this break?”.

Side by side

	Vulnerability scanning (enumeration and checks)	Fuzzing
What it finds	Services in the wrong session, readable and writable DIDs, missing SecurityAccess counters and delays, constant seeds, exposed XCP/CCP, DoIP routing to blocked ECUs, open SOME/IP services	Resets and hangs on malformed ISO-TP frames, crashes on oversized payloads, services that stop answering, fault codes raised by bad input, parser errors in CAN signal handling
What it misses	Implementation bugs in parsers and stacks; anything only triggered by invalid input	Access-control and design weaknesses; a perfectly robust ECU with a writable serial number passes every fuzzing run
Who does it	Test engineers from a dashboard; reads and classifies	Test engineers from a dashboard; needs a recovery path for the ECU
Bench time	Minutes per session; about ten minutes per session for a full DID sweep	Hours per campaign; a short run per build, a long run per release
Cost	Part of the AutoST licence per component; free tools exist	Part of the AutoST licence per component; free fuzzers exist but reproducibility and crash detection are your job
Fits a release cycle	Yes, fast enough for every build	Yes with a seeded, bounded campaign; a long run belongs on the release branch
Required by	ISO/SAE 21434 [RC-10-12] recommends vulnerability scanning for component testing; UN R155 asks for testing of the implemented measures	ISO/SAE 21434 [RC-10-12] recommends fuzz testing; expected in practice from CAL 2 upwards for communication interfaces
Output	A map of sessions, services and DIDs with risk flags and a 0 to 10 score; PDF and SARIF	Findings with iteration, payload, monitor and payload history, replayable by seed; PDF and SARIF

Choose vulnerability scanning when

• You see the ECU for the first time. Enumeration is non-destructive and tells you what is there before you throw anything at it.
• The question is configuration: has the supplier locked the programming session, is the identification range read-only, does SecurityAccess lock after three wrong keys. These are the findings we see most often on real benches and none of them needs fuzzing.
• The ECU is expensive or hard to recover. A read-only scan does not change state; fuzzing can.
• You need a result in minutes, for example as a gate on every build.

Choose fuzzing when

• The ECU parses complex input: multi-frame ISO-TP, TransferData blocks, DoIP messages, SOME/IP payloads, DBC-defined signals with checksums and counters. That is where length and state bugs live.
• You have had field returns or test-drive incidents with ECUs that reset or went silent and nobody could reproduce it. A seeded fuzzer with a payload history is how you find those.
• The ECU is at CAL 2 or higher and your assessor will ask for fuzz testing of the communication interfaces as [RC-10-12] recommends.
• The ECU passed every scan. A clean map says nothing about robustness.

Both together

They are two halves of component testing and ISO/SAE 21434 names them in one sentence. The practical order is scan first, fuzz second: enumeration gives the fuzzer its targets (the sessions that open, the services that answer, the DIDs that accept writes) and tells you what to exclude so you do not reset the ECU on iteration one. In AutoST both run from the same component and land in the same Fix Plan, so a writable DID and a crash on the same service show up as what they are: two findings on one attack surface.

Neither finds logic flaws or chained attacks. For those, and for the seed/key algorithm itself, you still need a person reading the firmware.