Medical Device Software Regulation: A Complete Guide

Software now diagnoses, monitors, and guides treatment, and when it does, it is regulated as a medical device. The FDA reports that it has authorized over 1,600 AI-enabled medical devices for the US market, and the EU regulates medical device software under the Medical Device Regulation. For HealthTech and MedTech teams, regulation shapes the product from the first line of the intended use statement to postmarket monitoring. This guide brings the topic together: how to tell whether your software is a device, how it is classified in the US and EU, the routes to market, the engineering standards behind a compliant product, and what changes when the software uses AI. Each section links to a detailed guide.

Is your software a medical device?

Intended use decides. Software intended to diagnose, treat, mitigate, monitor, or prevent disease is generally a medical device, whether it runs on its own as Software as a Medical Device (SaMD) or inside hardware. The FDA's Policy for Device Software Functions and Mobile Medical Applications explains which software functions the agency focuses on and which lower-risk functions it does not intend to enforce requirements against.

Two important exclusions apply in the US. Clinical decision support software that meets all four criteria in section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act is not a device, and products intended only for general wellness fall outside device regulation under the FDA's General Wellness guidance, updated in January 2026. Marketing claims matter: a wellness app that starts claiming to detect a condition can become a device without any code change.

• SaMD classification under the FDA walks through device status, CDS and wellness exclusions, and IMDRF risk categories.
• AI in clinical decision support explains how CDS systems work and how they are regulated.
• Healthcare mobile apps covers FDA, HIPAA, FTC, and accessibility rules for apps.

How classification works in the US and EU

Both systems classify by risk, but they use different rules and the classes do not map one to one.

	United States (FDA)	European Union (MDR)
Legal basis	Federal Food, Drug, and Cosmetic Act and 21 CFR	Regulation (EU) 2017/745, applied since May 26, 2021
Classes	Class I, II, III	Class I, IIa, IIb, III
Software rule	Classification regulations and product codes, informed by the IMDRF SaMD framework	Annex VIII Rule 11, with MDCG 2019-11 guidance (revised June 2025)
Typical result for clinical decision software	Often Class II	At least Class IIa, rising to IIb or III with severity
Who reviews	FDA, unless the device is exempt	A notified body for Class IIa and above

For the detail, see our guides to FDA SaMD classification and EU MDR Rule 11.

Routes to market in the US

Device class sets the usual FDA route. Most Class I devices are exempt from premarket review, most Class II devices need 510(k) clearance against a predicate, novel low-to-moderate-risk devices without a suitable predicate can use De Novo, and most Class III devices need Premarket Approval (PMA). The FDA's premarket software guidance asks for Basic or Enhanced documentation depending on the risk of the software function, which is assessed separately from IEC 62304 safety classes. Our guide to FDA pathways for AI-enabled medical devices explains how to choose between 510(k), De Novo, and PMA.

The engineering standards behind a compliant product

Area	Standard or rule	What it requires of software teams	Our guide
Quality system	ISO 13485:2016 and the FDA QMSR	Design controls, document control, supplier and change management inside a quality system. The QMSR, effective February 2, 2026, incorporates ISO 13485:2016 by reference	ISO 13485 design controls
Software lifecycle	IEC 62304:2006 with Amendment 1:2015	Assign safety Class A, B, or C and apply the matching planning, design, verification, and maintenance rigor	IEC 62304 safety classification
Risk management	ISO 14971:2019	Identify hazards across the lifecycle and show how each risk is controlled	AI in MedTech engineering
Usability	IEC 62366-1	Test how users interpret and act on the software's output	AI in MedTech engineering
Cybersecurity	FD&C Act section 524B	Since March 29, 2023, premarket submissions for cyber devices must include a vulnerability management plan and a software bill of materials	AI in MedTech engineering

What changes when the device uses AI

AI adds work on top of the standards above: documenting training and test data, versioning models, planning for updates, and monitoring performance after release.

• Planned model updates. A predetermined change control plan lets the FDA review planned modifications up front, so changes within the plan do not each need a new submission.
• Postmarket monitoring. Track drift, subgroup performance, and real-world use. Our guide to monitoring clinical AI in production covers what to measure.
• EU AI Act. AI that is a medical device, or a safety component of one, and needs notified body assessment is high-risk under the EU AI Act. Following the 2026 amendments, those obligations apply from August 2, 2028.
• Governance. Clinical AI also needs organizational oversight; see our healthcare AI governance and compliance guide.

A practical roadmap for medical device software teams

1. Write the intended use statement. It drives device status, classification, evidence, and labeling.
2. Classify in every target market. Record the FDA class and route, the EU Rule 11 class, and the reasoning behind each.
3. Set up the quality system early. Design controls are far harder to reconstruct after development.
4. Assign the IEC 62304 safety class and run ISO 14971 risk management alongside design, not at the end.
5. Design for cybersecurity and integration. Threat modeling, an SBOM, and secure interfaces belong in the architecture.
6. Plan clinical evidence and postmarket monitoring together, including a change control plan if the software uses AI that will be updated.

Guides in this cluster

• SaMD Classification FDA: Class I, II or III?
• EU MDR Rule 11: How Medical Device Software Is Classified
• FDA Pathways for AI-Enabled Medical Devices
• IEC 62304 Software Safety Classification Explained
• ISO 13485 Design Controls for Software Teams
• Predetermined Change Control Plan: FDA Guide for AI Devices
• AI in MedTech: The Engineering Standards Behind AI Medical Device Software
• AI in Clinical Decision Support: How CDS Systems Work
• Monitoring Clinical AI in Production: Drift, Performance and Alert Fatigue

For HIPAA, business associate agreements, SOC 2, and HITRUST, see our HealthTech Security and Compliance guide.

Conclusion

Medical device software regulation follows a clear sequence: decide whether the software is a device, classify it in each market, choose the route to market, and build it inside a quality system using IEC 62304, ISO 14971, usability, and cybersecurity requirements. AI adds data documentation, planned change control, and postmarket monitoring, plus EU AI Act obligations from August 2028. Teams that settle intended use and classification first, and build the evidence as they develop, reach market faster and with fewer surprises. To build compliant medical device software, explore Ekipa's SaMD solutions or book a consultation.

Frequently asked questions

When is software considered a medical device?

When its intended use is to diagnose, treat, mitigate, monitor, or prevent disease. In the US, clinical decision support that meets all four statutory criteria and products intended only for general wellness are excluded.

What is the difference between SaMD and software in a medical device?

SaMD performs its medical purpose on its own, without being part of a hardware device. Software in a medical device is part of a hardware device, such as firmware in an infusion pump, and is reviewed with that device.

Do US and EU classes match?

No. The FDA uses Classes I to III with product codes and predicates, while the EU MDR uses Classes I, IIa, IIb, and III under Rule 11. Clinical decision software often lands in FDA Class II and EU Class IIa or higher, but each market needs its own analysis.

Which standards apply to medical device software?

The core set is ISO 13485 for the quality system, IEC 62304 for the software lifecycle, ISO 14971 for risk management, and IEC 62366-1 for usability. US cyber devices must also meet section 524B cybersecurity requirements.

How are AI model updates handled after clearance?

In the US, a predetermined change control plan authorized with the device lets you make the modifications it describes without a new submission for each one. Changes outside the plan usually need a new regulatory review.