One Dossier, Three Markets: CE to FDA to SFDA Reuse

Building three separate regulatory submissions from scratch for three markets is the default assumption for most founders, and it is more expensive than it needs to be. The method that avoids it is reusing your CE technical file for FDA and SFDA. This guide sets out what genuinely transfers between a CE technical file and submissions to FDA and Saudi Arabia's SFDA, and what has to be rebuilt for each.

In short: A CE technical file built under EU MDR transfers substantially to Saudi Arabia's SFDA, whose MDMA framework is broadly IMDRF-aligned with technical-file expectations that track MDR's — and SFDA's pathway formally recognises prior approval from reference regulators including the EU, so a CE mark carries real weight there. SFDA registration is commonly understood in the region to function as a reference point for other GCC regulators, which can shorten those states' own timelines. Transfer to FDA is partial: the evidence reuses, but the submission logic (predicates, pathways) is different.

The multi-market cost problem, stated in founder terms

A team planning EU, US, and MENA market entry sequentially, treating each as a fully separate regulatory project, is effectively paying to generate overlapping evidence three times: three technical documentation efforts, three risk management exercises, three verification and validation programmes, even though the underlying device, its design, its testing, its clinical performance, does not change between markets. The regulatory frameworks differ; the device does not.

The practical opportunity is to build one evidence base, structured well enough that its jurisdiction-neutral components (design verification, usability testing, clinical performance data, much of the risk management analysis) can be reused directly, while the jurisdiction-specific components (classification logic, submission format, specific regulatory claims) are built separately for each market on top of that shared foundation. This does not eliminate multi-market cost, but it removes the duplicated evidence-generation cost that dominates a from-scratch approach to each market.

What a technical file actually contains, and which parts are jurisdiction-neutral

A CE technical file under MDR Annex II and III contains, broadly: device description and intended purpose, design and manufacturing information, the GSPR (General Safety and Performance Requirements) checklist, risk management documentation under ISO 14971, verification and validation evidence, the clinical evaluation report, and labelling and instructions for use. Building an MDR Technical File and CER covers the structure in full.

Of these, design and manufacturing information, verification and validation testing, and much of the risk management analysis describe the device itself and are largely jurisdiction-neutral: a usability study, a software verification test suite, or a failure mode analysis does not change because you are submitting to a different regulator. What is jurisdiction-specific is the classification logic applied to that evidence, the specific format and structure the submission must take, and in some cases additional testing or evidence a particular regulator requires beyond what MDR asks for.

Two EU-specific obligations sit alongside the file and do not reuse anywhere: EUDAMED registration and UDI obligations (first modules mandatory since 28 May 2026) travel with EU market presence only, and for AI/ML-enabled devices the EU AI Act adds a high-risk overlay with no SFDA or FDA equivalent — its deadline for high-risk AI in regulated products is 2 August 2028, deferred from the original 2 August 2027 by the Digital Omnibus postponement (Regulation (EU) 2026/1744, published in the Official Journal 24 July 2026, in force from 27 July 2026).

Artefact-by-artefact reuse across the three markets

This table is a general pattern, not a substitute for an artefact-level review of your specific file; the degree of reuse in each row depends on how your original CE file was structured and how much of it was written with only the EU audience in mind.

A worked example: one device, three files

Consider a Class IIa diagnostic software product that has just completed its EU MDR technical file and is preparing to expand into Saudi Arabia and the United States. The CE file already contains a complete risk management file, a full verification and validation test suite, usability engineering data, and a clinical evaluation report built on an equivalence argument against comparable software already on the EU market — itself a demanding route for software under MDR Article 61 and MDCG 2020-5, so that CER was not a low-effort artefact. One watch-item on the example's EU premise: in December 2025 the European Commission published a proposal to simplify the MDR and IVDR (COM(2025) 1023, procedure 2025/0404(COD)) that would, among other things, move much stand-alone software toward Class I self-declaration. It is a proposal, not law — adoption is realistically ~2027 at the earliest — so the Class IIa premise here reflects the current rules, which still apply.

