Medical Device Software Verification and Validation: What FDA Expects

Part of our Verification, Validation, and regression testing series. For the full overview, start with V&V and Regression Testing for Medical Devices.

Reviewed September 17, 2026

Every FDA submission for a software-containing device lives or dies on whether the manufacturer can prove two separate claims: that the software matches what was specified, and that what was specified actually solves the user's problem safely. Conflating these two questions is one of the most common reasons reviewers issue deficiency letters. A device can pass every unit test against its requirements and still fail validation if the requirements themselves missed a use error, a workflow gap, or an unanticipated clinical environment. Getting the distinction right, and documenting it with traceable evidence, is what separates a submission that moves forward from one that stalls in additional-information cycles.

Why This Matters

Weak or incomplete verification and validation is a recurring root cause behind recalls, warning letters, and refuse-to-accept holds. The FDA's "Cybersecurity in Medical Devices" final guidance, dated February 3, 2026, reinforces that cybersecurity controls are design inputs like any other, and that manufacturers must verify those controls were implemented correctly and validate that they do not degrade safety, effectiveness, or usability. IEC 62304 and the design control requirements at 21 CFR 820.30 already required this discipline for functional requirements. The February 2026 guidance closes the gap for security-specific requirements, making clear that a security control with no verification record is treated by reviewers as an unimplemented control.

Under the quality management system regulation (QMSR), design control expectations carry forward largely unchanged even though several legacy Part 820 subparts are now reserved. Manufacturers still need a documented design history file showing verification and validation were planned, executed, and reviewed. Reviewers use that traceability to decide whether a device is ready for market, and gaps here are one of the most common reasons for additional-information requests during premarket review.

What Is the Difference Between Verification and Validation?

Verification asks whether the software was built correctly against its documented requirements, and validation asks whether the software is the right solution for the user's actual needs. Verification is an internal, objective comparison: does the output match the specification. Validation is an external, use-context comparison: does the finished device work correctly for real users in the real intended use environment. A classic example is a dosing calculation that verifies perfectly against its requirement but fails validation because the requirement itself omitted a rounding rule that matters clinically.

[KEY REQUIREMENT] Every requirement in the design input document needs at least one verification test, and every user need needs at least one validation activity tracing back to it. A requirement with no test, or a user need with no validation evidence, is a gap a reviewer will find.

Where Do V&V Sit in the IEC 62304 Lifecycle?

IEC 62304 places verification inside each development phase and validation at the system level once integration is complete. Unit implementation is verified against unit-level requirements, software integration is verified against architecture, and system testing verifies the complete software system against the software requirements specification. Validation happens against user needs and intended use, typically as part of the broader device-level validation required under design controls, and it often includes usability evaluation under IEC 62366-1. Traceability matrices required by IEC 62304 tie each verification and validation record back to a specific requirement or user need.

How Do Design Verification and Validation Requirements Apply Under the QMSR?

ISO 13485 clause 7.3.6, incorporated by the QMSR, requires design verification, and clause 7.3.7 requires design validation (formerly 21 CFR 820.30(f) and (g)), including software validation, and both must be documented in the design history file. Design verification under (f) confirms that design outputs meet design input requirements, using methods like analysis, inspection, or test. Design validation under (g) confirms the device conforms to defined user needs and intended uses under actual or simulated use conditions, and it explicitly calls out software validation and risk analysis as part of that activity. Records for both must identify the design, method, date, and the individuals performing the activity.

Verification vs Validation vs Testing vs QA: What Is the Difference?

Testing is a technique used inside both verification and validation, and quality assurance is the broader system that ensures both happen consistently and are documented.

What Activities Make Up a Complete V&V Program?

A complete program layers unit, integration, system, regression, usability, and, where applicable, clinical evaluation. Unit testing checks individual functions or modules against their specifications, and integration testing checks that modules work together correctly. System testing exercises the complete software against the full software requirements specification, and regression testing reruns prior tests after any change to confirm nothing broke. Usability testing under IEC 62366-1 validates that intended users can operate the device safely and effectively, and clinical evaluation, where the intended use warrants it, provides evidence the device performs as intended in the clinical population.

How Does Software Safety Classification Change the Evidence Needed?

IEC 62304 assigns each software system a safety classification of A, B, or C based on the severity of harm a failure could cause, and that classification scales how much verification and validation evidence is expected. Class A software, where failure cannot cause injury, needs the least rigorous documentation. Class B, where failure could cause non-serious injury, requires more detailed unit and integration verification records. Class C, where failure could cause death or serious injury, requires the most rigorous verification, including detailed traceability, more extensive testing, and often independent review of test results.

What About Tool Validation and SOUP?

Any automated tool used to build, test, or verify the software needs its own validation record showing it performs its intended function reliably. Software of unknown provenance (SOUP), including open source libraries and third-party components, must be identified, and the manufacturer must assess and document the risk it introduces, even though the manufacturer did not write it. Verification activities for SOUP typically include confirming the version in use, checking known vulnerabilities, and testing the integration points where SOUP interfaces with manufacturer-written code.

