EUDAMED Goes Mandatory: Wiring UDI and Device Registration Into Your Product Data, Not a Portal

EUDAMED stops being optional for the four core modules on 28 May 2026, and the manufacturers who treat it as a web form to be typed will spend the next decade reconciling a portal against a product catalogue that has already moved on.

The European database on medical devices has existed in a half-live state for years: available since October 2021, populated voluntarily by the diligent, ignored by everyone else because nothing turned on it. That ends. Under the gradual roll-out mechanism introduced by Regulation (EU) 2024/1860, the Commission can declare modules functional one at a time and start a mandatory-use clock. It has now done so. The practical question for a device manufacturer is no longer whether to register in EUDAMED. It is whether registration is something a regulatory-affairs colleague does by hand, screen by screen, or something your systems do because the data already lives there.

What actually becomes mandatory, and when

Following Decision (EU) 2025/2371 and the notice published in the Official Journal in November 2025, four of the six EUDAMED modules become mandatory on 28 May 2026: Actor registration, UDI/Device registration, Notified Bodies and Certificates, and Market Surveillance. The remaining two — Vigilance and post-market surveillance, and Clinical Investigations and Performance Studies — are not yet in the mandatory set; they follow once the Commission declares them functional on the same module-by-module basis. Do not assume a single switch flips everything.

Two dates matter most for the UDI/Device module. New devices placed on the EU market from 28 May 2026 must be registered before the first unit is placed on the market. Devices already on the market before that date, and still being made available, get a grace window: they must be registered by 28 November 2026. That six-month tail is the only breathing room you get for a legacy catalogue, and it is not much time to reconcile every SKU you have ever shipped. This applies across both the MDR and the IVDR; the timeline does not distinguish between them.

The portal is the wrong mental model

EUDAMED presents as a website, so the instinct is to staff it as one: give someone a login and a spreadsheet, and have them key devices in. For a firm with a dozen products, that survives. For a real catalogue — hundreds or thousands of variants, each with its own UDI-DI, packaging levels, reference numbers and market status — manual entry is a defect generator. Every value typed by hand is a value that can drift from the source of truth in your PLM or ERP system. The database and the product then disagree, and the disagreement is invisible until a competent authority or a notified body finds it.

This is the same category of problem I have written about for structured data behind the ESAP portal: the portal is not the system, it is a projection of your data. The engineering work is upstream, in the master data and the mapping, not in the user interface. Treat EUDAMED as an integration target with a schema, not a form with fields, and the whole shape of the problem changes.

What the UDI/Device record actually contains

The UDI system has three layers, and conflating them is the most common data-modelling error. The Basic UDI-DI is the regulatory grouping key — the primary identifier for a family of devices with the same intended purpose, risk class and design; it links your device to certificates and declarations but never appears on the label. The UDI-DI is the specific device-and-packaging identifier issued by a designated entity — GS1, HIBCC, ICCBBA or IFA GmbH. The UDI-PI is the production identifier — lot, serial number, manufacturing or expiry date, software version — which EUDAMED describes by type rather than storing every value. On top of that sits the EMDN nomenclature code, the European Medical Device Nomenclature term that classifies what the device is.

A registration payload built from your product master data, rather than typed, looks like this:

{
  "basicUdiDi": "5710000110123AB",
  "basicUdiDiIssuingEntity": "GS1",
  "regulation": "MDR",
  "riskClass": "IIa",
  "udiDi": {
    "code": "05710000110130",
    "issuingEntity": "GS1",
    "referenceCatalogueNumber": "AC-2210-14",
    "secondaryUdiDi": null
  },
  "emdnCode": "A020101",
  "tradeName": {"text": "AcuGuard Infusion Set", "language": "en"},
  "udiPiTypes": ["LOT_NUMBER", "EXPIRY_DATE"],
  "quantityPerPackage": 1,
  "unitOfUseDi": null,
  "directMarking": false,
  "sterile": true,
  "sterilisationBeforeUse": false,
  "containsMedicinalSubstance": false,
  "latex": false,
  "marketStatus": "ON_THE_MARKET",
  "placedOnMarketDate": "2026-06-01"
}

Nothing in that record should be authored for EUDAMED. Every field has a home already — in your PLM, your labelling system, your regulatory dossier. The job is to map each field to its source, generate the payload, and submit it through the machine-to-machine route rather than the screen. Where a value has no reliable source, you have found a master-data gap, not a data-entry task, and the fix belongs upstream.

Staying in sync is the harder half

Getting the first submission right is the easy part. The database has to track the product over its life. A change of packaging, a new sterile variant, a device withdrawn from a market, a labelling correction — each is an event that must flow to EUDAMED, and some of them create a new UDI-DI rather than editing an old one. Certain attributes are, by design, not editable once set; they force a new identifier. If your only sync mechanism is a person remembering to log in after a change-control board meeting, you will fall out of alignment within a quarter.

The durable pattern is to hang EUDAMED updates off the same change events that already govern your product data, so a change to a device record proposes the corresponding EUDAMED action automatically. That is a lineage problem — knowing which downstream registrations a product change touches — and it is the same discipline that makes a platform like California’s DROP deletion registry tractable when you wire systems to it rather than servicing it by hand. Clean identifiers and a defensible mapping are also what let you use this data for anything else later; the same argument I have made about data classification as a prerequisite, not a parallel workstream applies to device master data.

Who owns this, and why it is not just regulatory affairs

The reflex is to file EUDAMED under regulatory affairs and move on. That is how you end up with a portal maintained in parallel to your real systems by people without the access to fix the source. The registration content is regulatory; the plumbing is engineering. Someone has to own the mapping from product master data to the EUDAMED schema, the submission mechanism, and the change-event triggers — and that someone sits between IT, quality and regulatory. If you are a device maker, you are already juggling overlapping obligations where you are both a regulated entity and a regulated product; EUDAMED is one more system that rewards treating product data as a governed asset rather than a byproduct.

The manufacturers who come out of 28 May 2026 well will not be the ones who typed fastest. They will be the ones who decided, before the deadline, that their catalogue is the source of truth and EUDAMED is a downstream consumer of it — and built the feed accordingly.