---
title: FDA Software Guidance: How US Software Regulation Differs from EU
description: FDA software regulation differs from MDR in pathway, documentation, and lifecycle. Here is the comparison for EU SaMD startups at general framing.
authors: Tibor Zechmeister, Felix Lenhard
category: FDA & International Market Access
primary_keyword: FDA software guidance EU comparison
canonical_url: https://zechmeister-solutions.com/en/blog/fda-software-guidance-eu-comparison
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# FDA Software Guidance: How US Software Regulation Differs from EU

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **FDA software regulation and EU MDR software regulation share common ancestors in the IMDRF SaMD framework, but they diverge in classification logic, submission pathway, documentation expectations, and lifecycle discipline. For an EU SaMD startup, the practical translation is that a file built for an MDR conformity assessment under Annex VIII Rule 11 and EN 62304:2006+A1:2015 is not a ready-to-submit FDA file — it is raw material that has to be re-framed against a different set of rules. This post orients EU founders to those differences at the general framing level. For specific FDA software pathway decisions, work with a US regulatory specialist.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- The MDR qualifies software as a medical device through Article 2(1) and classifies it through Annex VIII Rule 11. The FDA uses device-type classification listings and product codes rather than a rule-based classification walk.
- MDCG 2019-11 Rev.1 is the definitive EU guidance for qualification and classification of Medical Device Software (MDSW). The FDA has its own body of software guidance documents that operate under a different legal framework.
- EN 62304:2006+A1:2015 is the harmonised software lifecycle standard recognised under MDR Annex I. The FDA accepts the same standard as one acceptable way to demonstrate software lifecycle rigour, but its documentation expectations for a submission are structured differently.
- The MDR route produces a technical documentation file assessed by a Notified Body. The FDA route produces a premarket submission assessed by CDRH reviewers. The artifacts overlap substantially but are not interchangeable without re-framing.
- A SaMD that is Class IIa under MDR Rule 11 is not automatically any specific FDA class — the two classifications are computed differently and the answer is determined per device type, not per rule walk.

---

## Why EU SaMD founders keep hitting this wall

The pattern shows up in almost every first meeting with an EU software startup that has decided to also pursue the US market. The founders have done good MDR work. They have written a clean intended purpose under MDR Article 2(1). They have walked the MDCG 2019-11 Rev.1 qualification decision tree. They have landed on Class IIa under Annex VIII Rule 11. They have adopted EN 62304:2006+A1:2015 as their software lifecycle standard. They have a risk file, a software development plan, and a growing technical documentation set aimed at a Notified Body review.

Then someone asks the US question. And the founders, in good faith, answer it with the EU answer. "We are Class IIa, so we are FDA Class II. We have EN 62304:2006+A1:2015, so we have the FDA software documentation. We have MDCG 2019-11 Rev.1 qualification, so we have FDA qualification." Each of those sentences is close enough to sound right, and each of them is wrong in a way that can cost months.

The MDR and FDA both regulate software as a medical device. They draw on some of the same international groundwork — notably the IMDRF SaMD framework that influenced both. But they are different legal systems with different classification logic, different pathway structures, different documentation expectations, and different lifecycle checkpoints. A file prepared for one is raw material for the other, not a drop-in replacement. The purpose of this post is to give EU founders the orientation map so the translation work is deliberate rather than discovered the hard way.

## The FDA software regulatory framework at general level

At general framing, the FDA regulates medical device software under the same Federal Food, Drug, and Cosmetic Act that governs all medical devices in the US. Software is not carved out into a separate regime. Instead, the agency publishes guidance documents that interpret how the existing device framework applies to software — including guidance on premarket submissions for software, guidance on clinical decision support software, guidance on software as a medical device, and guidance on cybersecurity in medical devices. These guidance documents sit alongside the device classification listings maintained by CDRH.

The FDA itself — specifically the Center for Devices and Radiological Health — is the reviewer for software submissions. There is no Notified Body equivalent for most submissions. The submission pathway is the same set of three main routes that apply to hardware devices: 510(k) for devices substantially equivalent to a predicate, De Novo for novel low-to-moderate risk devices without a predicate, and Premarket Approval (PMA) for high-risk devices. Software fits into these pathways like any other device type; there is no separate "software pathway" that runs in parallel.

The practical implication for an EU founder is that the mental model for FDA software work is not "which software rule applies." It is "which device type best matches my software, what class does the FDA assign to that device type, and which pathway does that class drive." This is a fundamentally different reasoning process than walking MDR Annex VIII Rule 11.

