UDI Labeling Requirements: What Medical Device Manufacturers Need on Every Label

Unique Device Identification is one of the most operationally significant changes EU MDR introduced for medical device manufacturers — and one of the most consistently misunderstood. Unlike labeling requirements that primarily affect content, what the label says, UDI affects every packaging level a device passes through, requires registration in a central EU database, and depends on a specific kind of consistency that most artwork review processes weren't built to check.

An error in the UDI carrier — a transposed digit, a mismatched device identifier between the unit and the case, a barcode that doesn't decode correctly — isn't a cosmetic labeling issue. It's a traceability failure, with direct implications for how a device is tracked through the supply chain and how quickly a field safety corrective action can reach the right units if one is ever needed.

This guide goes deeper into UDI specifically than a general device labeling overview can — covering what UDI actually requires under EU MDR and the FDA system, where the consistency requirement most often breaks down in practice, what EUDAMED registration involves, and how to verify a UDI carrier is genuinely correct, not just present.

Scope note: for the broader set of device labeling requirements — IFU, symbols, language — see the Medical Device Labeling Requirements guide. This guide focuses specifically on UDI.

What UDI Is — and Why It Matters

Unique Device Identification is a system of standardized, unique codes assigned to medical devices, designed to allow a specific device to be traced from manufacturer through the supply chain to the point of use. It exists to serve three practical purposes: enabling rapid, precise identification during a field safety corrective action or recall; supporting post-market surveillance by giving regulators and manufacturers a consistent way to track device performance data back to specific units; and reducing the risk of counterfeit or diverted devices entering the supply chain undetected.

A UDI has two components. The Device Identifier (UDI-DI) identifies the specific device model, its labeler, and its packaging configuration — it is, in effect, a fixed identifier for "this exact product, packaged this exact way." The UDI-DI changes whenever any of those elements change: a new pack size, a different labeler, a revised device version. The Production Identifier (UDI-PI) identifies the specific production unit — typically a lot or batch number, a serial number, a manufacturing date, and an expiry date where applicable to the device type. Where the UDI-DI answers "what is this," the UDI-PI answers "which specific one is this."

Both components together are what gets registered in EUDAMED, the EU's central database for medical device information, which is where UDI's regulatory purpose and its labeling requirements meet directly.

EU MDR UDI Requirements

The UDI obligation under EU MDR is set out in Articles 27, 28, and 29, and Annex VI Part C of Regulation (EU) 2017/745. Four requirements matter most for a labeling and artwork team:

UDI must appear at every packaging level. The device or its sterile barrier system (where applicable), the unit sales packaging, and every higher level of packaging — intermediate cartons, shipping cases — must each carry a UDI carrier. This isn't one code repeated at every level; each packaging level's UDI-DI reflects that specific packaging configuration.

The UDI carrier has two required forms. A machine-readable Automatic Identification and Data Capture (AIDC) representation — typically a linear barcode or a DataMatrix 2D symbol — and a Human Readable Interpretation (HRI), the same data presented as plain text alongside the symbol. Both are required; neither substitutes for the other.

The AIDC format depends on device class. Implantable devices and Class III devices must use DataMatrix. Other device classes may use either DataMatrix or a linear barcode, depending on manufacturer choice and label space constraints.

Every packaging level must be registered in EUDAMED, and the UDI module became mandatory on May 28, 2026. For devices newly placed on the EU market, UDI-DI registration in EUDAMED is now a live requirement, not an upcoming one. Devices that were already on the market before that date, and continue to be marketed, have until November 27, 2026 to complete registration, per the transitional provisions in Regulation (EU) 2024/1860.

FDA UDI Requirements (21 CFR Subpart B)

FDA's UDI system runs in parallel to EU MDR, with meaningful overlap but not full equivalence. Under 21 CFR Part 801, Subpart B, most devices must bear a UDI on their label and on each package, in both AIDC and HRI form. Class III devices and certain implantable Class II devices additionally require the UDI-PI to appear directly on the device label, not just on the packaging.

Device UDI-DIs must be submitted to FDA's Global Unique Device Identification Database (GUDID). The issuing agency assigning the UDI-DI must be FDA-accredited — GS1, HIBCC, or ICCBBA for blood-related products are the accredited agencies.

For a manufacturer selling into both the US and EU markets, the practical approach is usually to obtain a UDI-DI from a GS1-accredited issuing agency, since GS1 is recognized by both FDA and the EU system — meaning a single underlying identifier framework can typically satisfy both regulatory regimes, even though the registration destinations (GUDID versus EUDAMED) and some specific data fields differ.

UDI on Each Packaging Level — Where Consistency Breaks Down

This is the single most common source of UDI non-conformities, and it's worth treating as its own topic rather than a footnote to the general UDI requirement.

Because each packaging level's UDI-DI reflects that level's specific configuration, a device passing through unit, intermediate, and case packaging has, correctly, three related but distinct UDI-DIs — not one identifier copied three times. The requirement isn't that all three levels show the same code; it's that each level's UDI-DI is correct for that level, and that the relationship between levels (which unit-level UDI-DIs are packed under which case-level UDI-DI) is accurately reflected and registered.

