---
title: Device Registration in EUDAMED: Step-by-Step for Startups
description: Registering a device in EUDAMED under MDR Article 29 is a sequence of specific steps. Here is the startup walkthrough with the exact data fields required.
authors: Tibor Zechmeister, Felix Lenhard
category: EUDAMED, UDI & Registration
primary_keyword: device registration EUDAMED step by step
canonical_url: https://zechmeister-solutions.com/en/blog/device-registration-eudamed-step-by-step
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Device Registration in EUDAMED: Step-by-Step for Startups

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Registering a device in EUDAMED under MDR Article 29 is a sequence of specific steps that must be completed before the device is placed on the EU market. The manufacturer must already hold a Single Registration Number issued under MDR Article 31. It must then assign a Basic UDI-DI to the device in accordance with MDR Article 2(15) and the rules of a Commission-designated UDI issuing entity, generate the applicable UDI-DIs for each packaging level, submit the Basic UDI-DI together with the data elements specified in Annex VI Part B to the UDI database in EUDAMED, attach the Notified Body certificate reference where the conformity assessment involves a Notified Body, validate the submission, and keep the record up to date across the life of the device. The detailed functioning of the EUDAMED modules, including device registration, is governed by Commission Implementing Regulation (EU) 2021/2078.**

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

---

## TL;DR

- Device registration in EUDAMED is a manufacturer obligation under MDR Article 29(1). It has to happen before the device is placed on the EU market.
- The sequence is: SRN first, Basic UDI-DI assignment second, UDI-DI generation third, EUDAMED data entry fourth, Notified Body certificate reference fifth, validation sixth, maintenance seventh.
- The data elements submitted to the UDI database are specified in MDR Annex VI Part B. They cover the regulatory identity of the device, not production-level data.
- The UDI-PI (lot, serial, software version, manufacturing date, expiry) is not submitted as a database entry; it lives on the physical unit under Annex VI Part C.
- The mandatory use of the EUDAMED UDI/device registration module is governed by MDR Article 34 and activated by Commission functional declarations. Check the current status on the Commission's EUDAMED information page before filing.

---

## A founder who skipped straight to step four

A founder wrote to us last year to say EUDAMED had rejected their device submission. The rejection reason was not informative. They had tried to enter a Basic UDI-DI, been told the SRN field was invalid, assumed the form was broken, and escalated to their Notified Body, who in turn asked us what was going on. The answer took five minutes to find. The company had never completed actor registration. They did not have an SRN. They had gone straight to step four of a seven-step sequence, skipped the first three, and then been surprised when the form complained.

This is the post we should have written the week before that email arrived. It is the step-by-step walkthrough of device registration in EUDAMED for a small manufacturer, written so that a founder can read it once and know the full sequence before they open a single form. The pillar for this whole cluster is [What is EUDAMED?](/blog/what-is-eudamed-european-database-medical-devices). The status context is in [EUDAMED status in 2026](/blog/eudamed-status-2026). This post is the operational walkthrough that sits between them.

## Before you start — the prerequisites

Before any of the seven steps below makes sense, three things have to already be true.

First, your device must have a stable intended purpose and a confirmed risk classification under MDR Article 51 and Annex VIII. If the classification is still moving, the Basic UDI-DI grouping cannot be finalised, and the EUDAMED entry will not be consistent with the technical documentation.

Second, your manufacturer role under MDR Article 10 has to be clear. You are the legal entity placing the device on the market. If you are established outside the Union, the obligations of Article 31(3) sit with your authorised representative, and that relationship has to be formalised before anything else happens.

Third, you must have chosen a UDI issuing entity designated by the European Commission — currently GS1, HIBCC, ICCBBA, or IFA — and be in a position to allocate identifiers under that entity's rules. See [what is a UDI](/blog/what-is-udi) and [MDR Articles 27-29 UDI requirements](/blog/mdr-articles-27-29-udi-requirements) for the background.

With those prerequisites in place, the seven-step sequence below is what device registration actually looks like.

## Step 1 — Obtain your Single Registration Number (SRN)

The first step is not device registration at all. It is actor registration. MDR Article 31(1) requires manufacturers, authorised representatives, and importers to submit to EUDAMED the information referred to in Annex VI Part A, Section 1, before placing a device on the market. Once the Competent Authority of the Member State where the economic operator is established verifies the data, EUDAMED issues the Single Registration Number.

The SRN is the identifier that every subsequent EUDAMED action attaches to. You cannot register a device without an SRN, because every device record in the UDI database is linked to the manufacturer's SRN as the legal owner of that record. Importers and distributors who handle the device downstream will reference the same SRN in their own registrations. The SRN is not cosmetic — it is the key that ties the entire EUDAMED graph together.

