Diagnostic Tester vs Security Tester: Why Your ODX Tool Is Not a Security Test

What is the difference?

A diagnostic tester is built to confirm a specification. You load the ODX or CDD, it knows every service, DID, routine and their parameters, and it lets you execute them: read the VIN, start the routine, flash the image, clear the DTCs. Used for testing, it answers “does the ECU do what the file says?” Its view of the ECU is the file. A DID that is not in the ODX does not exist for it, and a service that answers in the default session when the file says extended is not something it would notice, because it would open the extended session first as told.

A security tester is built to find what the specification does not say. It walks every session, sends every service identifier and classifies the negative response codes, sweeps the DID space the file does not mention, counts how many wrong keys SecurityAccess accepts, tries a key without requesting a seed, probes whether an identification DID is writable, and then sends the ECU malformed input and watches whether it survives. Its view of the ECU is what the ECU actually answers. The ODX is useful to it for naming and for calling real routines, not as the boundary of the test.

The two are not interchangeable and the diagnostic tester is not worse. Conformance testing is needed and a security tool is bad at it. The error is using a conformance tool and believing a security test has happened.

Side by side

	Diagnostic tester	Security tester
What it finds	Deviations from the ODX or CDD: wrong response lengths, missing DIDs, routines that fail, flashing errors, timing violations	Undocumented services and DIDs, services in the wrong session, writable identification DIDs, weak or constant seeds, missing attempt counters, keys accepted without a seed, resets and hangs under fuzzing, exposed XCP/CCP, DoIP routing and SOME/IP exposure
What it misses	Everything not in the file: undocumented surface, wrong-session exposure, SecurityAccess weaknesses, robustness; it never sends malformed input on purpose	Conformance detail: it does not check that a documented DID has the right length or scaling; logic and chained attacks remain a pentester’s job
Who does it	Diagnostics and validation engineers	The same engineers from a dashboard, or a security team
Bench time	Seconds per sequence; a full conformance run depends on the test specification	Minutes for enumeration, hours for fuzzing, unattended
Cost	Commercial diagnostic tool licences, often already in the house	AutoST licensed per tested component, price on request; free open-source tools cover parts of it
Fits a release cycle	Yes, conformance sequences are usually automated already	Yes, via API tokens and the Bamboo plugin, with SARIF into the tracker
Required by	Diagnostic conformance requirements of the OEM; type-approval related diagnostics for emissions ECUs	ISO/SAE 21434 Clause 10.4.2 [RC-10-12] component testing with fuzzing and vulnerability scanning; UN R155 testing of security measures
Output	Pass or fail per test step, trace logs	Map of the surface with risk flags, 0 to 10 score, PDF report, SARIF, Fix Plan

Choose the diagnostic tester when

• The question is conformance: does each documented service behave as specified across variants and firmware releases. That is what the tool is for and it does it better than any security tool.
• You need to drive the ECU for other tests: flashing, end-of-line routines, variant coding, DTC handling.
• You want to check one hypothesis quickly. “Does 2E F1 8C work in the default session?” is a single request, and the diagnostic tester sends it fine.
• Nobody has asked for a security test and the ECU has no security goals. Then nobody needs a security tester either.

Choose the security tester when

• Somebody has to answer “what can an attacker on the bus or the OBD port do with this ECU”, not “does the ECU meet the spec”. The findings we see most often, services reachable in the default session, writable fingerprints, seeds without randomness, no attempt counter, are all invisible to a conformance run.
• The ECU is at CAL 2 or higher, or an assessor will ask for fuzzing and vulnerability scanning evidence under [RC-10-12].
• You want the result as evidence: a dated report per firmware release, a score to compare releases, SARIF into the tracker, a Fix Plan with status.
• You want the full DID and service space covered, not the documented subset. Roughly ten minutes per session covers 0x0000 to 0xFFFF; no engineer does that by hand.

Both together

They complement each other and share a file. Load the same ODX or CDD into both: the diagnostic tester proves that what is documented works, the security tester proves that nothing undocumented is exposed and that the documented gates (sessions, SecurityAccess) actually hold. The diff between the two views is itself a finding: every DID the security tester reads that the file does not list is a question for the supplier.

AutoST is the second tool in this pair. It imports ODX, PDX and CDD files to name what enumeration finds and to call the routines they define, and it leaves conformance testing to the tool you already have. Neither of them finds a seed/key algorithm that is weak by design or an attack chain across the update path; for that you need a penetration tester reading the firmware.