EUDAMED is the European Database on Medical Devices established by MDR Article 33. It is the central EU-level IT system that will hold registration data for manufacturers, authorised representatives, and importers; for devices and their UDIs; for certificates issued by Notified Bodies; for clinical investigations; for vigilance and post-market surveillance; and for market surveillance. EUDAMED is structured as six modules. Under MDR Article 34, mandatory use of a module is triggered only once the Commission has declared that module functional. Until then, the pre-existing national registration and reporting obligations continue in parallel. For a startup, EUDAMED is the public register your device will eventually live on — and the first place an auditor, hospital procurement team, or competitor will look.

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

TL;DR

  • EUDAMED is established by MDR Article 33 and is designed as the single EU-level database for medical device registration, transparency, and market surveillance.
  • EUDAMED is built as six modules: actor registration, UDI/device registration, Notified Bodies and certificates, clinical investigations and performance studies, vigilance and post-market surveillance, and market surveillance.
  • MDR Article 34 conditions mandatory use of EUDAMED on the Commission publishing a notice that the system, or specific modules, are functional. Until that trigger fires for a given module, the corresponding Member State-level obligations remain in force.
  • Commission Implementing Regulation (EU) 2021/2078 sets out the detailed functioning rules for EUDAMED: registration, access, nomenclature, data ownership, security, and contingency procedures.
  • For startups, the practical consequence is radical transparency. Once your device is in EUDAMED, your SRN, device UDI, clinical investigation summaries, certificate data, and eventually safety information become visible to the public, to competitors, and to hospital procurement — by design.

You read Article 33 and wondered what you were actually supposed to do

A founder sends the same email every few months. They read MDR Article 33, saw the phrase "European database on medical devices," opened the public EUDAMED website, found a system that looks partly live and partly not, and could not tell whether they were supposed to register something, whether they were required to, when the deadline was, and what happens to the obligations they already have at national level. The confusion is not their fault. EUDAMED is one of the most technically ambitious parts of the entire MDR and its roll-out has been staggered across multiple years, with some modules available on a voluntary basis long before the legal mandate activates.

This post is the orientation. It answers what EUDAMED is, why it exists, how it is structured, what is mandatory now versus voluntary depending on the module, and what it means for a small company trying to bring a device to market without a regulatory affairs department. It is the pillar post of the EUDAMED, UDI and Registration cluster on this blog — every deeper-dive post in the cluster links back here.

What EUDAMED is

EUDAMED is the name of the IT system that the European Commission is required to set up, maintain, and manage under MDR Article 33. The article is explicit about the purposes of the system. It is to enable the public to be adequately informed about devices placed on the market, the corresponding certificates, and the economic operators involved. It is to allow unique identification of devices within the Union market and to facilitate their traceability. It is to enable the public to be adequately informed about clinical investigations and to enable sponsors to comply with their obligations. It is to enable manufacturers to comply with information obligations. It is to enable Competent Authorities to carry out their tasks. And it is to enhance communication between Competent Authorities and between them and the Commission.

In plain language, EUDAMED is the EU's attempt to replace a fragmented landscape of 27 Member State databases with a single source of truth for everything that needs to be registered, tracked, and made public under MDR. It is the database on which your device's regulatory identity lives. It is where the Notified Body posts the certificate. It is where UDIs are registered. It is where clinical investigation summaries end up. It is where serious incidents and field safety corrective actions are eventually reported. And importantly, significant parts of EUDAMED are public — anyone can look up a manufacturer, a device, or a certificate.

EUDAMED's detailed functioning rules are set out in Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021. That implementing act defines registration procedures, access rights, the nomenclature used (EMDN), technical support, data ownership, malfunction contingency procedures, information security, and personal data processing. Any question about how EUDAMED actually works — as opposed to what it is supposed to achieve — is answered by reading (EU) 2021/2078 alongside Article 33.

Why EUDAMED exists