For the broader FDA framework that sits above this software-specific post, see the FDA primer in post 601.

## Software as a medical device under FDA framing

The FDA engages with the term "Software as a Medical Device" through its participation in the IMDRF and through guidance documents that use the SaMD vocabulary. At general framing, the FDA recognises that software can itself be a medical device when its intended use meets the statutory definition of a device, and that such software is regulated under the same device framework as any other device.

What the FDA does not do is operate a rule-based classification system that walks a piece of software through a decision tree the way MDR Annex VIII Rule 11 and MDCG 2019-11 Rev.1 do. Instead, the agency relies on its classification database of device types, each identified by a regulation number and a product code, each pre-assigned to a class. A new piece of software is compared against that database. If an existing device type matches, the software inherits the class of that device type. If no existing device type matches and the risk profile is low-to-moderate, the De Novo pathway exists to create a new classification. If the risk is high and no predicate applies, PMA is typically the route.

This is the deepest structural difference between the two systems. MDR classification is computed from the software's characteristics against a set of rules. FDA classification is looked up from the software's device type against a database of prior classifications. The MDR route can produce a classification before any comparable device exists. The FDA route, for most devices, relies on comparable devices having been classified already — which is why the De Novo pathway had to be created in the first place.

For the EU side of the SaMD qualification story, post 371 and post 373 cover the MDR and MDCG 2019-11 Rev.1 approach in depth.

## Lifecycle expectations: EN 62304:2006+A1:2015 on both sides — but not identically

On the software lifecycle side, the two systems converge more than they diverge. EN 62304:2006+A1:2015 — the harmonised European standard for medical device software lifecycle processes — is recognised by the FDA as one acceptable way to demonstrate software lifecycle rigour in a US submission. The standard defines the same lifecycle activities (planning, requirements, architecture, implementation, integration, verification, release, maintenance, risk management, configuration management, problem resolution) whether the submission is going to a Notified Body under MDR Annex I or to CDRH under a 510(k).

What differs is the submission-level documentation expectation. Under the MDR, the technical documentation file is structured around MDR Annex II and III, and the software lifecycle evidence is presented as part of that structure. Under the FDA, the software documentation is presented according to the agency's guidance on premarket submissions for software, which specifies a different artifact structure — documentation level (often tied to the software's risk to patient safety), software description, risk management file, software requirements specification, architecture design chart, software design specification, software development and maintenance practices, verification and validation, revision level history, and unresolved anomalies.

The underlying engineering activities are the same. The artifact packaging is not. A startup that has built a clean EN 62304:2006+A1:2015 development file has done most of the engineering work for both systems, but still has to re-package the evidence to match the specific expectations of each submission. This is the kind of work that looks trivial from the outside and swallows weeks from the inside. Post 376 covers the MDR-side software lifecycle in detail.

The cybersecurity layer lives alongside the lifecycle layer. The MDR side is driven by Annex I requirements, MDCG 2019-16 Rev.1, and EN IEC 81001-5-1:2022. The FDA side is driven by separate FDA cybersecurity guidance. At general framing, both sides expect secure development practices across the full product lifecycle; the specific artifacts are different. See post 425 for the cybersecurity lifecycle discussion.

## Where FDA and MDR converge

The two systems share more ground than the divergences suggest.

Both treat software as a medical device when its intended use meets a medical device definition. Both expect manufacturers to run a documented software lifecycle with defined activities and produced evidence. Both accept EN 62304:2006+A1:2015 as a recognised lifecycle standard. Both expect risk management to feed the software safety classification and the lifecycle activities. Both expect cybersecurity to be designed in, not bolted on. Both expect post-market monitoring of the software after release. Both treat intended purpose / indications for use as the pivot point of the regulatory analysis, and both penalise drift between marketing claims and the filed intended purpose.

For an EU startup, the convergence means the underlying engineering work is not duplicated across the two submissions. A well-built EN 62304:2006+A1:2015 file, a risk management file under EN ISO 14971:2019+A11:2021, a QMS under EN ISO 13485:2016+A11:2021, and a clean intended purpose all carry weight on both sides. The work is not wasted. It is re-purposed.

## Where FDA and MDR diverge

The divergences are where the translation work happens.

**Classification logic.** MDR Annex VIII Rule 11 is a rule-based walk. FDA classification is a device-type lookup. The two produce different answers for the same software, and the MDR class does not predict the FDA class.

