---
title: FDA UDI Requirements: GUDID Registration for EU Manufacturers
description: FDA UDI and GUDID for EU manufacturers: how GUDID differs from EUDAMED, dual submission, issuing entities, and the one-label strategy.
authors: Tibor Zechmeister, Felix Lenhard
category: FDA & International Market Access
primary_keyword: FDA UDI GUDID EU manufacturers
canonical_url: https://zechmeister-solutions.com/en/blog/fda-udi-gudid-eu-manufacturers
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# FDA UDI Requirements: GUDID Registration for EU Manufacturers

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

> **FDA UDI requires a UDI on the device label and packaging plus registration of the device identifier in GUDID, the FDA's Global Unique Device Identification Database. For EU manufacturers already compliant with MDR Articles 27-29 and EUDAMED, the data model and the issuing entities overlap, but the submission workflows, attribute lists, and timelines are different. One UDI, two databases.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- FDA UDI rule is codified at 21 CFR Part 801 Subpart B and 21 CFR 830; GUDID is the FDA's device identifier database.
- MDR UDI requirements sit in Articles 27-29, with data submitted to the EUDAMED UDI module.
- FDA and the EU accept the same three issuing entities: GS1, HIBCC, and ICCBBA. You do not need separate codes for each jurisdiction.
- The physical UDI carrier can be the same symbol on both sides of the Atlantic if you design the label carefully.
- The database submissions are separate. GUDID attributes and EUDAMED attributes overlap but do not match one-for-one.
- Class I startups exporting to the US cannot rely on the EU self-certification mindset for UDI data entry; GUDID has its own validation rules.

## Why this matters

If you are an EU startup with CE marking and a US launch planned, the cheapest moment to design your UDI strategy is before you print your first label. The mistake we see most often is teams who finish the EUDAMED UDI entries, celebrate, and then discover six months later that FDA expects a parallel submission with different attributes, different grace periods, and a different definition of when a device is "in commercial distribution."

UDI is not a single global system. It is two systems that happen to be built on the same backbone. Getting that backbone right once saves you from redesigning labels, printing plates, and ERP fields twice.

## What MDR actually says, and what FDA actually says

The EU side is set by Regulation (EU) 2017/745, Articles 27-29. Article 27 establishes the UDI system and defines UDI-DI (device identifier) and UDI-PI (production identifier). Article 28 establishes the UDI database as part of Eudamed. Article 29 sets the registration obligation for manufacturers before placing a device on the market. Annex VI Part C lays out the UDI system rules.

The FDA side is set by 21 CFR Part 801 Subpart B (UDI labeling) and 21 CFR Part 830 (UDI requirements and GUDID). The FDA UDI rule was finalized in 2013 and phased in by device class over several years. GUDID is the database where manufacturers submit the Device Identifier (DI) portion of the UDI.

Both systems share the same conceptual model: a UDI is a DI plus a PI. The DI is a fixed identifier assigned by an issuing entity that uniquely identifies the device model. The PI is variable, covering lot, serial, expiry, and manufacturing date where relevant.

Both systems accredit the same three issuing agencies:
- **GS1** (used by most EU and US manufacturers, global reach)
- **HIBCC** (used in healthcare distribution, particularly in US hospital systems)
- **ICCBBA** (used for blood, cell, tissue, and organ products)

If your startup already has a GS1 company prefix for EUDAMED, the same prefix generates DIs that FDA will accept. This is the single most important fact in this post. You do not pay twice for issuing-entity codes.

## A worked example: a Class IIa infusion accessory

A Graz startup CE marks a Class IIa reusable infusion accessory under MDR in early 2026, enters the UDI-DI into EUDAMED, and now wants to launch in the US under 510(k). Here is what the UDI workflow actually looks like.

**Step 1 — Issuing entity:** The team already obtained a GS1 company prefix when preparing for EUDAMED. They use the same prefix to generate GS1 GTINs as UDI-DIs. No new vendor.

**Step 2 — Physical label:** The EU label already carries a GS1 DataMatrix with the GTIN (DI) plus lot and expiry (PI). FDA accepts the same DataMatrix. The team verifies that the human-readable interpretation next to the symbol meets FDA's requirement under 21 CFR 801.40 for both AIDC and HRI forms. No label redesign needed — this is the "one-label strategy" we recommend whenever it is achievable.

**Step 3 — GUDID submission:** Here the work diverges. The team creates a GUDID account, nominates a Regulatory Contact and a Labeler DUNS number, and submits the device record. GUDID asks for attributes EUDAMED does not ask for, including GMDN preferred term (FDA prefers GMDN for device categorization), FDA Premarket Submission number (the 510(k) K-number), and several commercial distribution date fields. The team cannot simply export the EUDAMED submission as a CSV and reuse it.

**Step 4 — Timing:** The device DI must be in GUDID before the device is in commercial distribution in the US. For 510(k)-cleared devices, the team targets GUDID submission concurrently with the 510(k) clearance, not after. FDA will not issue a warning letter on day one, but they will if you distribute without a GUDID record and get caught.

**Step 5 — Changes:** Every time the team updates an attribute that triggers a new DI under FDA rules (for example, certain design changes), they must generate a new DI and update both GUDID and EUDAMED. A change that requires a new DI under FDA rules usually also requires a new Basic UDI-DI or UDI-DI under MDR logic — but not always. Check both.

