Conformity assessment for Software as a Medical Device under the MDR follows the same legal routes as any other device — Article 52 governs the choice, Annex IX is the default route for Class IIa and above, and a Notified Body is mandatory the moment Annex VIII Rule 11 pushes the software above Class I. What differs is the scrutiny: the Notified Body reviews the software lifecycle against EN 62304:2006+A1:2015, the QMS against EN ISO 13485:2016+A11:2021, and the qualification and classification reasoning against MDCG 2019-11 Rev.1. The route is the same. The audit content is software-specific.

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

TL;DR

  • Article 52 of Regulation (EU) 2017/745 sets the available conformity assessment routes for every class, including SaMD. Rule 11 of Annex VIII decides which class the software lands in, and the class decides whether a Notified Body is mandatory.
  • For most SaMD startups the route is Annex IX — full QMS audit plus technical documentation assessment on a representative device per generic device group. This is the same seven-step spine as any Class IIa or IIb device.
  • EN ISO 13485:2016+A11:2021 is the harmonised QMS standard the Notified Body audits against. EN 62304:2006+A1:2015 is the harmonised software lifecycle standard whose evidence the Notified Body reviews inside the technical documentation file.
  • MDCG 2019-11 Rev.1 (June 2025) is the guidance the Notified Body uses to judge whether your qualification and classification arguments hold. If your file contradicts MDCG 2019-11 Rev.1, the file loses.
  • The software-specific parts of the audit are the SOUP/third-party component list, the software safety classification, the architecture and unit verification trail, the change control and release history, and the cybersecurity and post-market update mechanism.
  • The mistake that stalls SaMD conformity assessment most often is not a missing document — it is a classification argument that does not survive the Notified Body's first read of MDCG 2019-11 Rev.1.

Why SaMD conformity assessment looks different (even though the route is the same)

Founders building SaMD often arrive expecting that software has its own special path through the MDR. It does not. The Regulation treats SaMD as a medical device, routed through the same conformity assessment procedures as hardware, governed by the same Article 52, classified under the same Annex VIII — with Rule 11 applying to software specifically — and audited by the same kind of Notified Body that certifies implants and in vitro diagnostic analysers.

What does differ is what the Notified Body actually looks at inside the file. A hardware reviewer spends days on biocompatibility, sterilisation validation, and mechanical testing. A software reviewer spends those days on software architecture, SOUP lists, unit verification traceability, software safety class justification, and cybersecurity. The route is the same. The audit content is not.

This matters for startup planning because the parts of the file that matter most are the parts the generic "Class IIa procedure" walkthrough does not emphasise. A SaMD founder who reads post 095 and believes the Class IIa seven-step procedure is the whole story will still miss the software-specific scrutiny that decides whether the file passes on the first round or the fourth. This post covers the delta.

SaMD classification under Rule 11 — the gate to everything downstream

Before any conformity assessment question can be answered, the software has to be classified. Under Annex VIII Rule 11 of Regulation (EU) 2017/745, software intended to provide information used to take decisions with diagnostic or therapeutic purposes is at least Class IIa. It escalates to IIb when those decisions could cause serious deterioration of health or a surgical intervention, and to III when they could cause death or irreversible deterioration. Software intended to monitor physiological processes is Class IIa, or IIb when variations in vital parameters could result in immediate danger. Everything else is Class I.

The Class I bucket is the exception, not the default. MDCG 2019-11 Rev.1 (June 2025) contains worked examples that show how narrow the Class I bucket really is once Rule 11 is applied honestly. For a full treatment see post 081 and the SaMD pillar at post 371.

The classification gate matters for conformity assessment because it decides one thing with finality: whether a Notified Body is mandatory. At Class I the manufacturer self-declares and there is no Notified Body involvement, which is the path covered in post 093. The moment Rule 11 produces Class IIa or higher, Article 52 forces a Notified Body into the procedure, and the path becomes the Annex IX walkthrough from post 094, post 095, and post 096 — applied to software.

Route selection under Article 52 for SaMD

Article 52 sets the available conformity assessment routes by class. For SaMD the practical picture is this.

Class I SaMD — self-declaration, no Notified Body, registration and technical documentation maintained by the manufacturer. Rare under Rule 11 and usually the wrong assumption for a founder without expert confirmation. Covered in post 093.

Class IIa SaMD — Annex IX (full QMS plus technical documentation assessment on a representative sample per generic device group) or, in specific scenarios, Annex XI (production quality assurance). Annex IX is the default for a software-only startup. Covered in post 095.

Class IIb SaMD — Annex IX with a wider technical documentation assessment scope, or Annex X (type examination) combined with Annex XI. Annex IX remains the default for most software companies because Annex X is structured around physical type samples that are awkward for pure software. Covered in post 096.

Class III SaMD — Annex IX with technical documentation assessment on every device (not a representative sample), or Annex X plus Annex XI. Rare for startups because the clinical evidence burden is the dominant constraint long before the procedure choice is.