**Guidance architecture.** MDCG 2019-11 Rev.1 is the single anchor document for SaMD qualification and classification in the EU. The FDA does not have a single equivalent; it has a portfolio of software guidance documents covering different aspects (premarket submissions, clinical decision support, cybersecurity, change management, device software functions) that must be read together.

**Submission structure.** The MDR technical documentation file is built to the Annex II / III structure and reviewed by a Notified Body. The FDA submission is built to the agency's guidance on premarket software documentation and reviewed by CDRH. The content overlaps substantially; the packaging does not.

**Predicate logic.** The 510(k) pathway requires a predicate device, which is a concept the MDR does not use. Selecting the right predicate is the single highest-leverage strategic decision in most 510(k) software submissions. Nothing in the MDR prepares a founder for this work.

**Change management.** The MDR treats changes through significant change rules that trigger re-assessment by the Notified Body. The FDA treats changes through its own guidance on when software modifications require a new 510(k). The thresholds are different, and the documentation trails are different.

**Post-market obligations.** MDR PMS under Article 83 and MDCG 2025-10 is structured around the PMS plan, the PMS report, and the PSUR for higher classes. The FDA post-market system uses different reporting thresholds and different artifact structures. Both require vigilance for adverse events; the specific reporting channels and deadlines differ.

Post 602 walks through the broader FDA-versus-MDR comparison across classification, pathway, and QMS; this post is the software-specific cut of that comparison.

## Common founder confusions

**"We are Class IIa under Rule 11, so we are FDA Class II."** There is no deterministic mapping. A Rule 11 Class IIa device can land in FDA Class II, but it can also land in FDA Class III, and the answer depends on the FDA's device-type classification for the specific product, not on the MDR rule walk.

**"Our EN 62304:2006+A1:2015 file is our FDA software documentation."** The engineering work mostly transfers. The packaging does not. An FDA submission expects the documentation restructured to match the agency's guidance on premarket software documentation.

**"MDCG 2019-11 Rev.1 qualifies us for both markets."** MDCG 2019-11 Rev.1 is the EU authority for MDSW qualification under MDR Article 2(1). It has no standing in an FDA submission. The FDA applies its own reasoning through its own guidance portfolio.

**"We do not need a US regulatory specialist because our EU consultant knows software."** EU software regulatory expertise and FDA software regulatory expertise are different specialisations. A good EU sparring partner will tell you this directly and recommend a US specialist when the US work begins. A partner who claims to cover both at expert depth is overstating.

**"The FDA is faster than the MDR for software, so we should go US-first."** The timelines depend on the pathway, the device, and the specific reviewers on both sides. For some software products, a well-prepared 510(k) moves faster than an MDR Class IIa conformity assessment under current Notified Body capacity. For others, particularly novel software pursuing De Novo, the FDA side is longer. The answer is per device, not per system.

## The Subtract to Ship angle for dual-market SaMD

Subtract to Ship applied to dual-market SaMD work has one central move: do the underlying engineering and regulatory work once, to the higher of the two standards on each specific element, and then package that work twice for the two different submission structures. See post 65 for the full framework.

The pattern that wastes the most time is doing the engineering work twice because the two submission structures were treated as two separate projects. The pattern that creates the most compliance risk is doing the engineering work once against the lower of the two standards and then discovering, late, that the other submission needs more. The discipline is to identify, per element — lifecycle, risk, cybersecurity, clinical evidence, QMS — which system has the higher expectation, build to that expectation once, and then restructure the documentation twice.

For SaMD specifically, the elements that most often need a higher bar are the risk management file, the cybersecurity file, and the software documentation structure. Build those to the higher standard from the start and the translation cost at submission time drops substantially. Post 612 covers dual-market planning for SaMD in more depth.

## Reality Check — Where do you stand on dual-market software strategy?

1. Do you know which FDA device-type classification is the closest match to your software, including the product code and regulation number?
2. Have you identified candidate FDA predicate devices for a 510(k), or confirmed that De Novo is the likely route because no predicate exists?
3. Is your software lifecycle documentation structured to be re-packaged for an FDA premarket submission, or only for an MDR technical documentation file?
4. Have you read the relevant FDA guidance on premarket submissions for software, or are you relying only on MDCG 2019-11 Rev.1?
5. Does your risk management file support both MDR and FDA expectations, or only one?
6. Is your cybersecurity file aligned with both MDR Annex I and the FDA's cybersecurity guidance?
7. Do you have a US regulatory specialist lined up for the FDA-specific work, or are you assuming your EU support covers both markets?