Why Does Traceability From User Need to Test Result Matter?

See also: Medical Device Vulnerability Testing, Hardware Hacking Tools for Medical Device Security Testing, and Docker Containers in Medical Devices: FDA Testing.

Traceability is the mechanism that lets a reviewer confirm nothing was verified in isolation from an actual need. The chain runs from user need, to design input requirement, to design output, to verification or validation test, to a documented result. A break anywhere in that chain, a requirement with no test, or a test with no traceable requirement, is treated as unaddressed risk by both internal quality reviewers and the FDA.

What Does an FDA Reviewer Look for in a Submission?

A reviewer looks for a complete, traceable record showing every requirement was verified and every user need was validated with objective evidence. That means test protocols with pass/fail criteria defined before execution, signed and dated test results, a traceability matrix connecting requirements to tests, and a rationale for the software safety classification assigned. Reviewers also expect the design history file to show that failures found during testing were investigated, corrected, and retested, not simply logged and left open.

How Does Cybersecurity Fit Into V&V?

Security requirements must be verified the same way any other design input is verified, with documented test protocols, pass/fail criteria, and traceable results. The February 3, 2026 FDA premarket cybersecurity guidance is explicit that cybersecurity risk controls are design inputs, and a control that was never verified is functionally the same as a control that was never implemented. Penetration testing is independent adversarial evidence that a security control holds up under attack, but it is not a substitute for the manufacturer's own verification that its design inputs were satisfied.

[KEY REQUIREMENT] A third party performing penetration testing or independent assessment should never attest that a manufacturer's design inputs were satisfied. That attestation belongs to the manufacturer, based on its own verification and validation records; the third party's role is to report findings against the scope it tested, not to certify design input closure.

What an Outside Firm Can and Cannot Do for Your V&V Record

Buyers often ask whether an external security firm can simply own verification and validation. It cannot, and any vendor who says otherwise is selling something that will not hold up. Your design inputs, your requirements, and your sign-off belong to your quality system. What an outside firm adds is independent testing evidence against those requirements, which is exactly the part reviewers question when it comes only from the team that wrote the code.

Budget accordingly. The external line item is testing and evidence, usually scoped by interface count and report depth rather than by document page count, and the penetration testing cost guide sets out those drivers. The internal line item, which is usually the larger of the two, is the requirements and traceability work that only your team can do.

How Blue Goat Cyber Approaches This

Blue Goat Cyber supports manufacturers in closing the specific gap between security requirements and verifiable evidence, without ever standing in for the manufacturer's own design control sign-off. Our medical device penetration testing engagements are scoped against the manufacturer's documented security requirements, so findings map directly to the requirements a design history file needs to show were tested. We also support threat modeling earlier in the lifecycle, so security requirements exist before verification testing starts, rather than being retrofitted after the fact. Throughout, we produce reports that document what we tested and found, so the manufacturer's own quality team can complete the verification and validation record with defensible, traceable evidence.

Frequently Asked Questions

What is the difference between verification and validation in simple terms?

Verification checks that the software matches its written specification, answering "did we build it right." Validation checks that the finished software meets the actual needs of its users in its intended use environment, answering "did we build the right thing." Both require documented, objective evidence.

Does IEC 62304 require validation, or only verification?

IEC 62304 focuses primarily on verification activities within the software development lifecycle, while validation is typically addressed through the broader design control process required by regulations such as 21 CFR 820.30(g). In practice, manufacturers run both under a single integrated V&V plan so evidence stays traceable.

What is software safety classification and why does it matter for V&V?

Software safety classification under IEC 62304 sorts software into Class A, B, or C based on the potential severity of harm from a failure. Class C software, tied to death or serious injury, requires the most rigorous verification and validation evidence, while Class A requires the least.

Can penetration testing substitute for security verification?

No. Penetration testing provides independent adversarial evidence that a control holds up under attack, but the manufacturer must still verify, through its own documented process, that each security design input was implemented and functions as specified. A third party should never attest that the manufacturer's design inputs were satisfied.

What records does the FDA expect to see for software V&V?

The FDA expects test protocols with predefined pass/fail criteria, signed and dated results, a traceability matrix linking user needs, requirements, and tests, and documentation of how any failures were investigated and resolved. This evidence typically lives in the design history file.

How does SOUP or open source software get verified?

Software of unknown provenance must be identified, version-controlled, and risk-assessed, even though the manufacturer did not write it. Verification typically confirms the specific version in use, checks it against known vulnerabilities, and tests the integration points where it connects to manufacturer-written code.

CTA

Incomplete verification and validation records are one of the most common reasons FDA submissions stall. If your team needs independent testing evidence that maps cleanly to your documented security requirements, contact us to scope an engagement built around your traceability matrix, not a generic test plan.