Selecting a notified body for software as a medical device is one of the earliest decisions that materially affects a CE marking timeline, and it is made under conditions that differ from those facing a hardware manufacturer. A notified body is a conformity assessment body designated by an EU member state under Regulation (EU) 2017/745 to verify that a device satisfies the requirements of that regulation before it is placed on the market, and its involvement is mandatory for every device above Class I.
For software, that threshold is reached earlier than manufacturers often expect. Rule 11 of Annex VIII classifies software intended to provide information used to take decisions for diagnostic or therapeutic purposes as Class IIa, unless those decisions may cause a serious deterioration of health or a surgical intervention, in which case the device is Class IIb, or may cause death or an irreversible deterioration of health, in which case it is Class III.
Software intended to monitor physiological processes is likewise Class IIa or Class IIb, where it monitors vital physiological parameters.
For manufacturers of standalone software, the selection of that body differs from the hardware case in three respects that together determine both cost and schedule. The conformity assessment examines a development process rather than a production line, which alters the content of the quality management system audit and the locations at which it is conducted.
The number of reviewers authorised against the software codes is materially smaller than the number of designated bodies would suggest, so designation and available capacity cannot be treated as the same question.
A substantial part of the assessment also falls in areas where the applicable guidance permits interpretation, among them classification under Rule 11, the evidence expected for third-party and cloud components, the clinical evidence expected where no comparable device exists, and the handling of changes to a product released on a continuous cycle.
For that reason, two designated bodies presented with the same technical documentation can arrive at different conclusions, with consequences for the conformity assessment route as well as for the timeline.
The legal basis of the choice
Article 52 of the MDR determines which conformity assessment procedure applies to each class of device, while Annex IX, Annex X, and Annex XI describe those procedures in detail, and Annex VII establishes the requirements a body must satisfy in order to be designated. Section 4.3 of Annex VII governs the review of a manufacturer’s application, under which the notified body verifies the codes proposed by the manufacturer or assigns them itself and carries out a feasibility evaluation to confirm both that the application falls within its designation and that it has the resources available to perform the assessment.
The final assignment of codes, therefore, remains a decision of the notified body rather than of the manufacturer.
Certificates issued under the MDR are valid for a maximum of five years under Article 56(2) and remain subject to surveillance throughout that period, which means that every certified manufacturer returns to the same pool of reviewers on a fixed and predictable cycle.
The MDR codes for software
The scope of a designation is expressed in the codes established by Commission Implementing Regulation (EU) 2017/2185, of which two apply directly to standalone software:
- MDA 0315, the active device code covering software.
- MDS 1009, the horizontal code for devices incorporating, utilising or controlled by software, including devices intended for controlling, monitoring or directly influencing the performance of active or active implantable devices.
MDCG 2019-14 sets out how these codes function in practice, explaining that designating authorities use them to define the scope of a body’s designation, while the body itself uses them to describe both the qualification of individual staff members and the qualification required to assess a particular device.
Because MDS codes are principally relevant to the allocation of personnel reviewing technical documentation, a body may hold the software codes and still have very limited reviewer availability against them, which is a common reason for the gap between an encouraging first conversation and a slow assessment.
Designation and scope can be verified in NANDO, the European Commission’s database of notified and designated organisations, and since the Notified Bodies and Certificates module in EUDAMED became mandatory on 28 May 2026, there is also a public view of the certificates that bodies have registered. Consulting both sources allows a manufacturer to separate what a body is permitted to certify from what it has demonstrably certified in the relevant device category.
Notified body capacity in 2026
The European Commission’s 20th Notified Body survey, published on 2 July 2026 with a data cutoff of 28 February 2026, recorded 53 active respondents, of which 52 were designated under the MDR and 19 under the IVDR. Several bodies hold both designations, so the two figures cannot be added together.
The 18th survey, published in March 2026, reported 33,175 applications submitted under the MDR against 17,549 certificates issued, and aggregate data from the same source indicate that approximately 48 percent of MDR certificates are issued within 13 to 18 months of application. At the bodies in highest demand, an intake queue of 6 to 12 months precedes the start of formal assessment.
Two structural factors keep that load in place. Regulation (EU) 2023/607 amended Article 120 of the MDR to extend the transitional periods to 31 December 2027 for Class III and most implantable Class IIb devices, and to 31 December 2028 for other Class IIb, Class IIa and Class Is, Im and Ir devices, subject to conditions that included lodging an application with a designated body by 26 May 2024 and signing a written agreement by 26 September 2024.
A large volume of legacy documentation is consequently still working its way through the system. At the same time, the MDR certificates first issued in 2021 and 2022 are reaching the end of their five-year validity from 2026 onward, which adds recertification work to the same reviewer pool that is processing new applications.
For planning purposes, the intake period and the assessment period should be estimated separately rather than as a single figure, and manufacturers are well advised to obtain both in writing from each candidate body: the expected time from signature of the contract to the start of formal conformity assessment, and the expected time from the start of assessment to issue of the certificate, assuming that no major non conformities arise.
Areas of interpretation specific to software
The points below account for most of the variation observed between bodies, and each of them is considerably less expensive to resolve during the pre-application discussion than after a contract has been signed.
Classification under Rule 11
MDCG 2019-11 addresses the qualification and classification of medical device software, but the boundary between Class IIa and Class IIb continues to be applied with some variation between bodies and between reviewers. Since classification determines the conformity assessment route, the depth of scrutiny, and ultimately the cost of certification, a classification rationale that has not been confirmed with the intended body carries more risk than any other open item in an application.
Software lifecycle documentation
IEC 62304 establishes requirements for the software lifecycle without prescribing a particular development model, yet review teams differ appreciably in the ease with which they accept documentation generated by an iterative process, which is one reason the software architecture is worth structuring for review from the outset and in the artefacts they expect to see at each stage.
The question to be settled with a candidate body is therefore one of reviewer familiarity with contemporary development practice rather than one of compliance in the abstract.
Third-party and cloud components
Software of unknown provenance requires justification and appropriate risk control, and for a manufacturer whose product runs on infrastructure it neither owns nor operates, the exercise of supplier control over a large cloud service provider is a recurring source of non-conformities. Expectations for the supporting evidence vary sufficiently between bodies that the point deserves a specific question rather than an assumption.
Clinical evaluation
MDCG 2020-1 sets out the clinical evaluation of medical device software and the clinical data requirements that follow. Because equivalence routes are frequently unavailable to software products, the more consequential question is what a given body will accept as clinical evidence where no comparable device exists, since the answer determines whether a clinical investigation must be planned and budgeted from the outset.
Cybersecurity and usability
MDCG 2019-16 covers cybersecurity for medical devices, IEC 62366-1 covers usability engineering, and IEC 82304-1 applies to health software products. All three will be assessed in any event, but whether those reviews are conducted in parallel with the main technical documentation review or sequentially after it has a direct and frequently underestimated effect on total elapsed time.
Changes after certification
The MDR contains no equivalent of the predetermined change control plan available under the United States framework, so substantial changes to the design or intended purpose of a certified device require notification to the notified body. Since the criteria applied, the turnaround time for assessment, and the associated fees all differ between bodies, this single set of terms governs the release process for the entire life of the certificate.
Artificial intelligence
Where a device incorporates machine learning, the expectations for retraining, performance monitoring, and post-market performance data should be established before contracting rather than discovered during review. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the application of the AI Act high-risk obligations for AI embedded in regulated products, medical devices among them, to 2 August 2028.
It is therefore reasonable to ask at the selection stage whether a candidate body intends to seek designation under the AI Act and how it proposes to combine that assessment with conformity assessment under the MDR.
The quality management system audit without a production site
A manufacturer of standalone software has no production line, no sterilisation process, and no incoming goods inspection, so the ISO 13485 audit conducted by the quality assurance function of the body concentrates instead on design and development controls, on configuration and release management, on supplier control over infrastructure and outsourced development, and on the flow of post-market surveillance data back into the design process.
Distributed organisations should settle three further points at the contract stage rather than later. The locations subject to audit need to be agreed explicitly where development, the legal manufacturer, and contracted work are situated in different countries, since each additional audited site carries its own cost and scheduling constraint.
The balance between remote and on-site auditing varies between bodies and influences the total cost of surveillance considerably more than the published day rate does, and MDCG 2022-14 endorsed hybrid audits among the measures intended to relieve capacity pressure.
The surveillance regime, including the unannounced audits required by section 3.4 of Annex IX, also extends to critical suppliers, so the treatment of cloud and development suppliers in that context should be clarified before it becomes a live issue.
Questions for the pre-application stage
The pre-application discussion is the point at which competence can be tested, and the questions worth asking are those to which the answers genuinely differ between bodies. It is useful to establish how many standalone software certificates the body has issued in the past 24 months and in which clinical areas, how many reviewers it has authorised against MDS 1009 and what their availability is over the coming two quarters, and how it reads Rule 11 for the specific intended purpose in question.
It is equally useful to establish what documentation the body expects under IEC 62304 from an iterative development process, what evidence it requires for third party components and for infrastructure operated by a cloud provider, what it accepts as clinical evidence where equivalence is unavailable, whether cybersecurity and usability reviews run in parallel with the technical documentation review, and what criteria, turnaround times and fees apply to the assessment of changes after certification.
Where a body offers a structured dialogue or a pre-application review, the terms on which it does so are worth establishing at the same time.
Contractual terms
The published day rate is a weak predictor of both total cost and elapsed time, and the terms that determine them are found elsewhere in the contract: the number of rounds of questions included before additional fees apply, the committed turnaround time for reviewing responses to non conformities, the fees and turnaround for change notifications during the certificate period, the precise wording of the certificate scope and whether it accommodates the product variants already on the roadmap, and the identity of the named contact together with the escalation path available when a review stalls.
Scale of the notified body
Certificates issued by any designated body carry identical legal weight, although procurement practice in certain markets attaches informal confidence to certificates from the largest and most widely recognised bodies, an effect that occasionally surfaces in hospital tenders and in multi-country framework agreements. For most manufacturers, certificate validity, correct registration in EUDAMED, and consistency between the registered data and the certificate itself matter considerably more than the identity of the issuing body.
Smaller bodies frequently offer shorter intake queues and more direct access to the reviewers handling the file, and for a first certificate on a Class IIa software device, that access tends to be worth more than recognition. A manufacturer preparing for acquisition or for a large tender programme may reasonably weigh the same considerations in the opposite direction.
A sequence for notified body selection
The process is best begun well before the technical documentation is complete, and four to eight weeks is a realistic allowance for it. The first step is to define the device in writing, covering intended purpose, classification and the rationale supporting it, together with the proposed MDR codes, since no useful conversation with a notified body can take place without those elements. A longlist is then assembled from NANDO, filtered on MDA 0315 and MDS 1009, and cross-checked against the certificates visible in EUDAMED.
An identical written enquiry covering device type, classification, target date, and the two timing questions set out above is sent to six to eight bodies, since identical wording is what makes the responses comparable. Pre-application discussions follow with the three or four bodies that respond substantively, ideally with the software lead present alongside the regulatory lead, and the final comparison is made on total elapsed time and contractual terms rather than on headline price.
Frequently asked questions
Does software always need a notified body under the MDR?
Only Class I software may be self-certified, and Rule 11 of Annex VIII places most software with a diagnostic, therapeutic, or monitoring purpose in Class IIa or above, so the involvement of a notified body is the normal outcome rather than the exception.
Which MDR codes should appear in an application for standalone software?
MDA 0315 covers software as an active device, and MDS 1009 is the horizontal code for devices incorporating, utilising, or controlled by software. Both should be checked against the designation of each candidate body in NANDO before any commercial discussion begins.
How long does certification take for a Class IIa software device?
Aggregate data from the European Commission’s Notified Body surveys indicate that approximately 48 percent of MDR certificates are issued within 13 to 18 months of application, and at the bodies in highest demand, an intake queue of 6 to 12 months precedes the start of formal assessment. Both periods should be estimated separately when planning a launch.
Can a manufacturer change the notified body during certification?
A change is possible but expensive in time, since the incoming body must repeat the application review and the feasibility evaluation under section 4.3 of Annex VII, and any surveillance arrangements must be transferred. Establishing scope, capacity, and software competence before contracting is considerably cheaper than correcting the choice afterwards.
Is a certificate from a smaller notified body worth less?
No. Certificates issued by any body designated for the relevant codes carry identical legal weight under the MDR, and differences in market perception are informal and confined to certain procurement contexts.
Verification
Designations, scopes, and capacity all change during the course of a year. NANDO remains the authoritative source for designation and scope, and EUDAMED for registered certificates, while neither provides reliable live capacity data, which is why written confirmation from the body that it is accepting applications for the specific device type continues to be necessary.
Aura Health supports software and AI medical device manufacturers through notified body selection, application preparation and conformity assessment, including classification rationale, technical documentation, clinical evaluation and audit readiness.
Enquiries can be directed to hello@aurahealth.ch.