The route decision for most SaMD startups collapses to Annex IX. The seven-step spine from post 095 — Notified Body selection, contract and scope, application package, QMS audit, technical documentation assessment, certificate issuance, annual surveillance — applies directly. The rest of this post focuses on what changes inside each step when the device is software.

Notified Body scope for SaMD — the scope-match trap

Not every Notified Body designated under the MDR can certify SaMD. Designation happens against specific codes in the Commission's NANDO database, and those codes include horizontal technology codes that cover software and active devices. A Notified Body without the relevant software codes in its designation cannot legally assess your SaMD file, no matter how much it would like to.

For a SaMD startup the scope-match question at Step 1 of the Annex IX procedure has two layers. First, does the Notified Body hold the horizontal software/active device code you need? This is a yes or no question answerable from NANDO. Second, does the Notified Body have a software reviewer on staff who actually understands your technology — AI, cloud architecture, real-time data streams, mobile deployment — well enough to run a productive review? This is a harder question, and the only way to answer it is to ask the Notified Body directly about its software review capacity and to check references with other software manufacturers they have certified.

A Notified Body that is formally designated but has no working software reviewers will either delay your project while it hires, or run your review through reviewers who are out of their depth and issue questions that multiply into rounds you cannot efficiently close. This is the quiet cost of a bad scope match, and it is the single largest controllable variable in a SaMD conformity assessment timeline. Post 094 covers Notified Body selection in full; the lesson for SaMD is to treat software reviewer capacity as a hard selection criterion, not a nice-to-have.

Software-specific Notified Body checks inside the technical documentation assessment

Once the application package is submitted and the QMS audit begins, the technical documentation assessment under Annex IX for SaMD focuses on a predictable set of software-specific deliverables. A reviewer who knows software will look for all of them; the absence of any one is a finding.

The software safety classification under EN 62304:2006+A1:2015. This is the A/B/C classification driven by the severity of possible harm from software failure before external risk controls. It is distinct from the MDR device class under Rule 11 and must be consistent with the risk management file. A software safety class that contradicts the risk file is an immediate question.

The architecture document and item decomposition. EN 62304:2006+A1:2015 expects software items and, for Class C, software units to be identified and traceable to requirements and tests. A modern microservice architecture is compatible with this — the mapping just has to be explicit.

The SOUP (software of unknown provenance) list. Every third-party library, open-source component, and cloud service the software depends on has to be listed, risk-assessed, and maintained. For cloud-native SaMD this list is long, and reviewers know that. The file has to show the list is real and current, not a snapshot from the day the documentation was written.

The verification trail. Requirements traced to design, design traced to code, code traced to tests, tests traced to results. For an Agile team this is mostly tooling — if your CI pipeline produces the trace automatically, the file is easy. If the team was going to back-fill the trace at the end, the file is hard and the round count explodes.

The change control and release history. Every release that placed a version of the software in front of users, with the corresponding risk and verification delta. SaMD evolves faster than hardware, and the Notified Body knows this. The change history is evidence that the lifecycle discipline is real.

The cybersecurity package. MDR Annex I cybersecurity requirements, threat modelling, penetration test evidence, the secure development lifecycle, and the patch and update mechanism. Cybersecurity is increasingly the question that separates a clean SaMD file from a problematic one.

The qualification and classification rationale. Written explicitly against MDCG 2019-11 Rev.1, walking the specific software through the guidance's decision tree and Rule 11 worked examples. A rationale that does not cite MDCG 2019-11 Rev.1 is a rationale that the reviewer will rewrite in their head with results you will not like.

Surveillance for software — the part that bites later

The Annex IX certificate is valid for up to five years, with annual surveillance audits. For SaMD, surveillance is where the software-specific obligations compound. Every significant change to the software during the certificate cycle has to be evaluated against the existing certification — is this change covered by the certificate, or does it trigger a supplementary assessment? The answer depends on whether the change affects the intended purpose, the classification, the safety class, the architecture, or the clinical claims.

Software that ships a new release every two weeks needs a change control process tight enough to make this decision without stopping the release train. A process that treats every release as a potential certification event blocks the product. A process that treats no release as a certification event eventually places an uncertified version in front of users. The balance is documented, defensible, and Notified-Body-aware change control — and it is set up before the first post-certification release, not after.

Cybersecurity surveillance adds another layer. Vulnerability monitoring, patch deployment, and incident response all sit on top of the general PMS obligations and the vigilance reporting timelines under MDR Chapter VII. For SaMD, cybersecurity PMS is not a quarterly review — it is an always-on process, and the Notified Body will check the evidence at surveillance.

Common SaMD conformity assessment mistakes

Assuming Class I and discovering Class IIa mid-project. The most expensive SaMD mistake is a classification argument that does not survive Rule 11 and MDCG 2019-11 Rev.1. By the time it falls, a QMS has been built for the wrong class, a Notified Body has not been selected, and the timeline is shot.

Picking a Notified Body without software review capacity. Scope designation is necessary and not sufficient. A Notified Body with no practicing software reviewers will produce a slow, frustrating review even with a clean file.

