What Are the Software Related Regulations for Medical Devices in the US?

If you are developing a medical device with software for the US market, you are stepping into one of the most tightly regulated spaces in product development. Software is no longer just a feature inside a device. For many products, it is the device. And the FDA treats it accordingly. This guide covers every major software related regulation your team needs to understand before submitting US market clearance.

1. IEC 62304: The Foundational Software Lifecycle Standard

IEC 62304 is the international standard for medical device software lifecycle processes, and the FDA formally recognises it as the expected development framework. Every company developing medical device software should be building their process around it. 

The standard classifies software into three safety classes based on the potential harm a failure could cause: 

1. Class A: No injury or only minor injury possible (for example, hospital scheduling software).
2. Class B: Non-serious injury possible (for example, a blood pressure monitoring application).
3. Class C: Serious injury or death possible (for example, radiation therapy control software). 

The class determines the depth of documentation, testing, and risk management required throughout development. A Class C item requires full traceability from requirements through architecture, design, unit testing, integration testing, and system testing.

2. QMSR 2026: The New FDA Quality System Regulation

On February 2, 2026, the FDA’s updated Quality Management System Regulation (QMSR) officially takes effect, aligning 21 CFR Part 820 more closely with ISO 13485:2016. 

This is the most significant quality system change for medical device manufacturers in a decade. 

Companies transitioning from legacy FDA QSR systems should perform a detailed gap assessment against ISO 13485:2016, particularly for software risk management, validation, supplier controls, and post-market monitoring activities.

The QMSR incorporates ISO 13485:2016 by reference, making it legally part of the FDA regulation. For software focused companies, this means design and development controls under ISO 13485 clause 7.3 now apply with explicit risk-based requirements. Software validation, design inputs and outputs, verification, and change control documentation must all align with this updated standard. A gap analysis against ISO 13485:2016 is strongly recommended for any company that was previously compliant with the old QSR. 

Under the QMSR framework, software suppliers, cloud infrastructure providers, cybersecurity maintenance activities, and outsourced software development partners are expected to fall under stronger supplier control and quality oversight processes. 

3. FDA Cybersecurity Requirements: Now Mandatory for Connected Devices

Under Section 524B of the FD&C Act, all medical device premarket submissions must now include a cybersecurity plan. This covers any device that includes software, connects to the internet, or has features susceptible to cybersecurity threats, which includes most modern medical devices. 

Key requirements include: 

1. A Software Bill of Materials (SBOM): Mandatory since October 2023 for all FDA premarket applications. It must list every commercial, open source, and off the shelf component with version details and dependency relationships.
2. A threat model identifying attack vectors, likelihood, and patient safety impact.
3. Defined processes for vulnerability monitoring, patching, and incident response post-market. 

The FDA’s current cybersecurity approach is based on the Secure Product Development Framework (SPDF), which expects cybersecurity activities to be integrated throughout the entire software development lifecycle rather than treated as a final testing activity. 

FDA reviewers increasingly expect evidence that cybersecurity risk management is continuously maintained post-market, including vulnerability monitoring, coordinated disclosure processes, and timely software patch deployment capabilities. 

Devices using third party software libraries, cloud APIs, AI models, or open source components are expected to maintain ongoing Software Bill of Materials (SBOM) updates throughout the product lifecycle. 

Cybersecurity obligations do not end at launch. Manufacturers are expected to actively monitor vulnerabilities and issue timely updates throughout the product lifecycle.

4. Software as a Medical Device (SaMD): What Qualifies and Which Pathway Applies

Standalone software designed to diagnose, treat, monitor, or mitigate a medical condition is classified as SaMD under the FDA. The intended use drives classification, not technology. A mobile app that interprets ECG data and flags arrhythmia is a medical device. A scheduling app for clinic appointments is not.  

Once classified, SaMD typically follows the 510(k) clearance pathway for moderate risk Class II devices, demonstrating substantial equivalence to a predicate. While many SaMD products follow the 510(k) pathway, some novel AI driven software products may require De Novo classification if no suitable predicate device exists.  

For AI or machine learning based SaMD, the FDA has issued guidance on Predetermined Change Control Plans (PCCPs), which allow manufacturers to plan algorithm updates post clearance without resubmitting for each change. The FDA continues to expand its regulatory framework for AI/ML enabled medical devices, with an increasing focus on algorithm transparency, bias evaluation, clinical performance monitoring, and real world learning systems.

5. Software Testing Requirements Before FDA Submission

Testing expectations for medical device software are significantly more rigorous than commercial software QA. The FDA requires documented verification and validation (V&V) evidence with full traceability from requirements to test outcomes.  

For devices with embedded software, EMC testing per IEC 60601-1-2 is also mandatory, since electromagnetic interference can cause software driven devices to behave unpredictably. Usability engineering studies per IEC 62366 are expected for any software driven user interface. 

FDA software reviews increasingly expect evidence of automated testing strategies, cybersecurity verification testing, interoperability validation, and documented management of Software of Unknown Provenance (SOUP). 

For cloud connected or AI enabled medical devices, manufacturers may also need to demonstrate data integrity validation, algorithm performance verification, and real world clinical performance monitoring strategies. 

Modern medical device software testing extends beyond functional verification and now includes resilience testing, secure update validation, penetration testing, and usability risk evaluation under real world operating conditions. 

6. AI Enabled Medical Device Software: Emerging FDA Expectations

The FDA is actively developing regulatory expectations for Artificial Intelligence (AI) and Machine Learning (ML) enabled medical devices. Manufacturers are increasingly expected to demonstrate algorithm transparency, bias management, dataset governance, clinical validation, and ongoing performance monitoring after deployment. 

AI enabled devices may also require Predetermined Change Control Plans (PCCPs) to define how future model updates will be safely implemented without repeated FDA submissions. As AI regulation evolves, manufacturers should prepare for increased scrutiny around training data quality, explainability, cybersecurity, and real world algorithm performance.