For the SFDA submission, the team's work is primarily structural: reformatting the existing technical file to the MDMA's required structure, translating the required sections, and appointing an in-country Authorised Representative, a mandatory local presence that neither the EU nor US relationship can substitute for. The underlying risk management and verification evidence carries across largely unchanged, because the MDMA framework's technical-file expectations broadly track MDR's structure, even though its classification, conformity, and reference-recognition rules are its own. The team's existing CE mark also does separate work here, as a recognised reference-market approval — a mechanism covered below. The team does not re-run its usability studies or rebuild its verification test suite from scratch.

For the FDA submission, the team's work is heavier. The verification and validation evidence remains useful, and increasingly so does the quality management system documentation, since building to ISO 13485 now serves both the EU relationship and the US QMSR requirement introduced in 2026. But the team must independently identify a suitable US predicate device, construct a substantial equivalence argument specific to that predicate, and potentially generate additional evidence if FDA's expectations for that predicate comparison differ from what the EU equivalence argument required. The clinical evaluation report itself is not submitted to FDA in its CE form; its underlying clinical data becomes input to a differently structured submission.

The pattern across both expansions is consistent with the artefact table above: evidence about the device reuses substantially; the classification and submission logic specific to each regulator does not, and has to be built for that regulator on its own terms.

Where reuse breaks down: three common mistakes

Misjudging what your CE mark is worth to each regulator. For FDA, the position is stark: a CE mark carries no formal weight in a 510(k), De Novo, or PMA review. What FDA can use is the evidence underneath it, and only once that evidence is presented in the form and depth its own process requires — treating the mark itself, rather than the file behind it, as the transferable asset is the most common conceptual error we see on the US side. SFDA is different: its MDMA pathway formally leverages prior approval from recognised reference regulators — the GHTF founding jurisdictions (EU, US, Canada, Australia, Japan) — so a valid CE certificate is a documented, often decisive input to a Saudi submission, not a mark given no weight. The mistake is treating the two markets the same way in either direction: presenting a CE mark to FDA as if it were evidence, or discounting it for SFDA as if it carried no recognition value. In both markets, the file still has to be presented in the form each process requires, and each regulator makes its own final determination.

Writing the original CE file with only a Notified Body audience in mind. A technical file that references EU-specific standards, terminology, or regulatory context without noting the underlying, more universal evidence it is based on is harder to adapt later. Teams planning multi-market expansion from the start benefit from structuring evidence, particularly verification, validation, and risk management, in a way that clearly separates the underlying device evidence from the EU-specific regulatory framing applied on top of it.

Underestimating the in-country Authorised Representative requirement for SFDA. This is not a paperwork formality; it is a mandatory local presence with real regulatory responsibility, and it cannot be satisfied by your existing EU Authorised Representative or by a US-based counsel. Teams that leave this until late in the SFDA process, assuming it can be arranged quickly alongside the rest of the submission, frequently find it is the actual bottleneck once the technical file itself is ready.

CE to SFDA: the high-reuse path

Saudi Arabia's SFDA operates a Medical Device Marketing Authorization (MDMA) framework, and since 1 January 2022, SFDA has required a complete technical file for every registration — the requirement is set out in SFDA's MDS-REQ 1, Requirements for Medical Devices Marketing Authorization (version 6, published 19 December 2021), which closed the earlier route that had accepted GHTF reference-regulator approvals more directly as a basis for registration. That framework is broadly IMDRF-aligned, with its own classification, conformity, and reference-recognition rules, but its technical-file expectations are structured closely enough to EU MDR's that a well-built CE technical file transfers substantially with targeted adaptation rather than a rebuild. The core evidence, design, risk management, verification and validation, clinical evaluation, generally carries across with format and, in places, translation adaptation rather than new evidence generation.

The CE relationship helps twice here, and the second mechanism is the one founders most often miss. Beyond file portability, SFDA's MDMA pathway leverages prior approval from recognised reference regulators — the GHTF founding jurisdictions: the EU, the US, Canada, Australia, and Japan — so a device that already holds a CE mark enters a more streamlined route than one arriving with no reference-market approval at all. This is formal recognition, not a shortcut past SFDA's own process: SFDA still makes its own determination on every submission, still requires the full technical file, an in-country SFDA-licensed Authorised Representative, and its own local registration. But it means an existing CE approval is itself a positive asset in a Saudi submission, over and above the reusable evidence behind it.