The practical result: one physical label, one issuing entity, one GTIN, two database submissions, two regulatory contacts, two sets of change-control triggers.

## The Subtract to Ship playbook

The goal is to do the UDI work once and maintain it with the smallest possible overhead. Every duplicated field is a future data-integrity bug.

**1. Pick one issuing entity and stick with it.** For 95% of startups that is GS1. If you are in blood, cell, or tissue products, that is ICCBBA. Do not run two in parallel unless a customer contract forces you.

**2. Build a single UDI master record.** Maintain one internal spreadsheet (or, better, one structured record in your eQMS) that contains every UDI attribute either jurisdiction asks for. Tag each column with EU-only, US-only, or both. This becomes the source of truth for both EUDAMED and GUDID submissions.

**3. Design the label for the stricter jurisdiction.** For UDI carrier, the requirements are similar, but FDA has specific human-readable interpretation rules under 21 CFR 801.40 that are slightly more prescriptive than Annex VI Part C. Design the label to pass FDA and you will pass EU. Reverse is not always true.

**4. Put the GUDID submission inside your 510(k) project plan, not after it.** Treat the GUDID record as a launch dependency with the same weight as a printed IFU. Teams that leave GUDID for "after clearance" miss their own launch dates.

**5. Nominate your Regulatory Contact carefully.** GUDID requires a named person. If this person leaves your startup, you lose edit access until you update FDA. Use a role-based email address as the account contact where possible, and document the handover in your QMS.

**6. Treat DI change triggers as CAPA-adjacent.** Changes that create a new DI cascade into labeling, inventory, distributor communications, and potentially a new 510(k) or a notification to your Notified Body on the EU side. Make DI change decisions at a management review level, not inside a single change request ticket.

**7. Audit GUDID and EUDAMED against each other quarterly.** Pull both records for every marketed device, line them up, and confirm they tell the same story about the same device. Drift between the two is the single most common UDI nonconformity we see in dual-market startups.

## Reality Check

Ask your team these questions before your next UDI label print run or GUDID submission.

1. Do we have one issuing entity code serving both GUDID and EUDAMED, or are we paying twice?
2. Is there a single internal record per device that drives both the EUDAMED and the GUDID entries?
3. Does our current label carry one UDI carrier that is compliant under both 21 CFR 801.40 and MDR Annex VI Part C?
4. Who is the named GUDID Regulatory Contact, and what happens if they leave next month?
5. Have we mapped every DI change trigger to the MDR significant-change logic and documented the overlap?
6. Is GUDID submission a line item in our US launch project plan, with an owner and a due date relative to 510(k) clearance?
7. When did we last reconcile the GUDID record against the EUDAMED record for each marketed device?
8. If an FDA inspector asked for our UDI-DI assignment procedure tomorrow, would they find one document or six?

## Frequently Asked Questions

**Do I need a different company prefix for GUDID and EUDAMED?**
No. GS1, HIBCC, and ICCBBA codes are accepted by both FDA and the EU. Your one company prefix from any of these three issuing entities generates DIs valid in both jurisdictions.

**Can I use the same DataMatrix symbol on the label for US and EU markets?**
In most cases yes. The AIDC symbol is the same; confirm the human-readable interpretation meets 21 CFR 801.40, which is slightly stricter than MDR Annex VI Part C in formatting.

**When must the GUDID record be live?**
Before the device is in commercial distribution in the US. For 510(k)-cleared devices we treat GUDID submission as a hard gate inside the launch plan, not a post-clearance task.

**Does EUDAMED export to GUDID?**
No. There is no data bridge between the two databases. You maintain both separately from your internal UDI master record.

**What counts as a new DI under FDA rules?**
Certain changes — including some packaging, labeling, and design changes — require a new DI per 21 CFR 830. Check against FDA guidance and map the trigger list against your MDR significant-change logic so you do not update one database without the other.

**Is GUDID submission part of the 510(k) review?**
No. GUDID is separate from premarket review. But the 510(k) K-number is an attribute inside the GUDID record, so you cannot complete the GUDID submission without the clearance number in hand.

## Related reading
- [MDR Articles 27-29: UDI requirements](/blog/mdr-articles-27-29-udi-requirements) — the EU-side legal basis that your GUDID strategy should mirror.
- [UDI carrier requirements](/blog/udi-carrier-requirements) — label-level detail on what your printed symbol must contain.
- [Dual submission strategy: CE and FDA](/blog/dual-submission-strategy-ce-fda) — how to sequence the broader EU/US regulatory path.
- [FDA 510(k) vs MDR CE marking](/blog/fda-510k-vs-mdr-ce-marking) — where the two systems overlap and where they diverge.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 27, 28, 29, and Annex VI Part C.
2. 21 CFR Part 801 Subpart B — Unique Device Identification (FDA).
3. 21 CFR Part 830 — Unique Device Identification (FDA) including GUDID requirements.
4. Commission Implementing Regulation (EU) 2021/2078 of 26 November 2021 on Eudamed rules, pursuant to MDR Art. 33.

---

*This post is part of the [FDA & International Market Access](https://zechmeister-solutions.com/en/blog/category/fda-international) 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).*
