V&V and Regression Testing for Medical Device Cybersecurity

Verification, validation, and regression testing are three of the most overloaded words in MedTech engineering - and three of the most consistently misapplied in FDA cybersecurity submissions. Reviewers in 2026, working under Section 524B of the FD&C Act, the September 2023 FDA premarket cybersecurity guidance, IEC 62304, and IEC 81001-5-1, expect every cybersecurity claim in your premarket submission to trace back to a verification activity, a validation activity, and a regression-testing strategy that survives the device's full lifecycle.

This guide consolidates how those three activities relate, where they sit inside your SPDF, and what evidence belongs in your 510(k), De Novo, or PMA package.

Key Takeaways

• Verification: Confirm security controls are built correctly.
• Validation: Confirm the right security controls are built.
• Regression testing: Ensure updates do not break controls.
• The FDA expects traceability across these activities.
• Evidence maps to Section 524B and IEC 81001-5-1.
• Inadequate traceability is a common submission deficiency.

Table of Contents

• Key Takeaways
• The Three Activities, Defined for Cybersecurity
• Verification: Proving the Control Was Built Correctly
• Validation: Proving the Right Controls Were Built
• Regression Testing: The Activity Most Submissions Skip
• Where These Sit Inside the SPDF
• What Belongs in Your Premarket Submission
• How Blue Goat Cyber Helps
• Related FDA & cybersecurity guides

Why this matters

The security of medical devices directly impacts patient safety, making verification, validation, and regression testing fundamental requirements. Without these activities, devices risk vulnerabilities that could lead to data breaches, device malfunction, or unauthorized access, directly endangering patients. The FDA's 'Cybersecurity in Medical Devices' Final Guidance, dated February 3, 2026, explicitly mandates these rigorous testing protocols for premarket submissions. Device manufacturers must demonstrate traceability between cybersecurity requirements, design, implementation verification (e.g., against IEC 62443 standards), validation of their effectiveness (aligned with ISO 14971 risk management), and continuous regression testing throughout the product lifecycle. This ongoing assurance is critical, especially as devices connect to complex network environments. Inadequate testing or a lack of clear traceability often leads to significant delays in regulatory approval and can result in costly postmarket remediation efforts.

The Three Activities, Defined for Cybersecurity

Activity	Question Answered	§524B / SPDF Role
Verification	"Did we build the security control correctly?"	Each security requirement traced to a test that proves the implementation matches the design
Validation	"Did we build the right security controls?"	Evidence the controls actually mitigate the threats in your threat model and the patient harms in your ISO 14971 risk file
Regression Testing	"Did our last change quietly break a control?"	Continuous evidence - premarket and postmarket - that updates do not weaken the security posture

Most deficiency letters in 2026 are not about missing controls. They are about missing traceability between these three layers.

Verification: Proving the Control Was Built Correctly

For cybersecurity, verification typically includes:

• SAST (static analysis) - every flagged finding triaged with disposition and CAPA linkage
• SCA (software composition analysis) - reconciled against the SBOM, with VEX statements for non-exploitable CVEs
• Unit tests for security-relevant code paths (auth, crypto, input validation, audit logging)
• Configuration verification - secure boot enabled, debug interfaces disabled in production, default credentials removed
• Cryptographic verification - algorithm/key-size checks against your cryptographic inventory

Each of these maps to a security requirement → test case → result row in your traceability matrix. Reviewers literally read this matrix.

Validation: Proving the Right Controls Were Built

Validation is where most submissions are weakest. Validation evidence for cybersecurity comes from:

• Penetration testing by an independent team, scoped to the full system
• DAST and protocol fuzzing against external interfaces
• Threat-model-driven test cases - every STRIDE element produces at least one test
• Patient-safety scenario testing - explicit attempts to trigger the harms enumerated in your ISO 14971 file
• Negative-path testing - what happens when an authentication failure is repeated 10,000 times? Does the audit log fill the disk?

Validation evidence is what proves your controls actually work against a thinking adversary, not just that they exist.

Regression Testing: The Activity Most Submissions Skip

Regression testing for cybersecurity is mandatory but rarely documented well. The 2026 FDA expectation is that every release - premarket and postmarket - runs an automated regression suite that re-executes:

1. Authentication and authorization tests - privilege boundaries don't quietly drift
2. Cryptographic conformance tests - algorithms haven't been swapped or weakened
3. SBOM diff + VEX re-evaluation - new components are triaged before release
4. Known-finding re-tests - every closed pen-test finding is re-run after each significant change
5. Update-mechanism integrity tests - signed update verification, rollback protection, and recovery paths

Regression evidence is what reviewers ask for in postmarket Section 524B(b)(1) plans. Without it, a vulnerability disclosure 18 months after clearance becomes a recall trigger instead of a routine patch.

Where These Sit Inside the SPDF

See also: De Novo Cybersecurity Requirements: What the FDA Expects, FDA Cybersecurity Major vs Minor Deficiency: How Reviewers Grade Findings, and FDA Cybersecurity Deficiencies in PMA Submissions: AI Requests, Major Deficiencies, and Complete Response Letters.

Mapped to IEC 81001-5-1:

SPDF Activity	Verification	Validation	Regression
Security requirements	Requirements → test traceability	Threat-model → requirement linkage	Re-validation of requirement coverage after change
Secure design	Design review	Architecture validation	Architecture diff review
Secure implementation	SAST, SCA, unit tests	Code review against threat model	Automated re-run of SAST/SCA in CI
Verification	Per-requirement test results	-	Regression suite execution
Validation	-	Pen test, fuzz, scenario tests	Re-run on each release
Defect management	CAPA evidence	Root-cause linkage to threat model	Re-test of every closed defect
Update management	Update integrity unit tests	Update integrity scenario tests	Update mechanism regression after every firmware release

The single deliverable that ties this together is the traceability matrix: requirement → design → implementation → verification test → validation test → regression coverage → CAPA disposition.

What Belongs in Your Premarket Submission

For each cybersecurity control:

• The requirement (with §524B subsection mapping where applicable)
• The threat-model element it addresses
• The verification test result
• The validation test result (typically the pen-test report citation)
• The regression-suite identifier and last-run date
• The residual risk acceptance, signed by the named risk owner

Submissions that present this consistently across every control clear the first round. Submissions that present pen-test results without verification traceability - or verification results without validation - almost always draw an AI request or hold letter.

How Blue Goat Cyber Helps

Our pen-test engagements deliver verification, validation, and regression-suite evidence in a single coherent package, mapped to §524B subsections, SPDF activities, and your ISO 14971 risk file. Findings come with CAPA-ready dispositions and regression test cases your team can run on every subsequent release.

Schedule a discovery session → to scope the V&V coverage for your device.

FAQ

What is verification in medical device cybersecurity?

Verification ensures that security controls are implemented precisely as designed. Activities include static analysis, software composition analysis, unit tests for security features, and configuration checks to confirm correct building of controls.

How does validation differ from verification for device cybersecurity?

Validation demonstrates that the implemented security controls are effective against real threats and prevent identified patient harms. This differs from verification, which only confirms correct implementation. Validation often involves penetration testing and threat-model-driven test cases.

Why is regression testing critical for FDA cybersecurity submissions?

Regression testing is critical because it provides continuous evidence that new software versions or updates do not negatively impact the device's existing security controls. The FDA requires this to ensure cybersecurity posture is maintained across the device's entire lifecycle.

What evidence should be included for FDA premarket cybersecurity submissions?

Submissions should include the security requirement, its associated threat-model element, verification test results, validation test results (e.g., pen-test report citation), the regression-suite identifier, and residual risk acceptance for each control.

Does the FDA accept third-party testing for V&V activities?

Yes, third-party testing, such as independent penetration tests, provides crucial validation evidence. Such tests demonstrate external verification of control effectiveness against a thinking adversary, which is often a challenge for internal teams.

How does the traceability matrix support V&V and regression testing?

The traceability matrix links requirements to design, implementation, verification tests, validation tests, regression coverage, and CAPA. This document helps the FDA reviewers understand the complete lifecycle of each security control.

Related FDA & cybersecurity guides

• FDA Section 524B cybersecurity requirements explained
• SBOM vulnerability management for medical devices
• VEX document guide for FDA submissions
• FDA deficiency-letter response service
• STRIDE threat modeling for medical devices

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.

Continue the Verification & Validation series

Dive deeper with these companion articles:

• Verification & Validation in Medical Device Software
• A Comprehensive Guide to Software Testing for Medical Devices
• Risk-Based Testing for Medical Device Software
• Abuse and Misuse Cases
• Input Validation in Medical Devices