Two elements are specifically additional for SFDA regardless of how strong your CE file is: an in-country Authorised Representative, a locally established entity or individual who takes on regulatory responsibility within Saudi Arabia, is mandatory for foreign manufacturers, and cannot be satisfied by your EU Authorised Representative; and the submission itself must be formatted and, typically, partially translated to SFDA's specific requirements, which differ procedurally from EU submission format even where the underlying evidence is identical. SFDA Medical Device Registration (MDMA) covers the MDMA process, the reference-market precondition, the Authorised Representative requirement, and the practical registration timeline in full.

CE to GCC: the reference-approval shortcut, honestly qualified

Beyond Saudi Arabia specifically, SFDA registration is commonly understood in the region to function as a reference point for other Gulf Cooperation Council states' own registration processes, meaning a device already registered with SFDA can, in practice, move through certain other GCC states' processes faster than starting cold in each. We should be direct about the evidentiary basis for that: we haven't found a single citable SFDA or GCC document formally establishing this reference-approval behavior as a rule. It's a widely reported regional pattern, consistent with how reference-country recognition works in other regulatory systems, but treat it as a plausible dynamic worth factoring into sequencing, not a guaranteed mechanism you can rely on the way you can rely on the MDMA framework's actual published requirements.

That qualification doesn't remove the practical logic for sequencing SFDA registration relatively early in a MENA market entry strategy. Even setting the GCC reference effect aside, Saudi Arabia is usually the largest single market in the region for most device categories, and building the SFDA submission early captures the high CE-to-SFDA reuse described above regardless of what happens elsewhere in the GCC. Each GCC state retains its own final registration authority regardless of what reference practices exist informally, and treating an SFDA registration as automatically sufficient elsewhere in the region would misread how any such mechanism actually works.

CE to FDA: what carries and what must be rebuilt

The relationship between a CE file and an FDA submission is the least direct of the three reuse paths covered here, because the two systems are built on different underlying logic: MDR is a conformity assessment system, checking your device against safety and performance requirements via a Notified Body, while FDA's 510(k) pathway, the most common US route, is a comparative system, checking your device's substantial equivalence to an existing predicate device. CE Mark vs FDA Clearance: The Real Differences covers this distinction in full.

What transfers: your underlying evidence, verification and validation testing, usability engineering data, clinical performance data, and much of your quality management system documentation, is directly useful input to an FDA submission, since FDA also wants to see that your device is safe and performs as intended, even though it frames that question differently. What does not transfer directly: the classification and submission logic itself. A CE mark does not establish substantial equivalence to a US predicate device, and FDA's review does not treat CE marking as evidence of anything beyond the underlying testing it represents. You will need to build the specific 510(k), De Novo, or PMA submission logic, including predicate selection and comparison where relevant, from the evidence base, not import a CE submission format directly.

The quality management system reuse case has strengthened materially since February 2026, when the US Quality Management System Regulation, or QMSR, replaced FDA's prior Quality System Regulation and incorporated ISO 13485 by reference. A team that built its QMS to ISO 13485 for the EU relationship now has a substantially converged foundation for the US quality requirement too, rather than needing a separate US-specific quality system built in parallel. QMSR: What Replaced FDA's Quality System Reg covers what still differs on the US side despite this convergence. Predicate selection itself remains the one genuinely non-transferable piece of FDA-specific work: it depends entirely on what devices are already legally marketed in the US, a landscape your EU equivalence argument, built against EU market comparators, has no visibility into.

Keeping three files in sync after launch

Reuse is not a one-time exercise completed at initial registration; it recurs every time the device changes. A software update, a new feature, an expanded intended population, or a manufacturing change typically needs to be assessed against all three regulatory relationships independently, since a change that is minor enough to handle through your EU change-management process is not automatically minor enough to avoid FDA or SFDA's own review of the same change.

