In short. An EU MDR timeline for software has two phases that run one after the other. The first is your own preparation: QMS, technical documentation, clinical evaluation, usability, cybersecurity and verification and validation. You control most of this phase. The second is the Notified Body phase, which you control far less. According to the European Commission's Notified Body survey (data as of 28 February 2026), most Notified Bodies report 13–18 months from a signed written agreement to a new certificate. Class I software follows a self-declaration route with no Notified Body. Nobody can promise you a certificate date: not a consultant, and not the Notified Body before it has assessed your file.

Two phases, two different kinds of uncertainty

Founders often ask "how long does CE marking take?" as if it were one number. It is more useful to split the question in two. Each phase has different drivers, and different people can shorten or lengthen it.

PhaseWho drives itWhat mainly determines its lengthWhere the estimate comes from
1. PreparationManufacturer (with a consultant, if you use one)Starting point, classification, clinical evidence, team capacity, product stabilityYour own plan, based on a gap analysis
2. Notified Body: application to written agreementNotified Body, plus your responsivenessNotified Body capacity and scope, completeness of your applicationEuropean Commission Notified Body survey
3. Notified Body: written agreement to certificateNotified Body, plus the quality of your answersAudit scheduling, technical documentation review, rounds of questions and non-conformitiesEuropean Commission Notified Body survey
Class I (self-declaration)Manufacturer onlyPreparation only. A Notified Body is involved only for sterile, measuring or reusable-surgical-instrument aspectsYour own plan

Phase 1: preparation by the manufacturer

Before a Notified Body can assess anything, the manufacturer has to build the evidence. A consultant can structure, write and review a large part of it. The manufacturer remains responsible for the device and its documentation. For software, the workstreams are:

  • Qualification and classification. First confirm that the software is a medical device (MDCG 2019-11 Rev.1, June 2025). Then classify it under Rule 11 of Annex VIII. Software that provides information used to take diagnostic or therapeutic decisions is Class IIa. It is Class IIb if those decisions may cause a serious deterioration of health or a surgical intervention, and Class III if they may cause death or an irreversible deterioration. The class sets the conformity assessment route, so get it right first. See our Rule 11 classification guide.
  • Quality management system. Article 10(9) MDR requires a QMS that is proportionate to the risk class and type of device. Most manufacturers use EN ISO 13485:2016, which is listed as a harmonised standard under the MDR. Our own estimate for ISO 13485 implementation is typically 3–6 months to certification-audit readiness, depending on company size and process maturity.
  • Technical documentation (Annexes II and III). This covers the device description and classification rationale, information supplied with the device, design and manufacturing information, the GSPR checklist, benefit-risk and risk management, verification and validation, and the post-market surveillance documentation. See EU MDR technical documentation for SaMD.
  • Software lifecycle and verification and validation. Annex I 17.2 requires software to be developed according to the state of the art, taking into account the development lifecycle, risk management (including information security), and verification and validation. Annex II 6.1(b) asks for evidence of software verification and validation. In practice this means IEC 62304 (current edition: IEC 62304:2006+AMD1:2015).
  • Clinical evaluation. MDCG 2020-1 sets out three components for medical device software: valid clinical association (scientific validity), technical performance and clinical performance. If the literature and your existing data do not cover clinical performance, you need to generate data. That is often the longest single item on the plan.
  • Usability. Annex I Section 5 requires risks from use error to be reduced. Most manufacturers apply IEC 62366-1:2015+AMD1:2020. The summative evaluation needs a stable user interface and recruited representative users, and both take calendar time.
  • Cybersecurity. Annex I 17.2 and 17.4 and MDCG 2019-16 Rev.1 apply. The guidance lists security feature testing, fuzz testing, vulnerability scanning and penetration testing as verification methods. External penetration testers have their own booking lead times. See our cybersecurity guide.

