Comparison
EU MDR vs FDA software requirements
Both regimes read your statement of intended use, for opposite purposes. The EU classifies from it under Annex VIII Rule 11 and decides whether a notified body ever opens your file. In a 510(k), FDA compares it with the predicate's, as the intended use limb of substantial equivalence under section 513(i) of the FD&C Act. One wording cannot be tuned for both.
- Compared
- EU MDR software requirements and FDA premarket software requirements
- Written for
- For a CEO
- What follows from it
- The test runs can serve both files. The arguments wrapped around them cannot, because the EU scopes the package from the class your own claim produces and FDA scopes it from a documentation level and a predicate. Decide the claim once, in front of both readers.
What does a company selling into both markets end up paying for twice?
You pay twice for the written reasoning. One test campaign can produce the evidence for both files, and almost nothing in either regime lets the reasoning a reader wants attached to it carry across.
| What you produce once | What the European file does with it | What the FDA file does with it |
|---|---|---|
| The statement of intended use | Classifies the product under Annex VIII Rule 11, which decides whether a notified body enters at all | In a 510(k), is compared with the predicate's under the intended use limb of substantial equivalence, section 513(i) of the FD&C Act |
| The list of platforms you claim | Sets the coverage that Annex II Section 6.1(b) expects, because that section keys evidence to the manufacturer's own information | Enters the file as part of the proposed labels, labeling and advertisements required by 21 CFR 807.87 |
| Your security work | Appears as the information security limb of GSPR 17.2 and as the minimum IT security measures GSPR 17.4 makes you state | Becomes filed documents under section 524B of the FD&C Act: a bill of materials and a postmarket vulnerability plan |
| Your test records | Are rolled up into the process description and summary results of Annex II Section 6.1(b) | Are read against IEC 62304 Edition 1.1, the text FDA recognises as a complete standard |
| The gaps you did not close | Have to carry a written rationale, which Section 6.1(b) requires where no new testing was undertaken | Are met by the provision in 807.87 for any additional information FDA requests |
On the European side an absence you have explained is part of a complete file. On the US side an absence is a question, and the question arrives after you filed, on the reviewer's calendar rather than yours.
Which sentence do both regulators read, and when is it written?
The intended use sentence, and it is written by whoever drafts the website. Article 2(12) of Regulation (EU) 2017/745 builds the intended purpose from the label, the instructions for use, promotional or sales materials or statements, and what the manufacturer specified in the clinical evaluation. Annex VIII Rule 11 then classifies from that purpose: software providing information used to take a decision with a diagnostic or therapeutic purpose starts at class IIa and rises with the harm the decision may cause.
Section 513(i) of the FD&C Act, 21 U.S.C. 360c(i), starts from the same sentence and pulls in the opposite direction. Substantial equivalence needs the same intended use as the predicate, and then either the same technological characteristics or information demonstrating the device is as safe and effective as a legally marketed device without raising different questions of safety and effectiveness.
The conflict lands inside one sentence. Broaden the claim so it reaches a predicate and you may have climbed a limb of Rule 11. Narrow it to hold a European class and the sameness limb of 513(i) gets harder to argue. The wording is settled long before either regulatory owner is in the room, usually by a launch page nobody filed anywhere.
How the European half of that decision is made, rule by rule, is set out on EU MDR software requirements. The US half, and which of your two software files a submission actually reads, sits at preparing software for an FDA submission.
Who reads the file on each side, and what does that do to the date?
The readers are different, and only one of the two publishes a clock.
FDA prints its numbers in the regulation. section 807.81 requires a premarket notification at least 90 days before the device is introduced into interstate commercial distribution. For a De Novo request, 21 CFR 860.230 puts FDA's threshold review of the request at 15 days from receipt, and section 860.240(a) then gives the agency 120 days after receipt of the request, or after the additional information that made it acceptable, to send an order granting or declining it. Where the request is granted, section 860.260(a)(2) requires a Federal Register notice of the classification order and any special controls within 30 days. Those are dates a board can plan against.
On the European side the class decides the reader, and the reader decides the date. Article 52 sends class IIa and class IIb devices through Chapters I and III of Annex IX with the technical documentation assessment of Section 4 of that Annex, class III through Annex IX or the Annex X and Annex XI alternative, and leaves only class I under Article 52(7) to the manufacturer's own declaration. The number you plan against comes from the body you contract with. That capacity has been the stated constraint in the Regulation's own amendment history: the recital of Regulation (EU) 2023/607, which extended the transitional dates in Article 120, records that notified body capacity was still not sufficient for the conformity assessment work in front of it.
Two calendar items belong to Europe alone and neither has a US counterpart in the same shape. The transitional dates of Article 120(3a), 31 December 2027 and 31 December 2028, extend a certificate issued under the old Directives, so a first entrant has nothing to extend; the sequence a first entrant actually faces is at EU MDR software market entry testing. And for an AI enabled device, Article 11(2) of Regulation (EU) 2024/1689 requires a single set of technical documentation covering both that Regulation and the medical devices one, while Article 113 as amended in 2026 defers Chapter III Sections 1 to 3 for products under Annex I Section A, which is the medical device route, to 2 August 2028. What that single file has to hold is worked through at the EU AI Act and clinical software.
What changes in the testing itself?
Three things: what sets the coverage, how fine the records have to be, and what a security artefact turns into.
Coverage is driven from different documents. Annex II Section 6.1(b) ties software verification and validation evidence to the hardware configurations and operating systems named in the information the manufacturer supplies, so the European instructions for use write your test matrix. On the US side the matrix is driven by what you declared against the predicate, because 807.87 requires the comparison with a comparable marketed device together with the data supporting it, and every declared difference is a claim with a run behind it or without one. The same product therefore carries two coverage lists derived from two different documents. Build both before either campaign is estimated; FDA 510(k) software documentation requirements sets out what the predicate side of that list costs when it is built late.
Record granularity differs in the same direction. The MDR asks for the process description and the summary of results in one place, which is a document you can assemble at the end. IEC 62304 Edition 1.1, which FDA recognises as a complete standard, fixes what a single software system test record has to contain so the run can be repeated, and several of those items exist only if somebody wrote them down on the day. Record at the finer grain from the first run and the European summary is a rollup. Record at the coarser grain and the US half of the work is a re-run.
Security is the clearest case of one body of work with two output shapes. Section 524B of the FD&C Act makes the sponsor of a premarket submission for a cyber device file a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits, maintain processes giving reasonable assurance that the device and related systems are cybersecure, release patches for known unacceptable vulnerabilities on a reasonably justified regular cycle and critical ones as soon as possible out of cycle, and provide a software bill of materials. The MDR reaches the same engineering through two short provisions instead: GSPR 17.2 names information security among the principles the software has to be developed under, and GSPR 17.4 makes the manufacturer set out the minimum hardware, IT network characteristics and IT security measures needed to run the software as intended, which is then a claim your evidence has to match. The US output is a filed document set. The European output is a statement in the product information that has to be true of the build you tested. What the testing behind both looks like is at cybersecurity testing under FDA section 524B.
What do you settle before either file is opened?
Five decisions, in this order
- Freeze the intended use sentence and have both regulatory owners write down what it produces on their side.
- Record the European class with the Annex VIII rule and the reasoning behind it, and the US route and documentation level with theirs.
- Derive the two coverage lists, one from the European instructions for use and one from the declared predicate differences, and merge them into a single test matrix.
- Fix the record format at the finer of the two grains before the first run.
- Decide who writes the rationale for every gap you will not close, because the MDR asks for it in the file and FDA asks for it in a question later.
Step 3 is where the saving is. One matrix covering the union of both lists costs less than two campaigns, and it is only available to a company that made the first two decisions before the estimate. The artefacts that carry the merged evidence into each file, and the traceability that lets a reader move from a requirement to a record, are validation documentation.
Sources for this page: the MDR articles, annex sections and Rule 11 are read in the official consolidated text of Regulation (EU) 2017/745 as at 1 January 2026. The 21 CFR and FD&C Act citations are read in the eCFR at the issue date of 31 August 2026, and 21 CFR 807.81 in its full text on 10 September 2026. The AI Act statements are read in Regulation (EU) 2024/1689 as consolidated at 27 July 2026, and the IEC 62304 statements in Edition 1.1, the 2006 first edition consolidated with Amendment 1. The references to Annex IX are quoted from Article 52, which names them. The Basic and Enhanced Documentation Levels are named as the mechanism that scopes an FDA software package; what each level asks for is set out in the June 2023 guidance itself.
What do buyers ask about this?
- Can one test campaign feed both submissions?
- The runs can be shared and the write-ups cannot. Annex II Section 6.1(b) of the MDR asks for a description of the software design and development process next to the summary of results, and ties coverage to every hardware configuration and operating system your own product information names. The text FDA recognises, IEC 62304 Edition 1.1, fixes what an individual test record has to contain so the run can be repeated. Plan one campaign, two write-ups, and record at the finer of the two grains.
- We are class I in Europe. Does that make us exempt in the United States?
- The two questions are decided by different instruments and neither answer carries. A European class I position comes from the closing sentence of Annex VIII Rule 11 and lets you self-declare under Article 52(7). The US exemption question runs through 21 CFR 807.85 and the device's classification under section 513 of the FD&C Act. Ask your regulatory owner to write both answers down separately, each with its own reasoning.
- Does our FDA documentation level tell us our EU class?
- An FDA documentation level does not tell you your EU class. FDA scopes device software documentation with a Basic and an Enhanced Documentation Level, defined in its guidance "Content of Premarket Submissions for Device Software Functions", June 2023, docket FDA-2021-D-0775. The European class comes from Annex VIII Rule 11 applied to the intended purpose, and Article 52 turns that class into a conformity assessment route.
- Which file should we build first?
- Build the one whose scoping decision is hardest to reverse, and that is usually the European one, because Article 2(12) of the MDR pulls your promotional and sales material into the intended purpose that Rule 11 classifies from. A claim written to match a US predicate is already on the European record by the time anyone classifies. Fix the wording once, then file in the order the revenue plan wants.
Which of our services test it?
What does validating your product actually involve?
Answer four questions about your markets, your product type and its integrations. You get the standards that reach you, the artefacts each one asks you to produce, and which of them a test supplier delivers.