Back-filling EN 62304:2006+A1:2015 evidence at the end. Reconstructed lifecycle evidence is the single cleanest way to fail a SaMD audit. The lifecycle starts on day one of the code, not day one of the certification project.

A SOUP list that is a snapshot, not a living document. Modern SaMD depends on hundreds of components. A reviewer who sees a SOUP list that has not been updated in months knows exactly what that means.

Change control that cannot distinguish between releases that need supplementary assessment and releases that do not. Surveillance findings on change control are among the most common SaMD non-conformities, and they are almost always preventable with a documented impact-assessment step before every release.

A cybersecurity file that treats the topic as a checklist. Cybersecurity is continuous, and the evidence has to look continuous. A single-point-in-time penetration test report with nothing after it is a flag.

The Subtract to Ship angle for SaMD conformity assessment

The Subtract to Ship methodology applied to SaMD conformity assessment subtracts three things specifically. First, premature QMS build-out before the qualification and classification are confirmed in writing against MDCG 2019-11 Rev.1 — every hour spent on a QMS for the wrong class is an hour wasted. Second, documentation volume that does not trace to a specific clause of EN 62304:2006+A1:2015, EN ISO 13485:2016+A11:2021, or an MDR article — reviewers do not reward volume, they reward coherence. Third, the back-filling temptation — the belief that lifecycle discipline can be added at the end. It cannot.

What stays is the work that actually matters: the classification argument, the live SOUP list, the CI-generated verification trail, the documented change control, and the cybersecurity process that runs continuously. Every item in that list traces to a specific obligation in the MDR or a harmonised standard referenced by it. Everything outside that list is decoration. The full methodology is in post 065; the SaMD-specific application is in post 417 and post 425.

Reality Check — Where do you stand on SaMD conformity assessment?

  1. Is your classification under Annex VIII Rule 11 written down, cross-checked against MDCG 2019-11 Rev.1 worked examples, and defensible without improvisation?
  2. Have you confirmed that your shortlisted Notified Bodies hold the horizontal software codes you need in NANDO, and have you spoken to references about their actual software review capacity?
  3. Does your engineering team produce the EN 62304:2006+A1:2015 evidence as a by-product of development, or is it planned as a back-fill exercise at the end?
  4. Is your SOUP list a living artefact maintained automatically from dependency files, or a document that was written once and has aged since?
  5. Does your change control process have an impact-assessment step that distinguishes releases covered by the certificate from releases that would trigger supplementary assessment?
  6. Is your cybersecurity package continuous evidence — threat model, secure development lifecycle, ongoing vulnerability management — or a point-in-time test report?
  7. Does your QMS under EN ISO 13485:2016+A11:2021 describe how the software-only company actually operates, or is it a template built for a hardware manufacturer?

Any question without a clear yes is a gap worth closing before the Notified Body contract is signed.

Frequently Asked Questions

Is the conformity assessment route different for SaMD than for hardware? No. Article 52 of Regulation (EU) 2017/745 sets the same route options for SaMD as for any other device. The class under Annex VIII — for software, driven by Rule 11 — determines which routes are available. What differs is the content of the Notified Body's review, not the legal route.

Is a Notified Body mandatory for SaMD? Only for Class IIa and above. At Class I the manufacturer self-declares. At Class IIa, IIb, or III a Notified Body is mandatory under Article 52. Most SaMD falls into Class IIa or higher under Annex VIII Rule 11, so in practice most SaMD startups will need a Notified Body.

Which standards does the Notified Body audit SaMD against? EN ISO 13485:2016+A11:2021 for the QMS, and EN 62304:2006+A1:2015 for the software lifecycle. Risk management runs under EN ISO 14971:2019+A11:2021. Cybersecurity increasingly draws on EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1. All of these are referenced by the MDR — the MDR is the North Star, the standards are tools that provide presumption of conformity.

Can I use Annex XI instead of Annex IX for SaMD? Legally yes in specific scenarios, but in practice Annex XI — production quality assurance — is a poor fit for pure software because its audit model is structured around physical production lines and final inspection. Annex IX is the default choice for SaMD startups and should be the baseline assumption unless a specific reason points elsewhere.

How long does SaMD conformity assessment take? For a Class IIa SaMD startup with a QMS-ready starting state, nine to eighteen months from application to certificate is a realistic order of magnitude, driven primarily by Notified Body capacity and the quality of the application package. Class IIb adds months. Classification surprises add quarters. A clean file with the right Notified Body compresses the timeline; the wrong Notified Body stretches it indefinitely.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 52 (conformity assessment procedures), Annex VIII Rule 11 (classification of software), Annex IX (conformity assessment based on a quality management system and on assessment of technical documentation). 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 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 (IEC 62304:2006 + IEC 62304:2006/A1:2015).

This post is part of the Device Classification & Conformity Assessment series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim here — EN 62304:2006+A1:2015 and EN ISO 13485:2016+A11:2021 are the tools that provide presumption of conformity with the software lifecycle and QMS obligations the Notified Body audits under Annex IX. For startup-specific regulatory support on SaMD conformity assessment, Zechmeister Strategic Solutions is where this work is done in practice.