Before MDR, device registration in the EU was handled nationally. A manufacturer placing a device on the German market registered with BfArM. A French importer registered with ANSM. An Austrian distributor notified BASG. The same device ended up in multiple national databases under different identifiers, with different levels of public access, and no reliable way for a Competent Authority in one Member State to see what had happened to the same device in another Member State. Market surveillance was hobbled by this fragmentation. So was public transparency. Patients and clinicians who wanted to check whether a device they were about to use had ever been the subject of a safety notice had no consistent way to do it.

The MDR was designed to close these gaps. EUDAMED is the IT backbone of that design. The goals in Article 33(2) are transparency, traceability, coordinated enforcement, and reduction of duplicate reporting burden. The reason the system matters for a startup is not abstract. It is that once EUDAMED is fully functional, the public-facing modules make your regulatory state visible — your SRN, your registered devices, the status of your certificates, the summaries of your clinical investigations, and ultimately safety information linked to your device. Transparency of this kind is a feature, not a bug. It is also a competitive reality a founder needs to plan for.

The module structure

EUDAMED is built as six interlocking modules. The structure is defined by MDR and reinforced by (EU) 2021/2078. Each module serves a distinct purpose and each one has its own go-live timeline.

1. Actor registration. The first module, and the first one to go live on a voluntary basis. It registers the economic operators themselves — manufacturers, authorised representatives, importers, and system/procedure pack producers — and issues each one a Single Registration Number (SRN). The SRN is the identifier that every subsequent EUDAMED interaction uses to tie activity back to a specific legal entity. MDR Article 31 sets out the registration obligation for manufacturers, authorised representatives, and importers. The SRN is explained in its own deep-dive post: what is the Single Registration Number (SRN).

2. UDI and device registration. The second module registers the devices themselves and their Unique Device Identifiers. UDI obligations are set out in MDR Articles 27 and 29; the data to be submitted and kept up to date is specified in Annex VI. Each device is registered by the manufacturer under its SRN, with the Basic UDI-DI as the core identifier that groups device variants for regulatory purposes. The UDI concept is covered in what is a UDI and MDR Articles 27-29 UDI requirements. The device registration workflow itself is covered in device registration in EUDAMED.

3. Notified Bodies and certificates. The third module holds the list of designated Notified Bodies and the certificates they issue, suspend, restrict, or withdraw under MDR. When your Notified Body issues your certificate, it flows into EUDAMED and becomes visible through this module. The certificate module is covered in the EUDAMED certificates module.

4. Clinical investigations and performance studies. The fourth module holds information on clinical investigations under MDR Articles 62-82 and Annex XV, including sponsor applications, summaries, and results. This module is how the MDR delivers on the transparency promise in Article 33(2) regarding clinical investigations.

5. Vigilance and post-market surveillance. The fifth module handles serious incident reports, field safety corrective actions, trend reports, and Periodic Safety Update Reports. The underlying obligations are in MDR Articles 87-92 for vigilance and Articles 83-86 for PMS. This is where your post-market safety footprint eventually lives. For the vigilance side specifically see the EUDAMED vigilance module.

6. Market surveillance. The sixth module supports the activities of Competent Authorities under MDR Articles 93-100: inspections, non-compliance findings, enforcement actions, and coordination between Member States.

Read together, the six modules cover the full lifecycle of a device and every economic operator that touches it. That is the design intent of Article 33 and the reason EUDAMED is as large a project as it is.

What is mandatory now versus voluntary

This is the part founders are most likely to get wrong, and it is the part that requires the most care to state accurately.

MDR Article 34 governs the functioning of EUDAMED and the conditions for mandatory use. The legal mechanism is as follows. The Commission, after verifying that EUDAMED has reached full functionality and that the system meets the functional specifications, publishes a notice to that effect in the Official Journal. The mandatory obligations that are tied to EUDAMED in the substantive articles of the MDR — the registration obligations under Articles 29 and 31, the certificate data obligations on Notified Bodies, the vigilance reporting obligations under Articles 87-92, and the clinical investigation transparency obligations — then become enforceable through EUDAMED six months after that notice (subject to the transitional rules in Article 123 for specific obligations).

