The EUDAMED certificates module is the part of the European Database on Medical Devices that holds the certificates Notified Bodies issue, amend, suspend, restrict, or withdraw under the MDR. It exists because MDR Article 33 lists "certificates issued by notified bodies" among the purposes of EUDAMED and Article 56 obliges Notified Bodies to enter certificate data into the electronic system. When operational as mandatory, every certificate of conformity that a Notified Body issues for a device under Regulation (EU) 2017/745 becomes a structured, timestamped, publicly visible record — with the Notified Body identified, the manufacturer identified, the scope named, and any later suspension or withdrawal visible to anyone who looks. For a manufacturer, the certificates module is where your regulatory legitimacy becomes a matter of public record.

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

TL;DR

  • The EUDAMED certificates module is one of the six modules of EUDAMED established around MDR Article 33 and operationalised by Commission Implementing Regulation (EU) 2021/2078.
  • MDR Article 56 obliges the Notified Body — not the manufacturer — to enter certificate data into the electronic system, including issuance, amendments, supplements, suspensions, restrictions, reinstatements, and withdrawals.
  • The module captures the certificate number, the Notified Body, the manufacturer, the scope of the certificate, the type of certificate issued under the relevant Annex IX, X or XI procedure, and the validity period, together with any status changes.
  • The public-facing part of the module means that hospital procurement, investors, competitors, and Competent Authorities in other Member States can look up your certificate status without asking you.
  • Mandatory use of the module depends on the Article 34 mechanism. Until the Commission declares this module mandatory, Notified Body certificate data has been entered on a voluntary basis in parallel with pre-existing processes.

A founder finds the certificate online before they find it in their inbox

A founder we worked with got the news in an unexpected order. Their Notified Body had issued the certificate on a Friday afternoon. The signed PDF was still working its way through the Notified Body's internal distribution. On Monday morning, before the official email arrived, a potential hospital customer sent the founder a congratulations note with a link — they had seen the certificate already in the public EUDAMED view. The customer's procurement team had been checking the database weekly as part of their vendor screening.

This is the certificates module in practice. It is not a back-office filing system the Notified Body keeps for its own records. It is a public register that, once operational, becomes the fastest route anyone outside your company has to verify that your device is legitimately certified under the MDR. That changes the way founders should think about certificate issuance — not as a private milestone but as a public event.

What the certificates module captures

The certificates module is built around the data elements that MDR Article 56 requires Notified Bodies to submit. The underlying obligations are in Article 56(5), which tells Notified Bodies to enter into the electronic system on notified bodies and on certificates of conformity (the formal name of the module inside Article 56) information regarding the certificates issued, including amendments and supplements, and information regarding suspended, reinstated, withdrawn or refused certificates and restrictions imposed on certificates. The underlying content of what is issued is defined by Annex XII, which lists the minimum content of certificates issued by a Notified Body.

In practical terms, the module holds the following for each certificate.

The certificate identifier. The unique certificate number issued by the Notified Body, formatted per that Notified Body's numbering scheme and traceable to the decision record behind it.

The Notified Body. The identity of the Notified Body that issued the certificate, including its four-digit Notified Body number — the same number that ends up on the CE mark label for devices subject to Notified Body involvement under MDR Article 20.

The manufacturer. The legal name and Single Registration Number (SRN) of the manufacturer the certificate applies to. If the manufacturer is outside the Union, the authorised representative is also identified.

The type of certificate. Which conformity assessment procedure produced the certificate — whether an EU quality management system certificate, an EU technical documentation assessment certificate, an EU type-examination certificate, or an EU product verification certificate. These types correspond to the procedures described in Annex IX, Annex X, and Annex XI of the MDR. Each type carries different implications for what was assessed and what the certificate authorises.

The scope. What the certificate actually covers — the devices, device categories or generic device groups, and where relevant the Basic UDI-DIs, together with the associated MDR classification. The scope is the substantive answer to the question "what does this certificate legitimise on the market?"

Validity. The date of issue, the date of expiry, and any conditions attached to the validity.

Status changes. Amendments, supplements, suspensions, restrictions, reinstatements, and withdrawals — each one time-stamped and tied back to the original certificate. This history is cumulative: once a status change is entered, it remains part of the visible record.

Refusals. Cases where the Notified Body refused to issue a certificate also flow into the electronic system per Article 56(5), so that Competent Authorities in other Member States can see that a refusal has occurred.

Read together, these elements turn each certificate into a structured data object that can be queried, compared across Notified Bodies, and cross-referenced with device registration data from the UDI/device module. The certificate is no longer just a signed PDF sitting in a manufacturer's file. It is a record with a lifecycle visible from the outside.

Who enters the data — Notified Body or manufacturer

This is the point manufacturers most often get wrong, and getting it right matters for both responsibility and timing.

The certificates module data is entered by the Notified Body, not by the manufacturer. The legal basis is MDR Article 56(5), which puts the obligation to populate the electronic system squarely on the Notified Body. The manufacturer does not upload the certificate PDF. The manufacturer does not type in the scope. The manufacturer does not log the expiry date. The Notified Body does all of this, as part of the decision cycle that ends with the certificate being issued.