For the walkthrough of actor registration itself, see [how to register your startup as a manufacturer in EUDAMED](/blog/register-startup-manufacturer-eudamed) and [what is the Single Registration Number](/blog/single-registration-number-srn). Do not proceed to Step 2 until the SRN is in hand.

## Step 2 — Assign a Basic UDI-DI

The second step is to assign a Basic UDI-DI to the device. MDR Article 2(15) defines the Basic UDI-DI as the primary identifier of a device model and the main access key for information stored in the UDI database. It is not the identifier carried on the label. It is the higher-level grouping identifier that binds together all variants of a device family sharing the same intended purpose, risk class, and essential design and manufacturing characteristics.

Assignment is not automatic and it is not trivial. The decision you make here propagates into the technical documentation, the EU declaration of conformity, the Notified Body certificate, the Summary of Safety and Clinical Performance for Article 32 devices, the clinical evaluation, and every downstream EUDAMED entry. A Basic UDI-DI that groups your devices too broadly forces you to manage regulatory events across unrelated variants. A Basic UDI-DI that splits too narrowly multiplies your administrative burden and your certificate footprint.

The rule of thumb Tibor uses: one Basic UDI-DI per device family as a Notified Body auditor would recognise it. Same intended purpose. Same class. Same essential design. Same manufacturing process. Size variants, colour variants, and packaging variants all sit under the same Basic UDI-DI. Distinct technologies or distinct intended purposes do not.

The Basic UDI-DI itself is assigned under the rules of your chosen issuing entity. For GS1, this is a specific GS1 identifier structure documented in their general specifications. For HIBCC, ICCBBA, and IFA, the equivalent rules apply under each entity's own standards. The format is dictated by the entity, not invented by the manufacturer.

## Step 3 — Generate UDI-DIs for each packaging level

The third step is to generate the UDI-DIs. Under MDR Article 27 and Annex VI Part C, each device and each higher level of packaging carries its own UDI-DI. A single-unit carton and a case of ten cartons each get their own UDI-DI. The UDI-DI is the static part of the UDI that is actually carried on the label.

Two things matter at this step. The first is that the UDI-DI structure must follow the issuing entity's rules — GS1 GTIN, HIBCC LIC-based identifier, ICCBBA ISBT 128, or IFA PZN-based identifier, depending on the entity you chose. The second is that each UDI-DI must link back to the Basic UDI-DI you assigned in Step 2, so that the tree structure (Basic UDI-DI as trunk, UDI-DIs as branches) is preserved in your internal records before it goes into the database.

The UDI-PI — the production identifier that carries the lot number, serial number, software version, manufacturing date, or expiry date — is not generated at this step for the purpose of EUDAMED submission. The UDI-PI is applied at the point of production and lives on the physical unit. Annex VI Part B does not require UDI-PI values to be registered in the database. Only the UDI-DI and Basic UDI-DI go into the database entry; the UDI-PI travels with the device.

## Step 4 — Enter the device in EUDAMED

The fourth step is the actual database entry. MDR Article 29(1) requires the manufacturer, before placing a device (other than custom-made) on the market, to assign a Basic UDI-DI to the device and provide it together with the other core data elements referred to in Annex VI Part B to the UDI database. This is the step that most founders think of as "EUDAMED registration." It is step four, not step one.

The data elements under Annex VI Part B cover the regulatory identity of the device. Without reproducing the Annex, the practical fields a startup will fill include the following categories:

- **Identification:** the Basic UDI-DI, the UDI-DI at the primary packaging level, and any other UDI-DIs at higher packaging levels.
- **Manufacturer data:** the manufacturer's SRN and identification details, linked automatically to the actor record from Step 1.
- **Authorised representative data:** SRN and identification of the authorised representative where the manufacturer is established outside the Union.
- **Risk class:** the classification under MDR Article 51 and Annex VIII.
- **Device description:** name or trade name, device model, device type, and the EMDN nomenclature code used to categorise it.
- **Intended purpose:** as stated in the labelling, IFU, and clinical evaluation.
- **Special device attributes:** whether it is single-use, reusable, sterile, implantable, measuring function, containing medicinal substances, containing substances of concern, and similar regulatory flags.
- **Status:** on the market, no longer placed on the market, recalled, and the corresponding date fields.
- **Links to the IFU:** where electronic instructions for use are provided under (EU) 2021/2226, the relevant URL.
- **Relevant clinical investigation references:** where applicable.

Enter the data through the EUDAMED user interface or, for larger catalogues, through the machine-to-machine interface described in Commission Implementing Regulation (EU) 2021/2078. The implementing regulation sets out the detailed rules for registration, access, nomenclature, data ownership, and security of EUDAMED. Any question about field definitions, format requirements, or error handling is answered by reading (EU) 2021/2078 alongside Article 29 and Annex VI.

