What ISO/SAE 21434 and FDA Premarket Cybersecurity Actually Require From Dynamic Testing

Security standards for automotive and medical devices have matured past checkbox compliance. Both ISO/SAE 21434 and the FDA's 2023 premarket cybersecurity guidance ask for evidence - artifacts that demonstrate you tested the attack surface dynamically, not just reviewed the code. If your current process stops at static analysis and threat modeling, you have a gap the auditor will find before the adversary does.

This article breaks down what each standard actually says about dynamic security testing, where the requirements overlap, and what "sufficient evidence" looks like in practice.

ISO/SAE 21434: The Evidence Requirement Is in the Work Products

ISO/SAE 21434 establishes cybersecurity engineering for road vehicles across the full lifecycle. The standard is organized around work products - documented outputs that demonstrate a requirement was met. Several clauses are directly relevant to dynamic testing:

Clause 10 (Product Development) requires cybersecurity testing as part of integration and system testing. The standard expects test cases derived from the TARA (Threat Analysis and Risk Assessment) and specifies that testing must cover the attack paths identified during risk analysis.

Clause 11 (Cybersecurity Validation) goes further: validation must confirm that cybersecurity goals are actually achieved, not just that engineering tasks were completed. A threat model document does not satisfy this. You need runtime evidence.

Clause 12 (Production, Operations, and Maintenance) introduces the concept of monitoring for vulnerabilities in deployed components - which ties directly to having a repeatable, automated testing process you can re-run against updated firmware or software components.

For CAN bus and embedded ECU targets specifically, the attack surface includes protocol handling, diagnostic interfaces (UDS, OBD-II), and firmware update mechanisms. Static analysis can identify code patterns; it cannot tell you how a CAN frame parser behaves when it receives malformed input at runtime. That gap is precisely where fuzzing generates the work-product evidence 21434 demands.

The practical upshot: your 21434 audit file needs test execution logs, identified findings, disposition records, and regression evidence. A threat model and a SAST report alone will not close Clause 10 or 11.

FDA Premarket Cybersecurity Guidance: "Robust Testing" Is Not Optional

The FDA's 2023 guidance ("Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions") is explicit in a way earlier guidances were not. Section 5 on cybersecurity testing states that sponsors should provide evidence of:

The guidance calls out fuzzing by name. It expects sponsors to describe the fuzzing approach, the interfaces tested, and the results - including how identified vulnerabilities were addressed. This is a submission artifact requirement, not a best-practice suggestion.

For medical devices, the relevant attack surface typically includes:

The FDA's position is grounded in the understanding that memory corruption, input validation failures, and protocol handling bugs in device firmware are not reliably caught by static analysis or code review. Dynamic fuzzing is the mechanism that exercises the device as a black- or grey-box system under conditions that approximate real-world attack input.

What the submission needs: a description of the fuzzing methodology, the target interfaces, the test environment, identified findings and their severity, and evidence of remediation or accepted risk. Vague statements like "fuzzing was performed" are not sufficient - reviewers will ask for specifics.

Where the Two Standards Converge

Despite different regulatory contexts, both frameworks share a core expectation: dynamic evidence produced at the interface level, not inferred from source code review.

| Requirement dimension | ISO/SAE 21434 | FDA Premarket Guidance | |---|---|---| | Dynamic testing explicitly required | Yes (Clause 10) | Yes (Section 5) | | Fuzzing called out | Implied via interface testing | Explicitly named | | Findings must be documented | Yes (work products) | Yes (submission artifact) | | Remediation evidence required | Yes | Yes | | Repeatable / regression testing | Yes (Clause 12 lifecycle) | Expected for iterative design |

The convergence matters practically: if you are building a connected medical device that also interacts with a vehicle network (infotainment integrations, EMS equipment, fleet health monitoring), you are operating under both frameworks. A single fuzzing program designed to produce audit-ready artifacts can serve both.

What "Audit-Ready" Fuzzing Evidence Actually Looks Like

Regardless of which standard applies, the artifact set reviewers expect has a consistent shape:

  1. Scope definition - which interfaces were tested, which were excluded and why
  2. Test methodology - mutation-based, generation-based, or protocol-aware; seed corpus description
  3. Execution logs - timestamps, input volume, coverage metrics where available
  4. Finding records - crash/hang/anomaly details, reproducibility, severity assessment
  5. Disposition - fixed, accepted risk with rationale, or deferred with timeline
  6. Regression evidence - confirmation that fixed issues do not reappear in subsequent builds

This is documentation work, but it has to be backed by real test runs. A platform that produces machine-readable logs and integrates into your build pipeline reduces the manual overhead of assembling this artifact set significantly.

The Static Analysis Gap

SAST tools are essential - they find code-level issues early and cheaply. But neither 21434 nor the FDA guidance treats static analysis as a substitute for dynamic testing. The reason is architectural: static analysis operates on code paths as modeled by the tool; dynamic fuzzing operates on the running system as it actually behaves.

Protocol parsers, state machines, and hardware abstraction layers in embedded firmware frequently behave differently at runtime than a static model predicts. Memory safety issues triggered by specific input sequences, race conditions in interrupt handlers, and parser differentials in proprietary CAN message formats are categories of vulnerability that fuzzing surfaces and static analysis routinely misses.

Getting Started

If you are preparing a 21434 TARA or an FDA premarket submission and your dynamic testing evidence is thin, the place to start is interface enumeration: list every external input the device accepts and categorize it by protocol and trust level. That list becomes the scope definition for a fuzzing program, and the fuzzing program becomes the source of the evidence both standards require.

Penzzer is built for exactly these targets - medical device firmware, CAN bus interfaces, and embedded systems where dynamic testing has historically been operationally difficult. If you want to understand what a fuzzing program for your specific target interfaces would look like, penzzer.com is the right starting point.

This post is about Penzzer.

More on this