V&V and Regression Testing for Medical Device Cybersecurity (FDA §524B)

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.

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

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.

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: Testing Medical Devices with Malformed and Unexpected Inputs
• Input Validation in Medical Devices: Preventing Cyber and Safety Risks