The manufacturer's role is upstream and downstream of that entry. Upstream, the manufacturer provides the Notified Body with accurate data — the correct legal name, the verified SRN, the correct Basic UDI-DIs, the precise scope as it should read. Downstream, the manufacturer monitors the record after issuance and raises any discrepancy with the Notified Body promptly. A wrong scope in EUDAMED is not something the manufacturer can unilaterally correct. It requires a correction through the Notified Body that issued the certificate.

The practical consequence is that the manufacturer has to treat Notified Body data hygiene as part of their own quality system. If the manufacturer's SRN changes (for example because of a legal restructuring), the Notified Body has to be told, so that the next certificate entry uses the correct SRN. If a Basic UDI-DI is revised, the same applies. The Notified Body is not reading your QMS updates. You have to push the information to them.

Public visibility and what it actually shows

Parts of the certificates module are public by design. That is not a side-effect of the IT implementation — it is a deliberate choice written into Article 33(2), which names public information about certificates as one of the core purposes of EUDAMED. The certificate data that the Notified Body enters under Article 56 is the substance of that public view.

What a member of the public can see, in the operational target state of the module, is the following: the Notified Body that issued the certificate, the manufacturer and SRN, the certificate number, the type of certificate, the scope (including the classification and the relevant device identifiers), the date of issue, the validity period, and any status change that has been recorded against it. This is enough to answer the practical questions most external parties ask. Is this manufacturer certified? By whom? For what scope? Is the certificate currently valid, or has it been suspended, restricted, or withdrawn?

For a startup, the public view has two immediate consequences. First, it is free marketing when the certificate is in good standing. A hospital procurement team that verifies your certificate in the database before a sales meeting has already cleared the single biggest risk they care about. Second, it is a reputational exposure when anything goes wrong. A suspension entered against your certificate is visible the moment the Notified Body records it, and it is visible to everyone — not just to the authority that triggered the action.

There is no private side door. You cannot ask the Notified Body to "hold" a status change. The purpose of the module is precisely to make these events visible.

Suspension, restriction, and withdrawal display

The most sensitive part of the certificates module is how it handles negative status changes. MDR Article 56(5) makes clear that suspensions, restrictions, reinstatements, and withdrawals all flow into the electronic system alongside the original issuance. The broader obligation for Notified Bodies to suspend, restrict, or withdraw certificates when the manufacturer no longer meets the requirements is set out in MDR Article 53 (on certain aspects of Notified Body involvement) and elsewhere in Chapter V.

In the module, a status change appears as a new entry attached to the original certificate record. The original record is not deleted. A withdrawn certificate does not disappear — it remains visible, with its withdrawal date and, where applicable, the reason. A suspended certificate shows as suspended, with the date of suspension and, once resolved, the date of reinstatement. A restriction — for example a narrowing of scope — is recorded against the original certificate with the new, restricted scope shown.

This historical layer is deliberate. The regulatory intent is that a manufacturer with a history of certificate problems should not be able to hide that history by waiting for a withdrawal to age off the system. Competent Authorities, downstream manufacturers buying components, and hospital procurement teams should all be able to see the track record.

For a founder this means one thing above all: if a status change is coming, assume it will be visible the day it is entered. Plan communications with customers, investors, and staff accordingly. Do not assume that a suspension will stay quiet until you decide to announce it.

What manufacturers should monitor

Given the architecture, a manufacturer's active work on the certificates module comes down to monitoring. The data is entered by the Notified Body, but the responsibility for the data being correct and for errors being corrected promptly sits with the manufacturer — because the manufacturer is the one whose regulatory legitimacy is being displayed.

A lean monitoring routine covers four things. First, check your certificate record after the Notified Body enters it, and confirm that the manufacturer name, SRN, certificate type, scope, Basic UDI-DI references, and validity dates are correct. Do this on the day you are informed that the entry has been made. Second, re-check the record whenever anything changes on your side — a corporate rename, a scope expansion, a technical file amendment that produces a certificate supplement. Confirm that the supplement or amendment has been entered and that it reads correctly. Third, on a fixed cadence — monthly at minimum, weekly during sensitive periods — look at the public view of your own record the way an external party would. This is a five-minute task that catches both Notified Body data errors and any unexpected status changes. Fourth, keep a copy of the Notified Body's evidence of entry in your quality system, so that during a future audit you can show that you verified the record and when.

None of this is complicated. It is boringly procedural. But manufacturers who skip it find out about issues from customers — which is the worst way to find out.

Common misunderstandings

Founders bring a handful of recurring misconceptions to conversations about the certificates module. It is worth naming them directly.

"I upload my certificate to EUDAMED." No. The Notified Body does. Your job is data quality upstream and monitoring downstream.

"The certificate is private between me and the Notified Body." No. Once the module is operational, the certificate becomes a public record with a deliberately public viewing layer.

"Only the current status is visible." No. History is preserved. A withdrawn certificate remains visible as withdrawn, not removed.

"I can ask for errors to be corrected directly in the database." No. Corrections flow through the Notified Body that issued the certificate, because the Notified Body is the data owner under Article 56.

