Your FDA submission deadline is set. Your regulatory affairs lead has handed the engineering team a requirements document, and now the question lands on your desk: how do you actually structure the testing? Not the theory. The protocols, the documentation artifacts, the traceability, the firmware validation. Every regulatory guide online tells you what needs to be tested. None of them tell you how a real QA team operationalizes it under a hard deadline.
This post addresses the software, firmware, and connected-device testing layers specifically. If your device includes embedded software, companion apps, wireless communication, or sensor-driven firmware, this is the layer where most submission packages fall short, and where FDA additional information requests originate.
TL;DR
- FDA software submission evidence requires traceable documentation linking every requirement to a test case and a test result, not just passing tests.
- IEC 62304 software lifecycle classification determines how much validation evidence your submission package must include.
- Connected and IoT medical devices require layered testing across firmware, hardware-software synchronization, and cybersecurity simultaneously.
- FDA’s 2023 Omnibus provisions made cybersecurity testing a mandatory premarket requirement, not an optional risk control.
- Developer-led QA during a submission sprint introduces the exact defect patterns that generate FDA additional information letters.
What FDA Software Submission Evidence Actually Requires from Your QA Team
The FDA is not evaluating test results in isolation. Reviewers evaluate the system that produced those results: the traceability between design inputs and test cases, the completeness of defect documentation, and the evidence that your software lifecycle process is repeatable and controlled.
The FDA’s guidance document Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (updated 2023) and the parallel IEC 62304 standard for medical device software lifecycle processes define the evidentiary bar. Per Greenlight Guru’s State of Medical Device Industry report, nearly 40 percent of FDA additional information requests cite deficiencies in software documentation, not in the device’s physical performance. Your QA process needs to produce artifacts that hold up under that level of scrutiny.
The Five Testing Layers Your Submission Package Must Cover
Step 1: Establish Your Software Classification Under IEC 62304 and FDA Guidance
IEC 62304 assigns your software one of three safety classes based on the severity of harm a software failure could cause. Class A covers software where failure cannot contribute to a hazardous situation. Class B covers software where failure can contribute to a hazardous situation that is not serious. Class C covers software where failure can contribute to a serious injury or death.
Your classification drives everything downstream. Class C software requires full unit, integration, and system testing with complete traceability and anomaly resolution records. Class A requires significantly less. Get this classification wrong and your submission package will be built on the wrong evidentiary foundation.
Work with your regulatory affairs lead to document the classification rationale formally. That rationale becomes part of your Software Development Plan, which the FDA expects to see in your submission package.
Step 2: Build a Traceability Matrix That Links Requirements to Test Evidence
A traceability matrix is the connective tissue of your submission package. It maps every software requirement in your Software Requirements Specification to at least one test case, and every test case to a documented test result. If a requirement has no corresponding test case, the FDA reviewer will treat it as untested. If a test case has no documented result, it did not happen.
Build the matrix as you write test cases, not after testing is complete. Retroactive traceability is a warning sign to reviewers and a significant rework burden for your team. Your QA tool of choice (Jira with Xray, Zephyr, or a dedicated ALM platform) should generate this matrix as a living artifact throughout the sprint cycle, not as a one-time export before submission.
Step 3: Execute Functional and Regression Testing Against the Design History File
Your Design History File (DHF) contains the design controls that govern the device’s development. Functional testing during the submission sprint is not exploratory testing. It is systematic verification that the software meets each design input requirement documented in the DHF.
Regression testing must cover the full validated baseline, not just recently modified modules. For connected devices with companion mobile or web applications, regression coverage must span the full user workflow: device pairing, data transmission, alert logic, and clinical data display. Gaps in regression coverage are gaps in submission evidence.
Step 4: Validate Firmware and Hardware-Software Synchronization
This is where software-only QA teams consistently miss coverage. Connected medical devices depend on firmware that manages sensor data acquisition, wireless communication protocols, power management, and device state transitions. If the firmware and the application software are not tested together under real operating conditions, you will not catch the failure modes the FDA cares about most.
Hardware, IoT & Firmware Testing at the submission level means scripted test scenarios that exercise the full hardware-software interaction: what happens when firmware receives a corrupted data packet, when a wireless connection drops mid-transmission, when a sensor calibration value falls outside the validated range. These are not edge cases. They are exactly the scenarios FDA reviewers look for in submission evidence.
Owlet faced this challenge directly during a simultaneous firmware update and hardware launch: synchronized testing across wearables and cameras was the critical gap, and closing that gap cut their release time by 54 percent while intercepting over 400 critical bugs before the product reached patients.
Step 5: Run Cybersecurity Testing to Satisfy FDA’s 2023 Omnibus Provisions
The Consolidated Appropriations Act of 2023 added Section 524B to the FD&C Act, requiring sponsors of cyber devices to submit a software bill of materials (SBOM), a plan for postmarket cybersecurity monitoring, and evidence of security testing as part of any premarket submission filed after March 29, 2023. This is not optional and it is not satisfied by a penetration test report from a general IT security firm.
Security and DevSecOps testing for a connected medical device submission means validating authentication mechanisms, encrypted data transmission (in transit and at rest), session management, input validation against injection attacks, and secure firmware update integrity. Your cybersecurity test evidence must align with FDA’s 2023 guidance document Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. Per FDA CDRH 2024 performance data, cybersecurity deficiencies now appear in a growing share of refuse-to-accept decisions for connected device submissions.
Where Developer-Led QA Breaks Down During the Submission Sprint
The submission sprint concentrates pressure at exactly the wrong point in the development cycle. Feature work is nominally complete, the regulatory deadline is fixed, and the engineering team is expected to produce test protocols, execute regression suites, resolve defects, update the traceability matrix, and prepare DHF documentation simultaneously.
Developers write test cases against their own code. They are too close to their own implementation to test it objectively, and they will not catch the failure modes that emerge from how a system behaves under conditions the original developer did not consider. Every scenario-based session on a clinical workflow, every firmware stress test, every cross-platform regression run gets deprioritized against the next defect fix.
The result is shallow coverage, missing traceability entries, and defect patterns that surface in FDA additional information letters months after the submission is filed. An AI letter does not just delay clearance. It requires your team to halt other product work, reconstruct test evidence, and resubmit, often extending the timeline by six months or more.
What a Dedicated QA Pod Delivers That an Internal Team Cannot Replicate Under Deadline Pressure
A dedicated QA team running parallel to the development sprint does not compete with the engineering roadmap for attention. Outpost QA’s nearshore QA pods integrate directly into the sprint cycle in the same timezone as US-based medtech teams, with no communication friction and no context-switching cost for the development team.
What that model delivers during a submission sprint is specific: QA engineers who own the traceability matrix, write and execute test protocols against the DHF, and document defects in the format FDA reviewers expect. Developers stay on the code. QA owns the evidence. The submission package reflects a controlled, documented process rather than a scramble.
If you are building your FDA submission testing plan and need to structure the software, firmware, and cybersecurity layers without pulling your engineering team off the roadmap, speak with an Outpost QA hardware and firmware testing specialist about designing your submission sprint.
Frequently Asked Questions
What is the difference between verification and validation in an FDA medical device software submission?
Verification confirms that the software meets its specified requirements. Validation confirms that the software fulfills its intended use in the actual use environment. FDA expects evidence of both. Verification is demonstrated through unit, integration, and system testing against the Software Requirements Specification. Validation is demonstrated through human factors testing or clinical simulation that shows the device performs as intended when used by the intended user population.
Does FDA require automated testing evidence for medical device software submissions?
FDA does not mandate automated testing specifically, but automated regression evidence is acceptable as part of software validation documentation when it is traceable to requirements and the automation framework itself is validated. The key requirement is that test results are reproducible, documented, and linked to specific design inputs. Automated test outputs that meet those criteria can strengthen a submission package by demonstrating systematic, repeatable coverage.
Which premarket submission pathway requires the most software testing documentation?
A Premarket Approval (PMA) application, used for Class III high-risk devices, requires the most comprehensive software documentation, including full design controls, software architecture documentation, complete traceability, anomaly resolution records, and a validated software lifecycle process. A 510(k) submission for a Class II device with software requires a level of documentation proportional to the software’s safety classification under IEC 62304, ranging from basic to complete documentation depending on the Class A, B, or C designation.
How does FDA define a “cyber device” for the 2023 Omnibus cybersecurity requirements?
Under Section 524B of the FD&C Act, a cyber device is a device that includes software validated, installed, or authorized by the sponsor; the ability to connect to the internet; and technological characteristics that could be vulnerable to cybersecurity threats. Most connected medical devices with firmware, Bluetooth, Wi-Fi, or cellular connectivity qualify. If your device meets this definition and your premarket submission was filed after March 29, 2023, cybersecurity documentation including an SBOM is required.
What happens if the FDA issues an additional information request on our software documentation?
An additional information (AI) letter requires you to respond with the requested evidence before the FDA resumes its substantive review. Response timelines vary, but an AI letter effectively pauses the review clock and requires your engineering and regulatory teams to reconstruct or supplement documentation that should have been in the original submission. The most common software-related AI letter triggers are missing traceability between requirements and test cases, incomplete anomaly resolution records, and insufficient cybersecurity documentation for connected devices.
