SaMD pre-certification under MDR is the work done before formal conformity assessment begins: locking intended purpose, fixing classification under Annex VIII Rule 11, building a minimum viable QMS, preparing technical documentation skeleton, and engaging a notified body early enough for the certification route per Annex IX, X, or XI to be real. Done well, it compresses the timeline. Done badly, it stretches it.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Pre-certification is not a shortcut — it is the parallel build of regulatory infrastructure alongside product R&D so that conformity assessment starts on day zero of readiness, not day zero of preparation.
  • MDR Annex VIII Rule 11 classifies most clinically meaningful SaMD as Class IIa or above, which means a notified body is mandatory per Article 52.
  • MDR Article 120 (as amended by Regulation (EU) 2023/607) extended transitional provisions for legacy devices; it does not apply to new SaMD without prior MDD certification.
  • Lock intended purpose, user, clinical condition, and classification before writing code that cannot be changed. Defer UI polish, non-core features, and multi-language rollout.
  • A minimum viable QMS per EN ISO 13485:2016+A11:2021 can be built in parallel with the first release candidate — but not after.
  • Notified body engagement should begin 6-12 months before intended CE mark date, not at submission.

Why pre-certification is the real work

The conformity assessment itself — the moment the notified body issues a certificate — is the shortest part of the journey for most SaMD startups. The long part is everything that comes before it: classification debates, intended purpose iteration, QMS build, technical file construction, clinical evaluation, risk management records, usability engineering, software lifecycle evidence. If any of these is weak when you submit, the notified body's review cycles will extend the timeline by months.

We have seen startups lose nine months because they treated pre-certification as a checklist to run at the end. We have also seen startups save nine months because they treated pre-certification as parallel engineering work that began on day one. The difference is not talent or capital. The difference is strategy — specifically, knowing what to lock early and what to keep fluid.

The regulation never uses the word "pre-certification." What it describes, across Article 10 (manufacturer obligations), Article 52 (conformity assessment), Annex VIII (classification), Annex IX (QMS-based conformity assessment), and Annex II (technical documentation), is a set of obligations that must all be met before a certificate can be issued. Pre-certification is the founder's discipline of meeting them in the right order.

What MDR actually says about the SaMD path

Classification: Annex VIII Rule 11. Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is Class IIa, unless the decisions may cause death or irreversible deterioration (Class III) or serious deterioration or surgical intervention (Class IIb). Software intended to monitor physiological processes is Class IIa unless monitoring vital physiological parameters where variations could result in immediate danger (Class IIb). All other software is Class I. For the vast majority of clinically useful SaMD, this lands at Class IIa or higher — which means a notified body is required per Article 52(6).

Conformity assessment routes: - Annex IX — QMS-based conformity assessment including assessment of technical documentation. The default route for SaMD Class IIa, IIb, and III, and the one most startups follow. - Annex X — Type examination. Less common for software-only products. - Annex XI — Production quality assurance. Typically combined with Annex X, not used standalone for most SaMD.

Article 120 / Regulation (EU) 2023/607. These transitional provisions apply to devices that held valid certificates under the former Directives. A brand-new SaMD without MDD history cannot use Article 120 transitions — it must meet MDR in full from day one. Startups regularly misread this and assume they have extra time. They do not.

Article 10(9) and Annex IX §2 require the manufacturer to have a QMS in place covering design and development, production, and post-market activities. EN ISO 13485:2016+A11:2021 is the harmonised standard providing presumption of conformity.

Annex I §17.2 requires software development per the state of the art, which for SaMD means EN 62304:2006+A1:2015 at minimum, with EN IEC 81001-5-1:2022 for cybersecurity.

Pre-certification strategy is the founder's plan to satisfy all of this in parallel with product development — not after it.

A worked example: locking intended purpose before locking code

A two-founder startup builds a SaMD for clinicians managing chronic kidney disease. Early intended purpose draft: "Assists clinicians in managing CKD patients." Vague. Under MDR Article 2(12), intended purpose is what the manufacturer states in labelling, IFU, and promotional materials — and it drives classification, clinical evaluation, and GSPR scope. "Assists in managing" is a promise that is too broad to defend and too vague to classify cleanly.

The founders refine through three iterations with their notified body contact: 1. "Provides decision support to nephrologists for staging and medication adjustment in adult CKD patients." — Too broad for Rule 11; would likely push to Class IIb given the medication adjustment implication. 2. "Displays calculated eGFR trend and CKD stage based on clinician-entered lab values to support routine monitoring by nephrologists in adult outpatient care." — Cleaner. Information provision, not therapeutic decision automation. Likely Class IIa under Rule 11. 3. "Calculates and displays eGFR and CKD stage from laboratory values entered by the treating nephrologist, for use in routine outpatient monitoring of adult CKD patients. Not intended for acute care, paediatric use, or as a replacement for clinical judgement." — This is the one. Clear inclusion, clear exclusion, defensible classification, tractable clinical evaluation scope.

With iteration 3 locked, the team can now: - Finalise classification justification (Class IIa). - Lock GSPR applicability in Annex I. - Define the clinical evaluation scope. - Scope the software requirements against the intended purpose. - Build the risk file around the specific population and context.

None of this requires finished code. All of it can happen in parallel with the first coded prototype. This is the essence of pre-certification: the regulatory skeleton is load-bearing before the product reaches feature-complete.