Fewer than five clear yes answers means the US-side work is not yet a plan.

## Frequently Asked Questions

**Is MDCG 2019-11 Rev.1 used by the FDA?**
No. MDCG 2019-11 Rev.1 is the European Commission's guidance on qualification and classification of Medical Device Software under MDR Article 2(1) and Annex VIII Rule 11. It has no standing in a US submission. The FDA applies its own portfolio of software guidance documents within the US device framework.

**Does the FDA accept EN 62304:2006+A1:2015?**
At general framing, yes — the FDA recognises EN 62304:2006+A1:2015 as one acceptable way to demonstrate a documented software lifecycle. The same engineering file built to EN 62304:2006+A1:2015 for an MDR submission can form the basis of the software lifecycle evidence in a US submission, but the documentation has to be re-packaged to match the FDA's premarket software documentation expectations.

**Does a Class IIa MDR SaMD automatically become FDA Class II?**
No. The two classification systems are structurally different. MDR Annex VIII Rule 11 is a rule walk; FDA classification is a device-type lookup. The answer for any specific software depends on which FDA device-type classification applies, which can produce Class I, Class II, or Class III regardless of the MDR outcome.

**Can I use my MDR technical documentation as an FDA submission?**
Not directly. The underlying content overlaps substantially — risk management, lifecycle, verification and validation, clinical evidence — but the submission is structured to a different template and reviewed under a different framework. Expect re-packaging work, not simple resubmission.

**Where does this post stop and where should I talk to an FDA specialist?**
This post gives the EU-founder orientation map at general framing. For specific FDA software pathway decisions — predicate selection, pre-submission meeting strategy, documentation level calls, cybersecurity artifact structure, change-control determinations — work with a US regulatory specialist who practices inside the FDA system daily.

## Related reading

- [FDA Regulation of Medical Devices: A Primer for EU Startups](/blog/fda-regulation-medical-devices-primer-eu-startups) — the general FDA primer this software-specific post builds on.
- [What Is Software as a Medical Device (SaMD)? The MDR Definition for Startups](/blog/what-is-software-as-medical-device-samd-mdr) — the MDR-side pillar for SaMD.
- [SaMD vs SiMD — Software as a Medical Device vs Software in a Medical Device](/blog/samd-vs-simd-distinction) — the distinction that underlies both systems.
- [Intended Purpose for SaMD — the Strategic Decision](/blog/intended-purpose-samd-strategic-decision) — the pivot point for both MDR and FDA software analysis.
- [MDCG 2019-11 Rev.1 — What the Software Guidance Actually Says](/blog/mdcg-2019-11-software-guidance) — the EU anchor guidance for SaMD qualification.
- [The MDR Software Lifecycle and EN 62304:2006+A1:2015](/blog/mdr-software-lifecycle-iec-62304) — the MDR-side lifecycle deep dive.
- [MDR Classification Rule 11 for Software — The Short Version](/blog/mdr-classification-rule-11-software) — the Rule 11 entry-level spoke.
- [Cybersecurity Across the Software Lifecycle](/blog/cybersecurity-software-lifecycle) — the cybersecurity layer on both sides.
- [MDR vs FDA: the core differences every founder should know](/blog/mdr-vs-fda) — the broader comparison this software post sits under.
- [Dual-Market SaMD Planning: EU and US in Parallel](/blog/dual-market-samd-planning) — the planning companion to this comparison.
- [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) — the methodology applied here to dual-market software work.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(1) and Annex VIII, Rule 11. Official Journal L 117, 5.5.2017.
2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).
4. U.S. Food and Drug Administration — Center for Devices and Radiological Health (CDRH), software-related guidance portfolio and device classification database. Referenced at the general framing level only.

---

*This post is part of the FDA & International Market Access series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. A note on the limits of our expertise: Tibor's authority is in the EU MDR, MDCG 2019-11 Rev.1, EN 62304:2006+A1:2015, and the Notified Body system. The FDA content in this post is at general framing only. For specific FDA software pathway decisions, work with a US regulatory specialist who practices inside the FDA system daily. This post is the orientation map. The specialist is the execution.*

---

*This post is part of the [FDA & International Market Access](https://zechmeister-solutions.com/en/blog/category/fda-international) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*