Factors that move the preparation timeline

  • Starting point. A team with requirements, tests and release records already in its tools moves faster than a team rebuilding history after the fact.
  • A clear, stable intended purpose. Every change to the intended purpose ripples through classification, risk management, the clinical evaluation and labelling.
  • Classification outcome. Class IIb and III software usually needs more clinical evidence and more Notified Body scrutiny than Class IIa.
  • Clinical evidence. Is the evidence literature-based, does it come from existing data, or do you need a new study? This is usually the biggest variable.
  • AI/ML components. Data management, independent test data and performance claims all need documented evidence.
  • Design stability. If the product keeps changing, tests and the usability evaluation have to be repeated. Plan which version you will submit.
  • Internal capacity. Someone on your side has to answer questions, provide evidence and approve documents. When your engineers are fully booked on features, the regulatory work waits.
  • Suppliers. Cloud providers, outsourced development and third-party software components (SOUP) all need supplier controls and documentation.

Our planning estimate for a Class IIa SaMD

For a Class IIa SaMD, we typically plan the consulting workstream to a submission-ready technical file over about 6–9 months. This is our own planning estimate, not a regulatory figure, and it depends on where you start. It covers preparation only. The Notified Body phase described below comes on top. A technical documentation gap analysis, delivered 1–4 weeks after we receive your documentation, is how we turn that range into a dated plan for your product. See what a gap analysis looks like.

Phase 2: the Notified Body

For Class IIa, IIb and III software, a Notified Body has to assess conformity before you can sign the EU declaration of conformity and affix the CE marking. Under Article 52(6), Class IIa manufacturers normally go through Annex IX Chapters I and III. The Notified Body assesses the QMS and the technical documentation of at least one representative device for each category of devices. Class IIb uses the same Annex IX chapters, with technical documentation assessed for at least one representative device per generic device group (Article 52(4)). The sequence is roughly as follows:

  1. Find a Notified Body whose designation scope covers your device and that has capacity. See how to choose a Notified Body.
  2. Lodge the application. The Notified Body reviews it and the two parties sign a written agreement.
  3. The Notified Body audits the QMS and assesses the technical documentation, then raises questions and any non-conformities.
  4. You respond, and further rounds follow if needed.
  5. The Notified Body makes its certification decision and issues the certificate.

What the Commission's Notified Body survey reports

The European Commission publishes a regular survey of Notified Bodies. The current edition was published on 2 July 2026, with data as of 28 February 2026. All 52 Notified Bodies designated under the MDR responded. Two of its indicators matter for planning.

Application lodged → written agreement signed (number of files across the 52 MDR Notified Bodies):

TimeFilesShare (our calculation from the survey counts)
1–2 weeks3,980≈ 17%
3–4 weeks4,713≈ 20%
1–2 months6,893≈ 29%
2–3 months4,112≈ 17%
3–6 months3,035≈ 13%
More than 6 months1,325≈ 6%

The Commission summarises this as follows: in the majority of cases (65%), it takes less than two months from an application lodged to a written agreement signed.

Written agreement signed → new certificate issued (share of Notified Bodies reporting each duration):

DurationQMS certificates
(Annex IX Ch. I or Annex XI Part A; 47 NBs)		QMS + product certificates
(Annex IX Ch. II, Annex X or Annex XI Part B; 39 NBs)
Less than 6 months2%0%
6–12 months30%8%
13–18 months62%51%
19–24 months2%31%
More than 24 months4%10%

How to read these figures

  • Which column applies to you. Most Class IIa and IIb software goes through Annex IX Chapters I and III, which leads to a QMS certificate, the left-hand column. Class III software is assessed under Annex IX Chapter II as well (or Annex X with Annex XI), which falls in the right-hand column.
  • The figures describe Notified Bodies, not your project. The second table shows the share of Notified Bodies reporting each duration. It is not a distribution of individual files or a forecast for any one manufacturer.
  • Your response time may be included. The survey measures time from signed written agreement to certificate issuance. It does not say whether the time manufacturers spend answering questions and closing non-conformities is counted. Answers that are complete and arrive quickly can only help.
  • Finding a Notified Body is not in the figures. The survey starts at "application lodged". The weeks or months you spend finding a Notified Body that has the right scope and will accept your application come before that. See our note on Notified Body capacity.