Teams that treat their three registrations as fully independent after initial launch often end up managing change three separate times, with three separate teams, working from three separate understandings of what the change actually was. The more efficient pattern, and the practical extension of the "one dossier" argument beyond initial registration, is a single change log and impact assessment process that documents what changed and why once, then maps that single assessment against each market's specific change-notification thresholds, EU significant change criteria, FDA's own change guidance for cleared devices, and SFDA's MDMA change requirements, rather than starting the analysis fresh in each jurisdiction. This is where the "one team" argument for initial registration compounds into an ongoing advantage: a team that built all three files together is positioned to assess a change against all three frameworks from a single, shared understanding of the device, rather than reconciling three independently maintained files after the fact.

Building this as an actual tracking artefact. You don't need special software for this; a well-structured log, even a shared spreadsheet, does the job if it captures the right columns. At minimum, a usable three-jurisdiction change log tracks: a change ID and date; a plain-language description of what changed and why, written once, in language a non-regulatory reader on your team could still follow a year later; the change's classification against EU MDR significant-change criteria (does it affect intended purpose, safety, or performance in a way requiring Notified Body notification); its classification against FDA's own change guidance for cleared devices (does it require a new 510(k) or fall within the scope of your existing clearance); its classification against SFDA's MDMA change requirements; the resulting action required in each jurisdiction, ranging from no action to full renotification; and the person accountable for each jurisdiction's follow-through. The value of building it this way is that the hard analytical work, understanding what the change actually is and why, happens exactly once, and each jurisdiction's column becomes a comparatively quick lookup against criteria you've already organized, rather than three separate teams re-deriving the same understanding of the change from scratch.

A worked change scenario. Say your Class IIa diagnostic software adds a feature expanding its intended use to a previously excluded patient subgroup, based on a validation study completed after launch in all three markets. Logged once, with the rationale and validation data referenced in a single entry, the EU column would likely flag this as a significant change requiring Notified Body notification, since an expanded intended population typically affects the basis of the original conformity assessment. The FDA column would likely require a new 510(k), since a change to intended use is one of the clearer renotification triggers under FDA's guidance. The SFDA column needs its own check against the MDMA framework's change criteria against the same fact pattern; given that framework's broad alignment with MDR-style change logic it often lands on a similar conclusion, but that's not automatic. What stays constant across all three columns is the validation study itself; what varies is each regulator's threshold for when that evidence triggers formal review versus routine documentation.

Sequencing playbook and the one-team argument

The practical sequencing question, once you understand what reuses and what doesn't, is which market to build first in a way that maximises reuse for the markets that follow. Building the EU MDR technical file first, since it is generally the most evidence-intensive of the three systems covered here, tends to produce the strongest foundation for both SFDA and FDA submissions that follow, since SFDA's high-reuse relationship to MDR means relatively little additional evidence generation, and FDA benefits from the underlying testing even though the submission logic must be rebuilt.

This is also the practical argument for using one team across all three markets rather than three separate regional specialists working independently: a team that understands how your MDR technical file maps to SFDA's MDMA requirements and to an FDA submission structure can build your evidence base once, with reuse in mind from the start, rather than generating redundant evidence because three disconnected teams each built their own version of your risk management file or your usability study. This is a claim about scope and efficiency of service, not a guarantee that any specific market's approval, clearance, or registration outcome is assured; each regulator makes its own independent determination on your submission.

The cost case for building this way follows the same logic as the cost figures cited elsewhere in this guide, an industry-cited range, including regulatory consultancies and market analysts such as posos.co: if a from-scratch EU submission alone commonly runs EUR 120,000-300,000, the marginal cost of a second and third market submission that reuses most of the underlying evidence is materially lower than building each from zero, even accounting for the jurisdiction-specific work that never goes away.

Where to Launch First: EU, UK, or US? covers the commercial and regulatory-speed tradeoffs that should inform which of these three you build for first, before the reuse strategy in this guide determines how efficiently the following two markets can be layered on top.

---

Where next: Where to Launch First: EU, UK, or US? · Building an MDR Technical File and CER · SFDA Medical Device Registration (MDMA) · CE Mark vs FDA Clearance: The Real Differences

See how far your existing CE file actually gets you in the other two markets before you build anything new. Book an expert conversation →