The Three Submission Methods
MDR Article 29requires manufacturers to enter device registration data into EUDAMED before placing most devices on the market. The regulation sets the obligation; it says nothing about how the data gets typed, uploaded, or transmitted. That is a separate, purely technical choice, and EUDAMED's own Information Centre documents exactly three ways to make it: the EUDAMED user interface, XML bulk upload/download through that same interface, and machine-to-machine (M2M) data exchange between an external system and EUDAMED directly.
All three methods validate the same underlying data against the same DTX schema and the same published business rules. None of them is more or less "official" than the others; the difference is entirely in how much manual effort and technical infrastructure each one takes, and at what portfolio size that tradeoff starts to make sense.
Choosing by Portfolio Size
The EUDAMED Information Centre's page on modes of data input gives a direct, numeric recommendation rather than leaving manufacturers to guess:
| Devices to Register | Recommended Method |
|---|---|
| Up to 100 | EUDAMED user interface |
| 100 to 1,000 | XML bulk upload/download |
| More than 1,000 | M2M data exchange |
This is a starting point, not a rule EUDAMED enforces. Nothing stops a manufacturer with 60 devices from building an M2M connection, or a manufacturer with 2,000 devices from working through bulk XML files instead. The Commission's own guidance frames the thresholds as a practical tip for where manual effort typically stops being worth the time, not a technical restriction on which method a given portfolio size is allowed to use.
The User Interface
The EUDAMED user interface is the simplest of the three from a data-handling standpoint: a PC with an internet connection and a browser is the entire requirement. Every field is entered by hand, one device record at a time, directly into the EUDAMED web application.
There is no XML to generate, no schema to validate against beforehand, and no infrastructure to install. The cost is entirely in labor: for a handful of devices this is faster than building anything else, and for a large legacy portfolio it becomes the slowest of the three methods by a wide margin.
XML Bulk Upload
XML bulk upload sits between the two extremes. The manufacturer still uses the EUDAMED user interface to perform the upload or download, but the data itself is prepared in advance as an XML file, validated against the EUDAMED DTX service and entity model XSDs, and then submitted in one action covering many device records at once rather than one form submission per device.
The EUDAMED Information Centre's guidance is explicit that this file should be produced automatically rather than typed by hand: manually assembled XML is far more likely to trip a validation error on upload, given the complexity of the schema and business rules involved (field sizes, tag positions, and mandatory-versus-optional fields among them). Bulk download works the same way in reverse: EUDAMED returns data in the same XML format, which is accurate but not easy to read without separate software to render it.
Because bulk upload still validates against the full EUDAMED business-rule set, including the field-level and EMDN-code-lifecycle rules covered in the guide to why registrations get rejected, an XML file that looks well-formed can still fail if the underlying EMDN classification or a conditional field combination is wrong. Bulk upload changes how much data moves per submission; it does not change what EUDAMED will accept.
M2M Data Exchange
M2M is the fully automated option: data moves between a manufacturer's own backend system and EUDAMED's backend with no manual upload step at all. Setting it up requires more than an XML file. According to the EUDAMED Information Centre's architecture documentation, an organisation connecting via M2M needs:
- An external system capable of converting its own data into the XML format EUDAMED's DTX schema requires.
- A CEF eDelivery Access Point, installed and configured on the organisation's own infrastructure, using the AS4 messaging protocol. Organisations can choose any AS4 eDelivery-conformant product or service. On EUDAMED's side, the corresponding Access Point runs on Domibus.
- An Organisation Backend, the gateway that implements the specific communication protocol and data exchange service compliant with EUDAMED's own service and data model.
That Access Point is not a one-time setup cost. It runs on hardware the organisation maintains itself, with ongoing responsibility for support, version updates, and configuration.
When M2M Is Actually Worth It
The EUDAMED Information Centre is direct about M2M being the most complex and costly of the three methods, and it lists the conditions under which that cost is worth paying rather than treating a large device count alone as sufficient justification:
- The organisation already maintains a database for this data outside EUDAMED.
- The volume of data to upload or download is too large to enter or extract manually without becoming burdensome and slow.
- Exchanges with EUDAMED will happen frequently, not as a one-off migration.
- The cost of manual data entry outweighs the cost of building and running the automation.
- The organisation has the available resources, competence, and infrastructure to implement and maintain the connection.
A manufacturer clearing a one-time legacy backlog of 1,500 devices ahead of the November 2026 deadline, with no ongoing need to exchange data with EUDAMED afterward, may find bulk XML uploads done in a few batches cheaper overall than standing up and maintaining an M2M connection for what is, in practice, a single event. M2M earns its cost when the exchange is recurring, not when it is large but one-off.
Primary Sources
The thresholds, requirements, and cost-benefit criteria above are taken directly from the European Commission's EUDAMED Information Centre, the same documentation source EUDAMED itself links to for data-exchange guidance.
| Page | Covers |
|---|---|
| Modes of data input | The three submission methods and the 100 / 1,000-device portfolio-size guidance |
| Requirements for the different modes of data input | Technical requirements for each method and the DTX change-notice periods |
| M2M data exchange architecture | The Access Point, AS4 protocol, and Domibus/eDelivery connection requirements |
| Bulk uploading-downloading | What the bulk upload/download function covers inside the EUDAMED user interface |
All four pages carry a EUDAMED Information Centre version footer of v2.27.0, publication date July 24, 2026, at the time this guide was written.
The method a manufacturer chooses does not change what EUDAMED will accept, only how much manual work and infrastructure it takes to get there. A well-formed XML file still fails if the device data underneath it is wrong. Getting the data right before choosing a submission method, rather than after the first rejected upload, is what makes any of the three methods fast instead of a source of repeated resubmissions.
Frequently Asked Questions
How many devices before I should switch from the EUDAMED user interface to bulk upload?
The EUDAMED Information Centre's own guidance puts the line at 100 devices: register up to 100 through the user interface, and use bulk upload/download once you have 100 to 1,000 devices to register. Above 1,000, the same guidance points to M2M data exchange instead.
What is the difference between XML bulk upload and M2M?
Both move data in and out of EUDAMED as XML validated against the same DTX schema and business rules. Bulk upload is semi-automated: you generate the XML file, then upload or download it manually through the EUDAMED user interface. M2M is fully automated: your own system exchanges XML with EUDAMED directly over a dedicated connection, with no manual upload step and no person clicking a button.
What does a manufacturer need to set up before using M2M?
An external system that can generate and consume EUDAMED's XML format, plus a CEF eDelivery Access Point installed and configured on the manufacturer's own infrastructure, using the AS4 messaging protocol. EUDAMED's own side of that connection runs on Domibus. The Access Point needs installation, configuration, and ongoing maintenance, including support and version updates.
Does the EUDAMED XML format change without notice?
No, but the notice period is short once EUDAMED is fully functional: the Commission gives roughly six months' notice before a DTX or validation-rule change, and both the old and new XSD versions work during that window. During EUDAMED's development phase, before a module is fully functional, DTX changes are communicated four to six weeks before a new release instead.
Is M2M always the right choice for a large device portfolio?
Not automatically. The EUDAMED Information Centre frames M2M as the most complex and costly of the three methods, worth the investment only when several conditions hold together: an external database already exists outside EUDAMED, the data volume is too large to enter or extract by hand, exchanges will be frequent, the cost of manual entry outweighs the cost of automation, and the manufacturer has the infrastructure and competence to build and maintain the connection.