The Subtract to Ship playbook for SaMD pre-certification

1. Lock four things before writing production code. - Intended purpose (narrow, specific, defensible). - User (who, what qualification, what setting). - Clinical condition and population. - Classification under Rule 11 with written justification.

These four define everything downstream. Changing them mid-build means rewriting the clinical evaluation, the risk file, the software requirements, and the technical file. Lock them early.

2. Defer what can be deferred. - UI polish (the notified body does not care about the colour palette; usability engineering per EN 62366-1:2015+A1:2020 does, but that is a different conversation). - Non-core features that do not contribute to the intended purpose. - Multi-language rollout (start with one language; add others after first CE mark). - Integrations with third-party systems that complicate verification. - Anything that does not serve the intended purpose as written.

Subtraction is strategy. Every feature you defer is a feature you do not need to verify, document, or risk-assess for the first release.

3. Build a minimum viable QMS in parallel. A minimum viable QMS covers document control, design controls, risk management, supplier control (including SOUP/OTS), CAPA, post-market surveillance, and management review. EN ISO 13485:2016+A11:2021 defines the clauses. Do not wait for "feature-complete" to start the QMS. The QMS is what turns your development history into auditable evidence. Build it alongside, not after.

4. Build the technical file skeleton from day one. MDR Annex II structure: device description, intended purpose, classification, design and manufacturing information, GSPR checklist, benefit-risk analysis, pre-clinical and clinical evaluation, verification and validation, PMS plan. Create the folders on day one. Fill them as you go. At submission, there is no scramble — the file has been growing in real time.

5. Engage a notified body early, not at submission. Notified body capacity is constrained. Applying six weeks before your intended CE mark date is not a strategy. Begin conversations 6-12 months in advance. Ask about their SaMD expertise, their Rule 11 interpretation, their queue, and their pre-application dialogue offerings. Some notified bodies welcome early technical dialogue; use it. This is permitted under MDR and is not a conflict of interest when conducted properly.

6. Run verification and validation in parallel with development. EN 62304 clauses 5.5, 5.6, and 5.7 require unit, integration, and system testing with documented records. Waiting until feature-freeze to write test protocols is the most expensive mistake SaMD startups make. Verification records are deliverables, not afterthoughts — build them as you build the code.

7. Start the clinical evaluation early. MDR Article 61 and Annex XIV require clinical evaluation for all devices. For SaMD, this often means literature-based evaluation for known clinical concepts plus device-specific evidence. Start the systematic literature search in pre-certification, not after. The CER grows alongside the product.

Reality Check

  1. Have you locked intended purpose, user, clinical condition, and classification in writing, with a traceable justification?
  2. Is your QMS being built in parallel with your code, or are you planning to "add it later"?
  3. Have you identified the notified body you intend to apply to, and opened dialogue?
  4. Does your technical file exist as a folder structure being populated in real time, or as a future task?
  5. Are your EN 62304 test protocols being written before execution, or reconstructed afterwards?
  6. Is your clinical evaluation plan drafted, or still a bullet in your roadmap?
  7. Have you explicitly decided what you are NOT building for the first release, and is that list longer than your build list?
  8. Do you know which Annex IX, X, or XI route applies, and why?

Three or more "no" answers means you are not pre-certifying — you are rehearsing for a scramble.

Frequently Asked Questions

Does Article 120 buy me more time for my new SaMD? No. Article 120 and the extensions under Regulation (EU) 2023/607 apply to devices that were already certified under the former Directives. A new SaMD without MDD history must meet MDR from day one.

Can I self-certify my SaMD under MDR? Only if it classifies as Class I under Annex VIII Rule 11 — which is uncommon for clinically meaningful SaMD. Most SaMD lands at Class IIa or higher, which requires notified body involvement per Article 52.

How early should I contact a notified body? Begin dialogue 6 to 12 months before your intended CE mark date. Capacity constraints and review cycles make late engagement the single most common cause of slipped timelines.

What is the minimum QMS I need before submission? A QMS aligned with EN ISO 13485:2016+A11:2021 covering design controls, risk management, document and record control, supplier control, CAPA, PMS, and management review. "Minimum viable" does not mean "incomplete" — it means right-sized for your team and scope while meeting all applicable clauses.

Can I freeze classification later if I change features? You can, but every change cascades through the technical file, the clinical evaluation, and the risk file. This is why locking the four anchors (purpose, user, condition, classification) early is load-bearing.

Do I need EN IEC 81001-5-1:2022 cybersecurity evidence in pre-certification? Yes, for any SaMD with connectivity or handling of health data. MDR Annex I §17.2 and §17.4 reference the state of the art for security; EN IEC 81001-5-1:2022 is the current reference standard for the software security lifecycle.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 10, 52, 120; Annex VIII Rule 11; Annex IX; Annex X; Annex XI.
  2. Regulation (EU) 2023/607 amending Regulation (EU) 2017/745 as regards transitional provisions.
  3. EN ISO 13485:2016+A11:2021, Medical devices — Quality management systems — Requirements for regulatory purposes.
  4. EN 62304:2006+A1:2015, Medical device software — Software life cycle processes.
  5. MDCG 2019-11 Rev.1 (June 2025), Qualification and classification of software.