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

> Vulnerability scanning on an ECU means structured probing with valid requests: which sessions, services and DIDs answer, whether SecurityAccess has a counter, whether a DID is writable. It finds configuration and access-control weaknesses and takes minutes. Fuzzing means malformed, oversized and random input over hours, watching whether the ECU resets, hangs or throws fault codes. It finds implementation bugs in parsers and stacks. ISO/SAE 21434 [RC-10-12] recommends both for component testing.

A vulnerability scan asks an ECU known questions and classifies the answers; fuzzing sends malformed input and watches for crashes. Why ISO/SAE 21434 recommends both.

Source: https://auto-st.com/compare/fuzzing-vs-vulnerability-scanning · Updated: 2026-10-07

## 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.

## FAQ

**Is UDS enumeration a vulnerability scan?**

Yes, in the ECU sense. Enumeration sends valid requests (session control, every service identifier, DID reads) and classifies the negative response codes. The scan part is the interpretation: a service that answers in the default session but should need extended, a DID writable without SecurityAccess, a seed that repeats. No input is malformed and nothing is written unless you enable write probing.

**Can fuzzing damage the ECU?**

It can put the ECU into a fault state, reset it or in rare cases leave it unable to boot. Fuzzing is a bench activity only, never on a vehicle in traffic, and you should have a recovery path such as a flashable image before you start. A vulnerability scan with read-only probes carries much lower risk.

**How long should a fuzzing run be?**

Long enough to cover the services and lengths that matter, which is hours rather than minutes. Because AutoST runs are seeded, you can run a short smoke campaign on every build and a long campaign per release and replay any crash exactly.

## Sources

- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, Clause 10.4.2 [RC-10-12] (fuzz testing and vulnerability scanning)](https://www.iso.org/standard/70918.html)
- [ISO 14229-1:2020 Unified diagnostic services (UDS), Part 1: Application layer, Annex A (negative response codes)](https://www.iso.org/standard/72439.html)
- [ISO 15765-2:2024 Transport protocol and network layer services (ISO-TP)](https://www.iso.org/standard/84211.html)

## Related

- [Fuzzing (Fuzz Testing)](https://auto-st.com/glossary/fuzzing)
- [NRC (Negative Response Code)](https://auto-st.com/glossary/nrc)
- [UDS Fuzzing vs CAN Fuzzing: Which Layer to Attack and What Breaks](https://auto-st.com/compare/uds-fuzzing-vs-can-fuzzing)
- [A UDS fuzzing methodology that finds real bugs](https://auto-st.com/insights/uds-fuzzing-methodology)
- [Break it on the bench, not in the field.](https://auto-st.com/ecu-fuzzing)
- [Know every door into the ECU.](https://auto-st.com/uds-enumeration)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/compare/fuzzing-vs-vulnerability-scanning