As EUDAMED entered its mandatory phase, two key deadlines are now in focus. From 28 May 2026, all new medical devices and in vitro diagnostic medical devices entering the EU market must be registered in EUDAMED before being placed on the market. For devices already marketed, the deadline is 28 November 2026, by which point all devices covered by the EU MD and IVD legislation must have their records in the system.
What is becoming clear across the industry is that not only the submission itself can be the tricky part. The work behind it – gathering, reconciling, structuring, and validating the underlying data – is consistently more complex and time-consuming than expected. This blog breaks down the most common pitfalls teams encounter and what can be done to get ahead of them.
Your data might not be where you think it is
One of the first surprises some manufacturers run into is that the information EUDAMED needs doesn't live in one place. Device identifiers may sit in an ERP system, labelling details in a PLM, and key regulatory information tucked away in technical documentation and declarations of conformity. When these sources are brought together, inconsistencies tend to surface: product descriptions that don't match labels, EMDN codes that have been modified or obsoleted, UDI-DI allocations that haven't kept pace with regulatory changes.
EMDN codes are worth a closer look on their own, as they're a frequent source of confusion. EMDN (European Medical Device Nomenclature) has replaced GMDN as the nomenclature system, and the two shouldn't be treated as interchangeable; a code that was assigned under a GMDN-based classification doesn't carry over directly. Within EUDAMED, the EMDN code entered for a device must sit at the lowest level of the nomenclature hierarchy, broader codes aren't accepted. In addition, EMDN isn't static; codes are periodically added, amended, or obsoleted through publications made available by the European Commission. It's worth checking device records against the latest EMDN updates before finalising a submission, as a code that was correct at the time of initial classification may since have changed.
These inconsistencies are not just administrative inconveniences. EUDAMED requires exact alignment between submitted data, physical device labels, Instructions for Use, and the Declaration of Conformity. Discrepancies need to be resolved before a compliant submission can be made. That reconciliation process takes time, often much more than anticipated.
The practical implication: don't treat data gathering as a quick pre-submission task. Build in time for a structured data review across all sources early in the process.
Manual submissions and the compounding risk of errors
EUDAMED allows manual, record-by-record data entry, which may be workable for very small portfolios. But it comes with two fundamental limitations that become increasingly painful as portfolio size grows.
The first is time. Manual entry requires navigating EUDAMED's interface field by field, for every device. With 100+ data attributes that need to be considered per device record, this is not a quick task, it is a significant time commitment that competes directly with the rest of a regulatory team's workload. For manufacturers with even a moderately sized portfolio, the hours add up fast.
The second is error risk. Manual entry means working through large volumes of structured data, attribute by attribute. Even with the best processes in place, the conditions are simply not ideal for maintaining perfect accuracy throughout. Copy-paste slips, a value entered in a neighbouring field, a transposed number... these are not signs of carelessness but a feature of repetitive, high-volume data work. Unlike systematic errors that tend to be consistent and therefore easier to spot, these scattered inconsistencies are hard to catch in review and time-consuming to correct, since each fix requires going back into individual records. It adds yet more time to a process that was already slow.
Bulk uploads: where technical complexity becomes a bottleneck
There are three routes to submitting data to EUDAMED: manual entry, XML bulk upload, and machine-to-machine (M2M) integration. The M2M option connects directly to EUDAMED via API and is designed for large-scale, automated data flows – but the IT infrastructure required to implement it reliably is substantial. In practice, M2M is the domain of large multinationals with dedicated technical teams and mature data governance systems. For the vast majority of manufacturers, it is beyond both the need and the available resources.
That leaves XML bulk upload as the practical path for any portfolio beyond a handful of devices. However, this is where a different category of errors enters the picture.
Unlike the human slips that characterise manual entry, bulk upload errors tend to be systematic and rule-based. EUDAMED's bulk upload mechanism follows a strict XML Schema Definition (XSD) and enforces an extensive set of business rules on top of it. A file that is well-formed XML will still fail validation if it violates any one of dozens of business rules. These rules govern field combinations, permissible values, conditional requirements, and relationships between data elements.
The types of validation errors that surface most commonly include missed mandatory or conditionally required fields. EUDAMED's data model includes a significant number of fields that become required depending on other inputs, and these conditional requirements are easy to overlook. Interdependent fields present a related challenge: values that seem independently valid may be rejected when evaluated against each other. And check character errors in Basic UDI-DI and UDI-DI codes, while seemingly minor, cause immediate validation failures that require correction at the source.
Each failed upload generates an error report that needs to be interpreted, corrected, and resubmitted. Preparing EUDAMED-compliant XML from source data – typically structured in Excel or other common formats – requires either XML authoring knowledge or a reliable conversion process based on EUDAMED’s XSD. Markup language expertise is rarely found within regulatory affairs teams, and relying on generic file converters produces outputs that fall short of EUDAMED compliance.
Getting this right requires not just a conversion tool, but one that has been specifically built and tested based on EUDAMED's XSD, and that can surface validation errors in a way that is actionable for regulatory teams rather than developers.
Module dependencies: EUDAMED is not linear
A frequently overlooked complexity is that EUDAMED's modules are deeply interdependent. Manufacturers who approach it as a series of independent data entry tasks tend to run into downstream failures.
The most fundamental dependency is the Actor Registration (SRN). Without an active, validated Single Registration Number, nothing else is possible: device registration cannot proceed, Notified Bodies cannot link certificates to the manufacturer's record, and importers cannot identify the manufacturer in the system.
The relationship between the UDI module and the Certificate module is more nuanced than it might appear. Considering that these two modules are associated with different transitional timelines, it is possible that a manufacturer uploads Basic UDI-DI data and a full set of UDI-DI records, and the submission goes through without errors, but the status doesn't move from "Submitted" to "Registered," because the relevant certificate has not yet been uploaded by the Notified Body. Without that certificate in place, the device record remains in a pending state and is not visible in the public database. While this is not a failure of the submission itself ("Submitted" is considered a compliant status), it is not the finish line. The practical answer is straightforward: coordinate actively with your Notified Body on certificate upload timelines rather than assuming the data will be there when you need it. Discovering a dependency gap mid-process is a manageable situation if expected, but a frustrating delay if not.
Legacy devices: the underestimated half of the problem
There is a persistent tendency to frame the EUDAMED challenge primarily around new MDR/IVDR devices. But the 28 November 2026 deadline applies equally to legacy devices – those placed on the market under MDD or IVDD – with one important nuance: a legacy device does not need to be registered if the same regulatory device (shared UDI-DI, catalogue number / trade name, same characteristics) is already registered under the Regulations. In practice, this exception is narrower than it sounds, and most legacy devices will still require dedicated registration.
The impact of this is felt unevenly across the industry. IVD manufacturers tend to fall behind medical device manufacturers in their EUDAMED readiness (a reflection of the longer IVDR transition timelines) and, in some cases, later engagement with the practicalities of the database. Beyond the IVD-specific dimension, legacy device registration carries its own general challenges. Technical files may be less structured, regulatory history may be fragmented across multiple legacy records, and, particularly for manufacturers with long-established portfolios, the volumes can be significant. Planning and resourcing should account for these implications.
Getting to a clean submission
The common thread across all of these challenges is that EUDAMED UDI registration rewards early, structured preparation and penalises last-minute efforts. The teams that navigate it most smoothly tend to share a few characteristics: they started earlier than felt necessary, they invested time in data quality before turning to submission, and they had a clear technical path to data uploads with limited dependency on manual workarounds.
For manufacturers who are still mapping out their approach, the questions worth asking now are: where does your device data actually live, and how clean is it? Do you have a reliable process for converting that data into EUDAMED-compliant format – one that handles the full scope of XSD and business rule validation? And do you have the capacity to manage this alongside the rest of your regulatory workload?
If any of those answers are uncertain, it's worth exploring support options sooner rather than later. At Qserve, we work with manufacturers to take the technical complexity of EUDAMED submissions off the table – handling data structuring, XML generation, validation, and upload – so that regulatory teams can focus on what they know best: the accuracy and completeness of the underlying data.
The deadlines are fixed. The work is significant. But with the right preparation and the right support, a quick and seamless EUDAMED submission is entirely achievable. Get in touch with us to see how we can support you.