Article 34 was later amended to allow the Commission to declare individual modules functional independently of the full system, so that modules can be made mandatory one at a time as they become ready, rather than waiting for the entire system. Under this revised mechanism, a module that has been audited and declared functional triggers its specific mandatory use after the implementing decision and the corresponding transitional period, while other modules that are not yet declared functional remain voluntary.

The practical consequence for a founder is this. Some EUDAMED modules have already been made available on a voluntary basis. Using the voluntary version is permitted and often sensible, because it gets your data into the system early and familiarises your team with the workflows. But a module that is still voluntary does not replace the pre-existing national registration and reporting obligations. If you register your company voluntarily in EUDAMED actor registration, you still have to comply with whatever national actor registration obligations apply to you until the Commission declares that module mandatory. The rule is additive while the system is in transition, not substitutive.

Status caveat for this post. EUDAMED module go-live status is shifting and the specific mandatory dates for each module depend on Commission implementing decisions that are published as each module is audited and declared functional. This pillar post deliberately avoids stating a specific module as "mandatory as of date X" in 2026, because such a claim would age badly and could mislead a founder into missing a parallel obligation. The honest position is: read Article 34, check the current status of each module on the Commission's EUDAMED information page before acting, and when in doubt assume the parallel national obligation remains in force. For a live view of current module status, see the companion post EUDAMED status in 2026, which is maintained as a living document.

The actor registration path

For a startup, the first EUDAMED touchpoint is actor registration. This is the module that issues your SRN, and the SRN is what every subsequent EUDAMED activity — device registration, certificate issuance, vigilance reporting — attaches to. The actor registration obligation is set out in MDR Article 31 for manufacturers, authorised representatives, and importers. Article 31(1) requires these economic operators, before placing a device on the market, to submit to the EUDAMED actor registration system the information referred to in Annex VI, Part A, Section 1.

The information required includes the type of economic operator, the name, address, and contact details of the entity, the name, address, and contact details of the person(s) responsible (including the PRRC under Article 15 for manufacturers), and data needed to identify the operator. For manufacturers established outside the Union, the actor registration is done by the authorised representative on behalf of the manufacturer.

Once the Competent Authority of the Member State verifies the data, EUDAMED issues the SRN. The SRN is unique, permanent, and public. It becomes the identifier used across every other module. The workflow itself is covered step-by-step in how to register your startup as a manufacturer in EUDAMED.

The UDI and device registration path

Once you have an SRN, you can register devices. This is done through the UDI/device registration module and the obligations flow from MDR Articles 27, 28, and 29, with the data specification in Annex VI Part B.

Article 27 establishes the UDI system itself. Each device must carry a UDI, which consists of a UDI-DI (device identifier, unique to the device model) and a UDI-PI (production identifier, identifying production-specific information such as lot number, serial number, manufacturing date, or expiry date). The Basic UDI-DI sits above individual UDI-DIs and is the main key used for regulatory filings — it groups together devices that share the same intended purpose, risk class, essential design and manufacturing characteristics, and is the identifier that links the device to its technical documentation, its certificate, and its clinical evaluation.

Article 29 requires the manufacturer to submit to EUDAMED, before placing a device (other than custom-made) on the market, the Basic UDI-DI and the information referred to in Annex VI Part A, Section 2, and to ensure that this information is up to date. The manufacturer is also responsible for assigning UDIs to devices and their packaging according to the rules set by the issuing entities designated by the Commission.

The consequence for a startup is that the UDI and device registration path is non-trivial. It requires decisions about Basic UDI-DI grouping, selection of a UDI issuing entity, allocation of UDI-DIs and UDI-PIs, and integration of UDI carriers onto labels and packaging. None of this is optional once the module becomes mandatory, and it is the kind of work that is far cheaper to do while the technical file is being built than to retrofit afterwards. The deep dives for this path are what is a UDI, MDR Articles 27-29 UDI requirements, and device registration in EUDAMED.

Note also MDR Article 32 on the Summary of Safety and Clinical Performance (SSCP). For implantable devices and for Class III devices other than custom-made or investigational, the manufacturer must draw up an SSCP, and the SSCP is made publicly available through EUDAMED once validated by the Notified Body. The link between Article 32 and EUDAMED is deliberate: SSCPs are a pillar of the public transparency layer the Regulation is trying to achieve.