## Step 5 — Attach the Notified Body certificate reference

The fifth step applies to every device where conformity assessment involves a Notified Body — which is to say, every device above Class I (with the exception of Class I measuring, sterile, or reusable surgical instruments, which also involve a Notified Body for specific aspects). MDR Article 29(4) requires the Basic UDI-DI to be provided to the Notified Body and to appear on the certificate.

The operational consequence at the EUDAMED entry level is that the device record has to carry the reference to the certificate issued by the Notified Body. The certificate itself flows into the EUDAMED Notified Bodies and certificates module — covered in [the EUDAMED certificates module](/blog/eudamed-certificates-module) — and the device record references that certificate. In practice this means you coordinate with your Notified Body so that their certificate is entered under the same Basic UDI-DI you submitted in Step 4, and the cross-reference is consistent on both sides.

For Class I self-certified devices, this step is not applicable and the declaration of conformity is the document of record instead. For every other class, a mismatch between the Basic UDI-DI on the certificate and the Basic UDI-DI in the device record is a finding waiting to happen in your next audit.

## Step 6 — Validate the submission

The sixth step is validation. Before marking the record as complete, walk through a short internal review.

Confirm that the Basic UDI-DI on the EUDAMED record matches the Basic UDI-DI on the declaration of conformity, the technical documentation file cover, the Notified Body certificate (where applicable), the Summary of Safety and Clinical Performance (for Article 32 devices), and the clinical evaluation report. Confirm that the risk class in the EUDAMED record matches the class in the technical documentation and on the certificate. Confirm that the intended purpose field is consistent word-for-word with the labelling and IFU. Confirm that the manufacturer SRN and, where applicable, the authorised representative SRN are the correct current values. Confirm that the EMDN code accurately reflects the device type.

Validation is not bureaucratic overhead. It is the last opportunity to catch inconsistencies before the record becomes public and auditable. A device record that contradicts the technical file is a problem you will have to explain, and the explanation will itself become part of the audit trail.

## Step 7 — Maintain the record

The seventh step is not a one-time action but an ongoing obligation. MDR Article 29(2) requires the manufacturer to keep the information in the UDI database up to date. Changes that affect the Basic UDI-DI or the UDI-DI trigger a new identifier under the issuing entity's rules. Changes that do not affect the identifier but do affect other Annex VI Part B fields — a change of authorised representative, a change of IFU URL, a change of status to "recalled" or "no longer placed on the market," a change in risk class following a re-classification — trigger an update to the record.

The practical consequence is that change control in your QMS has to include a EUDAMED maintenance hook. Every change request that affects a field in the Annex VI Part B data set has to flag the EUDAMED update as an action item. Without this hook, your EUDAMED record drifts out of sync with reality, and the drift itself becomes visible as a discrepancy between public registry data and your technical file.

## The Subtract to Ship angle on device registration

Device registration in EUDAMED is a finite workstream. The temptation, particularly in a startup with a fast-growing catalogue, is to build parallel tooling — an internal "EUDAMED mirror" in a spreadsheet or a homegrown database — and then wire elaborate synchronisation processes between the mirror and EUDAMED. Most of that is waste.

The real work is the seven steps above, done cleanly, with the data master stored once in a place your change control process already touches. A single source of truth for Basic UDI-DI, UDI-DI, Annex VI Part B data, and certificate references — typically inside the QMS — feeds EUDAMED directly and feeds the technical documentation in parallel. Every additional copy of this data creates an additional place for it to drift. Cut the copies. For the underlying methodology see [the Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr).

## Reality Check — Where do you stand on device registration?

1. Do you hold a valid SRN issued under MDR Article 31 for the legal entity that will be named as manufacturer?
2. Have you assigned a Basic UDI-DI per device family, and can you defend the grouping by reference to intended purpose, class, and essential design?
3. Have you generated UDI-DIs at every packaging level you will place on the market, under the rules of your chosen issuing entity?
4. Do you have the Annex VI Part B data elements assembled in one place, consistent with the technical documentation and the labelling?
5. For any device above Class I, does your coordination with the Notified Body ensure that the certificate will reference the same Basic UDI-DI you submit in Step 4?
6. Does your QMS change control explicitly trigger a EUDAMED maintenance action when an Annex VI Part B field changes?
7. Have you checked the current mandatory/voluntary status of the UDI/device registration module on the Commission's EUDAMED information page before filing?

If you cannot answer five or more of these cleanly, the device registration workstream is not yet ready to run end-to-end.

## Frequently Asked Questions

**Do I need an SRN before I can register a device in EUDAMED?**
Yes. The SRN is issued under MDR Article 31 as part of actor registration and is the identifier every device record in EUDAMED links back to. You cannot submit a device record without one.