"The certificates module only matters once it becomes mandatory." No. Notified Bodies have been entering certificate data on a voluntary basis as the module has rolled out. Your certificate may already be visible, or may become visible without a separate notification to you. Check.

"A CE mark on the product is enough; nobody looks at the database." Increasingly they do. Hospital procurement, investors, competitors, and Competent Authorities in other Member States all use EUDAMED as a verification layer precisely because it is faster than asking the manufacturer.

The Subtract to Ship angle

There is almost nothing to add on the manufacturer side of the certificates module — which is itself a Subtract to Ship lesson. The work is not building a new process. The work is making sure the existing data flow between you and your Notified Body is clean enough that the module, once mandatory, reflects your regulatory state accurately without additional effort.

Strip the work to what it actually is. One clean set of manufacturer data in the Notified Body's file (legal name, SRN, authorised representative if applicable, PRRC). One clean set of scope data per certificate (Basic UDI-DIs, device descriptions, classification). One monitoring cadence. One correction route through the Notified Body. That is the list. Founders who try to build a "EUDAMED certificates readiness programme" on top of that are adding overhead for its own sake. See the Subtract to Ship framework for MDR for why this matters.

Reality Check — Where do you stand on the certificates module?

  1. Do you know whether your Notified Body has already entered any of your certificate data into the EUDAMED certificates module on a voluntary basis, and have you checked what is visible?
  2. Is the manufacturer legal name your Notified Body holds on file identical to the name on your SRN record in EUDAMED?
  3. Are the Basic UDI-DIs in your technical file consistent with the Basic UDI-DIs your Notified Body would use when entering a certificate?
  4. Do you have a written internal procedure for verifying a certificate record in EUDAMED after issuance and for escalating corrections through the Notified Body?
  5. If a suspension or restriction were entered against your certificate tomorrow, do you know how quickly it would become publicly visible and how you would communicate with customers and investors?
  6. Have you briefed your sales team on the fact that hospital procurement can verify your certificate in the public database, and that this is usually a sales advantage rather than a risk?
  7. Do you monitor the public view of your own certificate record on a fixed cadence?

If you cannot answer four or more of these cleanly, your interface with the certificates module is informal, and informal is the state in which correction loops take weeks instead of hours.

Frequently Asked Questions

What is the EUDAMED certificates module? The EUDAMED certificates module is one of the six modules of the European Database on Medical Devices, established around MDR Article 33 and operationalised by Commission Implementing Regulation (EU) 2021/2078. It holds the data on certificates issued, amended, suspended, restricted, reinstated, and withdrawn by Notified Bodies under the MDR, as required by MDR Article 56.

Who enters certificate data into EUDAMED — the Notified Body or the manufacturer? The Notified Body. MDR Article 56(5) obliges Notified Bodies to enter information on issued, amended, suspended, restricted, reinstated, withdrawn, and refused certificates into the electronic system. The manufacturer's role is to provide accurate data upstream to the Notified Body and to monitor the record downstream after entry.

Is my certificate publicly visible in EUDAMED? Once the module is operational, yes. Article 33(2) names certificate information among the purposes EUDAMED serves for public information. The certificate number, Notified Body, manufacturer, scope, type, validity, and any status changes are designed to be publicly accessible.

What happens in EUDAMED if my certificate is suspended or withdrawn? A suspension, restriction, or withdrawal is entered as a status change against the original certificate record under Article 56(5). The original record remains visible with the new status, date, and where applicable the reason. The history is preserved rather than deleted, and Competent Authorities in other Member States can see it alongside the original issuance.

How do I correct an error in my EUDAMED certificate record? Through the Notified Body that issued the certificate. The Notified Body is the data owner for entries in the certificates module, and corrections flow through their internal process. Raise the issue in writing, reference the specific data field, and keep a copy of the correspondence in your quality system.

Is the certificates module mandatory yet? Mandatory use depends on the Article 34 mechanism. The Commission declares modules functional and mandatory through notices in the Official Journal. Until the certificates module is formally declared mandatory for a given obligation, Notified Bodies have been entering data on a voluntary basis in parallel with pre-existing processes. Check the current status on the Commission's EUDAMED information page before acting — see EUDAMED status in 2026.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 33 (European database on medical devices — Eudamed), Article 34 (functioning of Eudamed), Article 53 (general obligations of notified bodies regarding certain aspects of conformity assessment), Article 56 (certificates of conformity — issuance and obligation to enter certificate data into the electronic system), and Annex XII (certificates issued by a notified body — minimum content). Official Journal L 117, 5.5.2017.
  2. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 laying down rules for the application of Regulation (EU) 2017/745 of the European Parliament and of the Council as regards the European Database on Medical Devices (Eudamed). OJ L 426, 29.11.2021.
  3. European Commission, EUDAMED information page — current module status, Commission notices, and public view of Notified Bodies and certificates. Readers should consult the Commission page directly for the live status of the certificates module before relying on its mandatory application.

This post is part of the EUDAMED, UDI and Registration category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. For the live status of the certificates module and for the pillar overview of EUDAMED, see the companion posts linked above.