The transparency implications for startups

This is where the consequences become visible for the business, not just the regulatory file. Parts of EUDAMED are public by design, and the public parts grow as more modules become mandatory.

The public side already includes, or is designed to include, the following. Actor information — your company name, SRN, country of establishment, and the name of your PRRC for the regulatory role. Device information — your Basic UDI-DI, device model, risk class, and status (on market, withdrawn, recalled). Certificate information — the Notified Body, the certificate number, the scope, the date of issue, and any suspension or withdrawal. SSCPs for implantable and Class III devices. Summaries of clinical investigations. Field safety notices. And eventually, aggregate vigilance data.

For a founder, this has four consequences worth thinking through before the module you depend on goes live.

First, due diligence by customers and investors. Hospital procurement teams, investors doing commercial due diligence, and partners considering distribution deals will check EUDAMED. An active certificate, a clean vigilance record, and a coherent SSCP are commercial assets. Missing or inconsistent data is a red flag.

Second, competitor intelligence. Your competitors will check EUDAMED as part of their own market research. They can see your SRN, your registered devices, your Notified Body, the date your certificate was issued, and the scope. This is public information. Plan your public-facing regulatory data the way you would plan your marketing copy — because it is part of the same public picture.

Third, audit trail visibility. Anything that goes into EUDAMED is timestamped and traceable. A retroactive correction to a device registration is itself a data point. Auditors notice. Your own future team, months later, will be glad the data was accurate on first submission.

Fourth, permanence. EUDAMED data is not easily deleted. An entity registered incorrectly, a Basic UDI-DI grouped wrongly, or a certificate entered with the wrong scope is not something you quietly fix and forget — the correction itself becomes part of the visible history. Get it right the first time.

How EUDAMED changes startup strategy

Three things change once you take EUDAMED seriously as a founder.

The first is timing. You cannot treat registration as a task you get around to after certification. The actor registration has to happen before you place a device on the market, which under Article 31(1) is a legal requirement tied to Article 10. Device registration has to happen before first placement and has to be kept up to date. EUDAMED work is not a post-certification afterthought; it is a pre-launch milestone.

The second is data discipline. Every piece of information that goes into EUDAMED must be consistent with the information in your technical file, your labels, your IFU, your website, and your Notified Body submission. Inconsistency between EUDAMED and the rest of your file is a finding waiting to happen. Decide once, record it cleanly, and use the same data everywhere.

The third is public-facing regulatory positioning. If your device is visible in a public database — with its class, its Notified Body, its certificate status, and eventually its safety signals — then regulatory state is part of your public brand. A startup that treats its regulatory identity as operational plumbing rather than as a business asset is leaving value on the table.

The Subtract to Ship angle on EUDAMED

EUDAMED looks intimidating from the outside and this is precisely where the Subtract to Ship discipline helps. Strip the work in the EUDAMED cluster down to what MDR Articles 29, 30, 31, 32, 33, and 34 actually require, plus the detailed rules in (EU) 2021/2078. Everything else — the speculative tooling, the custom dashboards, the "EUDAMED readiness consultancy" sold as a separate engagement when your Notified Body already covers it — either traces to one of those articles or it does not belong in the plan.

The actual EUDAMED work for a small manufacturer is finite. One SRN. One Basic UDI-DI per device family. One UDI issuing entity. One clean set of Annex VI data, kept current. One PRRC identified. One authorised representative (if you are outside the EU) registered properly. A change-management process so that every product change triggers a EUDAMED update where required. That is the list. When a founder shows us a EUDAMED plan that is longer than that list, we ask them to defend each extra item against a specific MDR article. Usually the extra items come out.

See the Subtract to Ship framework for MDR for the full methodology. The EUDAMED cluster is an unusually good place to apply it because the work scales with real device complexity, not with consultant imagination.