The failure pattern that generates the most non-conformities is this: a label revision changes something about the unit-level packaging — a new catalogue reference, an updated pack configuration — and the unit-level UDI-DI is correctly updated to reflect it. But the intermediate and case-level artwork, produced separately or reviewed on a different cycle, isn't updated in the same pass. The result is a case label that still references the previous unit configuration, even though every individual label, reviewed on its own, looks correct.

A second, more subtle version of the same problem: the HRI (the human-readable text) is updated to reflect a change, but the AIDC symbol — the actual barcode or DataMatrix — still encodes the previous value, because the two elements were generated from different source data or updated in different steps of the artwork process. Visually, the label looks right. The code underneath doesn't match what's printed next to it.

Neither of these failure patterns is visible to a reviewer looking at any single packaging level in isolation. They only surface when every level, and both the AIDC and HRI representations at each level, are compared systematically against the approved specification and against each other.

EUDAMED — Registration and Deadlines

EUDAMED is the European Commission's central database for medical device information, and the UDI/Device registration module is the specific part of it relevant to labeling teams. As of May 28, 2026, this module is mandatory: new devices must be registered — UDI-DI, device description, risk classification, relevant certificate numbers — before being placed on the EU market for the first time.

For devices already on the market before that date, and continuing to be sold, the registration deadline is November 27, 2026 — twelve months from the date the relevant amending regulation was published in the Official Journal. This is a hard compliance date for a substantial number of currently marketed devices, not just new product launches, and it's worth treating as a live project deadline if legacy device registration hasn't already been completed.

EUDAMED registration and label content need to stay synchronized: if a device's UDI-DI is updated, both the label artwork and the EUDAMED record need to reflect the change, and a discrepancy between what EUDAMED has on file and what's actually printed on the device is itself a compliance gap, independent of whether the label alone looks correct.

Barcode and DataMatrix Verification — What "Correct" Actually Means

A UDI carrier being present on a label is not the same as a UDI carrier being correct. Three separate things need to be true:

The encoded data is accurate. The AIDC symbol needs to encode exactly the right UDI-DI and UDI-PI for that specific packaging configuration — not a previous version, not a value copied from a similar but different product.

The symbol is physically readable to standard. A barcode or DataMatrix that technically scans under ideal conditions may still fail grading standards that predict reliable performance across real-world scanning conditions — different lighting, different scanner hardware, different print quality. ISO/IEC 15415 governs 2D symbol quality grading; ISO/IEC 15416 governs linear barcode grading. A UDI carrier should be graded against the applicable standard, not simply confirmed to scan once under test conditions.

The AIDC and HRI match exactly. The data encoded in the barcode or DataMatrix needs to correspond precisely to the human-readable text printed alongside it. A mismatch between the two — however it originates — is a labeling non-conformity even if each element, checked separately, appears individually valid.

For manufacturers using GS1 as their issuing agency, UDI data is typically structured using GS1 Application Identifiers — standardized codes within the barcode data that identify which piece of information is which (GTIN, lot number, expiry date, and so on). A genuine verification step needs to decode this AI structure and confirm each individual data element is correct — not simply confirm that a scanner can read the barcode without error.

Common UDI Labeling Errors — and Where in the Process They Originate

Drawing on documented notified body findings and FDA enforcement patterns, the recurring UDI error categories are:

Packaging-level inconsistency — described in detail above, and the most frequent source of non-conformities.

DataMatrix or barcode encoding errors — introduced during artwork production, where the specification for what the code should encode and what actually gets encoded in the final file diverge, often due to a manual data entry step somewhere in the artwork pipeline.

GTIN or identifier transposition errors — a digit swapped or mistyped when the UDI-DI is entered into artwork software, producing a code that's internally valid in format but incorrect in content.

HRI and AIDC mismatch — covered above, where the printed text and the encoded symbol diverge due to being generated or updated through different processes.

EUDAMED registration drift — where a label change is implemented in artwork and print, but the corresponding EUDAMED record isn't updated to match, or vice versa.

These categories are consistent with the broader pattern in FDA Class I and II device recalls, where labeling and identification errors remain a persistent, largely preventable contributor. None of them require a lapse in regulatory knowledge to occur — they require a verification step systematic enough to catch a discrepancy that isn't visible in a normal visual review.

UDI compliance is verifiable before a device ships — the requirement is specific enough, and the failure patterns predictable enough, that a systematic check catches nearly all of it. What it requires is comparing every packaging level's UDI carrier, both its encoded data and its human-readable text, against the approved specification, in the same pass as the rest of the label's content.

Content Compare's Braille & Barcode module decodes UDI carriers, verifies the encoded data against the approved specification, and grades the barcode or DataMatrix to ISO/IEC standard — in the same session as text and graphic verification for the same label.

↗ See UDI verification across every packaging level on your own device labels. Compare it against what to look for in any artwork verification platform, or request a demo at informait.com.