ISO/SAE 21434 verification evidence from security testing

ISO/SAE 21434 asks you to verify that your cybersecurity controls work and to keep the evidence that they do. A security test only becomes evidence when an assessor can trace it to a requirement, see when it ran, reproduce its findings and read what happened to each one. This is a guide to what the standard asks for and how to produce artifacts that survive an assessment. It is practical guidance, not a certification, and no tool makes you compliant on its own.

Where the standard asks for testing

Three clauses of ISO/SAE 21434:2021 are where security testing lives:

Clause	Activity	What it asks for
10.4.2	Integration and verification	[RQ-10-09] verify the implementation meets the cybersecurity specification; [RC-10-12] recommends component testing with fuzz testing and vulnerability scanning to minimise unidentified weaknesses
11	Cybersecurity validation	[RQ-11-01] names penetration testing to confirm the cybersecurity goals
8.5	Vulnerability analysis	Finding and analysing weaknesses as a continuous activity over the lifecycle

From CAL 2 upward, fuzz testing of communication interfaces is effectively expected. The depth of testing scales with the Cybersecurity Assurance Level (CAL) of the item.

The difference between a test result and evidence

An assessment is not graded on whether you ran a fuzzer. It is graded on your work products: the verification report, the validation report and the cybersecurity case that argues the item is adequately secure, judged in the cybersecurity assessment (Clause 6.4.9). A test result becomes evidence when it carries four things:

1. Traceability. A link from the cybersecurity requirement to the test that verifies it, and back. An assessor must be able to start at a goal (“the ECU must not accept diagnostic writes without authentication”) and reach the test that checks it.
2. A date and a scope. What was tested, on which ECU and software version, and when. A result with no date cannot be placed in the lifecycle.
3. Reproducibility. For fuzzing, a stored seed so a crash can be replayed. A finding nobody can reproduce is weak evidence.
4. A disposition. What happened to each finding: fixed, mitigated, or accepted as a residual risk with a documented rationale.

Mapping test types to the clauses

Different security tests produce evidence for different clauses:

• UDS enumeration maps the diagnostic attack surface. It is evidence that reachable services and DIDs were checked against the specification (10.4.2).
• SecurityAccess (0x27) checks verify that an authentication control actually holds, which is often a direct cybersecurity requirement (10.4.2).
• Fuzzing of UDS and CAN interfaces is the component testing [RC-10-12] recommends, and the evidence is the seeded run plus its findings.
• DoIP, SOME/IP and IVI checks extend that coverage to Ethernet and infotainment surfaces.
• The whole set re-run on each build is how Clause 8.5 vulnerability analysis becomes a standing activity rather than a one-off.

What an assessor actually opens

An assessor does not run your tools. They read artifacts. The ones that work are:

• A report per ECU with the findings, each carrying a severity, the service or interface it concerns, and a concrete remediation.
• A dated history showing the same ECU tested across versions, so a fixed finding shows as resolved and an accepted one stays documented.
• A machine-readable export such as SARIF 2.1.0, so the findings flow into the team’s own tooling and issue tracker rather than living only in a PDF.
• A reference field on each finding linking it to the requirement or ticket it relates to, which is the traceability the assessor is looking for.

On an ISO/SAE 21434 audit-support engagement at a Tier-1, the gap was never the testing itself. It was that the testing could not be traced back to requirements, so good work read as anecdote. Fixing the traceability, not the tests, is what passed the assessment.

Where testing stops and process begins

Security testing produces verification and validation evidence. It does not write your TARA, run your cybersecurity management system (CSMS) or build your cybersecurity case. Those are process work products that sit around the testing. Overstating what a test tool does will not help an audit, because an assessor reads the whole argument, not just the test log.

AutoST produces the testing side of this directly: enumeration, SecurityAccess checks, seeded fuzzing, DoIP/SOME/IP and IVI tests, each finding scored and carrying a fix, a dated scan history, risk acceptance carried across re-tests, and PDF plus SARIF export with a reference field per finding. It does not run your CSMS or write your TARA; for those, Zyberum offers ISO/SAE 21434 consulting from the same team that holds the SAE and TÜV SÜD Automotive Cybersecurity qualification.