Combine the phases for a rough picture. Suppose your application reaches a written agreement within two months, and your Notified Body is in the 13–18 month group. Then the certificate arrives well over a year after you apply, on top of your preparation time. Treat this as arithmetic on survey bands, not a prediction.

Class I software: the self-declaration route

Under Rule 11, software that does not fall into the IIa/IIb/III cases "is classified as class I". Most decision-support and monitoring software is therefore Class IIa or higher. Class I is the exception, and the classification rationale has to stand up to scrutiny.

For Class I devices, Article 52(7) says the manufacturer declares conformity by issuing the EU declaration of conformity after drawing up the technical documentation in Annexes II and III. There is no Notified Body, with one exception. A Notified Body is involved if the device is placed on the market sterile (Is), has a measuring function (Im) or is a reusable surgical instrument (Ir). Even then, its involvement is limited to those aspects. Sterility and reuse do not apply to software. Whether a software function counts as a "measuring function" needs a documented case-by-case assessment.

The Class I timeline is preparation only, but the work is real. You still need the following:

  • a QMS (Article 10(9))
  • complete technical documentation, including a clinical evaluation (Annex II 6.1(c))
  • a post-market surveillance system and a PMS report (Article 85)
  • a person responsible for regulatory compliance (Article 15)
  • an EU authorised representative if you are established outside the EU (Article 11)
  • registration in EUDAMED (see our EUDAMED guide)

The biggest timeline risk on this route is getting the classification wrong. If the software is in fact Class IIa, you will need a Notified Body after all, and all of Phase 2 still lies ahead.

Planning checklist

  1. Fix the intended purpose and the classification in writing before you build the schedule. Record the Rule 11 reasoning and the conformity assessment route.
  2. Run a gap analysis against Annexes I, II and III and the standards you will apply. Turn the findings into owners and dates.
  3. Shortlist Notified Bodies early. Ask each one about its scope for your device, when it could sign a written agreement, when the first audit could take place, how it handles rounds of questions, and its published fees. See our EU MDR budget guide.
  4. Decide which software version you will submit and how changes after submission will be controlled. See change control for AI/ML SaMD.
  5. Start the clinical evidence plan first, because it has the longest lead time.
  6. Book external work early. This includes summative usability participants, penetration testing and any clinical study sites.
  7. Reserve internal capacity. Name owners for requirements, tests, risk and approvals, and protect their time.
  8. Build in buffer for Notified Body rounds. Plan for at least one round of questions, with a named person to coordinate responses.
  9. Prepare for post-market obligations from day one. This means the PMS plan, PMCF, PSUR (for Class IIa, at least every two years), vigilance and change notifications.

Planning around funding rounds and launch dates

Funding milestones and launch dates rarely line up with a Notified Body's calendar. Some approaches hold up in practice:

  • Use milestones you control as investor milestones. Examples are "QMS operating", "technical file submission-ready", "application lodged", "written agreement signed" and "stage audits closed". Avoid "CE mark by Q3".
  • Plan three scenarios. Build a base, a slow and a very slow case from the survey bands above. Make sure the runway covers the slow case, including the cost of keeping the team and the QMS running while you wait.
  • Remember the cascade. Some regulators outside the EU use EU certification as evidence in their own reviews. Australia's TGA, for example, accepts it as comparable overseas regulator evidence. A late EU certificate can therefore delay other markets too. See ASEAN market entry for EU-certified SaMD and TGA registration for EU MDR holders.
  • Communicate a range, not a date. Cite the source for each part of the range: your gap analysis for preparation, and the Commission survey for the Notified Body phase.

No one can promise a certificate date. Notified Bodies assess and decide. Consultants do not certify. As the manufacturer, you remain responsible for your device. A consultant can help you reach a complete, consistent submission and respond well to questions. That shortens the parts of the timeline you control. It cannot guarantee the parts you don't. If you would like a dated preparation plan for your product, see our EU MDR consulting support.

Sources