Reality Check — Where do you stand on EUDAMED?

  1. Can you name the six EUDAMED modules and say which one is your first entry point?
  2. Do you have a Single Registration Number (SRN) yet, and if not, do you know which Member State Competent Authority will verify your actor registration?
  3. Have you decided on a UDI issuing entity, or is this still an open question in your technical planning?
  4. Have you identified your Basic UDI-DI strategy — how devices will be grouped for regulatory purposes — and is that grouping consistent with your technical documentation?
  5. Do you know which of your existing national registration obligations persist in parallel because the relevant EUDAMED module has not yet been declared mandatory?
  6. If a hospital procurement team or an investor looked your company up in EUDAMED tomorrow, what would they see, and is that what you want them to see?
  7. Is your PRRC under Article 15 correctly listed on the actor registration data that will flow to EUDAMED?

If you cannot answer four or more of these cleanly, EUDAMED is a knowledge gap in your plan, not a checkbox.

Frequently Asked Questions

What is EUDAMED in simple terms? EUDAMED is the European Database on Medical Devices established by MDR Article 33. It is the central EU IT system that registers economic operators, devices and their UDIs, Notified Body certificates, clinical investigations, vigilance reports, and market surveillance activities. Parts of it are public and parts are restricted to authorities and manufacturers.

Is EUDAMED mandatory for startups? It depends on the specific module and its current status under MDR Article 34. A module becomes mandatory once the Commission declares it functional and the relevant transitional period ends. Until then, the corresponding national obligations remain in force in parallel. A founder should check the current status of each module before deciding which obligations apply to them today.

What is an SRN in EUDAMED? The Single Registration Number is the unique identifier EUDAMED issues to each economic operator — manufacturer, authorised representative, or importer — after their actor registration data is verified by the Competent Authority. The SRN is the key that ties every other EUDAMED activity back to a specific legal entity. It is explained in detail in the post on the Single Registration Number.

What is the difference between UDI and Basic UDI-DI? The UDI is the full Unique Device Identifier carried on the device, consisting of a UDI-DI (device identifier) and a UDI-PI (production identifier, for lot or serial). The Basic UDI-DI sits above the UDI-DI and groups devices that share the same intended purpose, risk class, essential design, and manufacturing characteristics. The Basic UDI-DI is the identifier used in EUDAMED, in the technical documentation, on the certificate, and in the clinical evaluation. Both are defined in MDR Article 27.

Where do I actually register in EUDAMED? EUDAMED is accessed through the European Commission's EUDAMED information page. Actor registration is the entry point, and registration is verified by the Competent Authority of the Member State where your organisation is established (or, for non-EU manufacturers, where the authorised representative is established). The workflow is covered step-by-step in how to register your startup as a manufacturer in EUDAMED.

Is my EUDAMED data public? Parts of it are. Actor information, device information including Basic UDI-DI, certificate information, SSCPs for implantable and Class III devices, clinical investigation summaries, and field safety notices are designed to be publicly accessible. Other parts — such as internal vigilance exchanges and some market surveillance data — are restricted to authorities.

What happens if I register the wrong data in EUDAMED? You correct it, but the correction itself is traceable. EUDAMED maintains a record of changes. Auditors, Competent Authorities, and potentially the public can see that a record was updated. The practical rule is: get it right the first time, and when corrections are necessary, make them promptly and with a documented internal rationale.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 27 (UDI system), Article 28 (UDI database), Article 29 (registration of devices), Article 30 (electronic system on registration of economic operators), Article 31 (registration of manufacturers, authorised representatives and importers), Article 32 (Summary of Safety and Clinical Performance), Article 33 (European database on medical devices — Eudamed), Article 34 (functioning of Eudamed), Articles 87-92 (vigilance), Annex VI (information to be submitted for registration of devices and economic operators, and Basic UDI-DI/UDI data elements). 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, user guides, and Commission notices on functional declarations. (Readers should consult the Commission page directly for the live mandatory/voluntary status of each module before acting.)

This post is the pillar of the EUDAMED, UDI and Registration category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Every spoke in the cluster links back here. If the status of a specific module has changed since the last updated date on this post, the companion post on EUDAMED status is maintained as a living document and supersedes any time-sensitive statements here.