**What data fields does Annex VI Part B require for device registration?**
Annex VI Part B specifies the data elements submitted to the UDI database, including the Basic UDI-DI, UDI-DI at each packaging level, manufacturer SRN, authorised representative data where applicable, risk class, device description, intended purpose, special attributes such as sterility or implantability, status, and links to electronic IFU where applicable. The full list and the field definitions are in the Regulation text and operationalised in Commission Implementing Regulation (EU) 2021/2078.

**Is the UDI-PI submitted to EUDAMED as part of device registration?**
No. The UDI-PI — lot number, serial number, software version, manufacturing date, or expiry date — lives on the physical unit under Annex VI Part C and is not registered as a database entry in the UDI database. Only the Basic UDI-DI and UDI-DI, together with the Annex VI Part B fields, are submitted to the database.

**Who enters the Notified Body certificate reference into EUDAMED?**
The Notified Body enters the certificate data into the Notified Bodies and certificates module of EUDAMED. The manufacturer ensures that the Basic UDI-DI used in the device record matches the Basic UDI-DI that appears on the certificate, so that the two records reference each other consistently.

**When exactly must device registration be completed?**
MDR Article 29(1) requires the information to be submitted before the device is placed on the market. Placing on the market is defined in MDR Article 2(28) as the first making available of a device on the Union market. In practice this means the EUDAMED record must be complete and validated before the first unit is made available to an end user or distributor in the EU.

**What if the UDI/device registration module is not yet mandatory under Article 34?**
Even when voluntary, entering the data early is sensible because it creates a clean record that carries over when the module becomes mandatory. Voluntary use does not replace any parallel national registration obligation that applies to you. See [EUDAMED status in 2026](/blog/eudamed-status-2026) for how to read the current status.

**How do I keep the EUDAMED record up to date?**
Wire a EUDAMED maintenance action into your QMS change control process. Every change request that affects an Annex VI Part B field — authorised representative, IFU URL, status, and so on — should trigger a EUDAMED update as a required step. MDR Article 29(2) places the up-to-date obligation squarely on the manufacturer.

## Related reading

- [What is EUDAMED? The European Database on Medical Devices explained for startups](/blog/what-is-eudamed-european-database-medical-devices) — the pillar post for the whole cluster.
- [EUDAMED status in 2026](/blog/eudamed-status-2026) — the living document on which modules are currently mandatory versus voluntary.
- [How to register your startup as a manufacturer in EUDAMED](/blog/register-startup-manufacturer-eudamed) — the actor registration walkthrough behind Step 1.
- [What is the Single Registration Number (SRN)?](/blog/single-registration-number-srn) — the identifier at the heart of Step 1.
- [What is a UDI?](/blog/what-is-udi) — the unique device identifier concept this whole process depends on.
- [MDR Articles 27-29 UDI requirements](/blog/mdr-articles-27-29-udi-requirements) — the legal obligations behind Steps 2 through 4.
- [How to assign a Basic UDI-DI](/blog/how-to-assign-basic-udi-di) — the operational detail behind Step 2.
- [UDI carriers: barcodes, DataMatrix, and direct marking](/blog/udi-carriers-barcodes-datamatrix) — the Annex VI Part C requirements for how the UDI appears on the physical device.
- [EUDAMED and UDI compliance checklist](/blog/eudamed-udi-compliance-checklist) — the consolidated readiness list for the whole cluster.
- [The EUDAMED certificates module](/blog/eudamed-certificates-module) — how Notified Body certificates flow into EUDAMED and connect to Step 5.
- [The Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr) — the methodology behind cutting the registration workstream down to what Articles 27-29 and Annex VI require.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(15) (Basic UDI-DI), Article 27 (UDI system), Article 28 (UDI database), Article 29 (registration of devices), Article 31 (registration of manufacturers, authorised representatives and importers), Article 33 (European database on medical devices — Eudamed), Article 34 (functioning of Eudamed), Annex VI Part A (information to be submitted for registration of economic operators), Annex VI Part B (core data elements to be provided to the UDI database), Annex VI Part C (the UDI system). 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, machine-to-machine interface documentation, and Commission notices on functional declarations under Article 34. Readers should consult this page directly on the day they file, because the live status of the UDI/device registration module is set by Commission notices and can change between audits and declarations.

---

*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. The pillar for this cluster is [What is EUDAMED?](/blog/what-is-eudamed-european-database-medical-devices). For the current mandatory status of the UDI/device registration module, read this post alongside [EUDAMED status in 2026](/blog/eudamed-status-2026), which is maintained as a living document and supersedes any time-sensitive statement here.*

---

*This post is part of the [EUDAMED, UDI & Registration](https://zechmeister-solutions.com/en/blog/category/eudamed-udi) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*