EUDAMED Registration 2026 and Data Integration Guide

EUDAMED registration became operationally mandatory on 28 May 2026, but only for four of the database's six modules: Actor Registration, UDI/Device Registration, Notified Bodies and Certificates, and Market Surveillance (^[1]) (^[2]). Clinical Investigations and Performance Studies remained without a known readiness date, while Vigilance and Post-Market Surveillance remained in development (^[3]) (^[4]). Companies should therefore run a four-module remediation program, not assume that every EUDAMED workflow has moved into the system.

For manufacturers, the sequence is dependency-driven. Register the relevant economic-operator role, obtain an approved Single Registration Number (SRN), establish user access, then register devices. A competent authority verifies the company information before EUDAMED issues the role-linked identifier (^[5]). Devices first placed on the market from 28 May 2026 must be registered before the first unit is placed, with no transition period (^[6]) (^[7]). For legacy and Regulation devices placed on the market before mandatory use, the Commission-published deadline to register the device in the UDI/Device module is 28 November 2026 (^[8]). Manufacturers should also check applicable Member-State requirements.

The data model should be governed in three layers. Basic UDI-DI groups a device model and anchors certificates and declarations. UDI-DI identifies a specific device and manufacturer. Higher package UDI-DIs represent orderable packaging levels, excluding shipping containers (^[9]) (^[10]) (^[11]). Regulatory operations should own submission and legal interpretation, while master-data, labeling, quality, and IT owners supply controlled attributes and evidence.

Submission mode should follow both volume and operating complexity. Commission guidance recommends the user interface for up to 100 devices, bulk upload for 100 to 1,000, and machine-to-machine (M2M) exchange above 1,000 (^[12]) (^[13]). These are sizing guides, not substitutes for total-cost analysis. M2M requires an AS4-compliant access point, Playground onboarding, production testing, security keys, schema governance, and durable reconciliation controls.

The 2026 EUDAMED change is no longer a future-readiness topic. It is a production operating requirement for medical-device organizations that place products on the European Union market. The European Database on Medical Devices, or EUDAMED, connects actor, device, certificate, surveillance, investigation, and vigilance information. Regulation (EU) 2024/1860 replaced an all-at-once launch with module-by-module activation after audit and notice (^[14]). The resulting legal sequence made four systems mandatory on 28 May 2026 (^[1]) (^[2]).

This report is written for regulatory-operations leaders, Unique Device Identification (UDI) stewards, quality leaders, and medtech architects dealing with the period after that date. The decision is not simply whether a registration exists. It is whether every required object is registered, linked to the right actor and identifier, reconciled to source systems, and maintained under a controlled change process.

IntuitionLabs describes capabilities in data pipelines, integration, warehousing, and business intelligence (^[15]) and in implementing and integrating complex enterprise systems (^[16]). This article discusses data-governance and integration considerations rather than presenting an EUDAMED submission product.

The legal trigger and practical scope

Commission Decision (EU) 2025/2371 entered into force when published and relied on an independent audit report dated 18 June 2025 (^[17]). Its publication activated module-specific obligations after six months. The practical scope is asymmetric:

• Manufacturers: register actor roles and all in-scope devices, maintain identifier and device data, and link records correctly. Poland requires device information before first placement (^[18]).

• Authorised representatives: register their actor role and maintain active mandates for non-EU manufacturers. Belgium confirms that associated actors must exist before device registration (^[19]).

• Importers: register where required, verify manufacturer or representative registration, and add importer details. The MDR gives importers a two-week verification window after placing a device (^[20]). Poland also requires an importer to add its own details to the registration (^[21]).

• System or procedure pack producers: register as actors and register non-custom-made packs under the relevant identifier rules.

• Notified bodies: enter new certificate information and status decisions in their module (^[22]).

• Competent authorities and the Commission: use Market Surveillance. Module data are managed only by competent authorities (^[23]).

Distributors do not register in EUDAMED merely because they distribute devices, although separate national duties can apply (^[24]). Custom-made devices also require jurisdiction-specific handling. Spain, for example, retained national communication for custom-made-device manufacturers when it ended its former general national communication process (^[25]).

Deadline logic after the start date

The most important split is first placement before or after 28 May 2026. A qualifying device first placed from that date must be registered before its first unit reaches the market (^[18]). Older devices still being placed after mandatory use fall under the transitional registration rule.

The Commission’s transition infographic states a 28 November 2026 deadline to register legacy and Regulation devices placed on the market before mandatory use in the UDI/Device module (^[8]). Manufacturers should also check additional applicable Member-State requirements.

Table 1 separates the four mandatory modules from the two unfinished modules and assigns an operational owner.

Module	Status as of 18 September 2026	Primary submitting or operating party	Post-deadline control
Actor Registration	Mandatory since 28 May 2026 ([26])	Manufacturer, authorised representative, importer, or system and procedure pack producer	Regulatory operations owns the request; legal-entity master data and the local signatory supply evidence.
UDI/Device Registration	Mandatory since 28 May 2026 ([27])	Manufacturer or pack producer	UDI stewardship controls identifiers; regulatory operations submits; quality approves changes.
Notified Bodies and Certificates	Mandatory since 28 May 2026	Notified body	Manufacturer reconciles certificate references even though the notified body submits. Belgium confirms new certificates and decisions must be registered ([28]).
Market Surveillance	Mandatory since 28 May 2026 for authorities and the Commission ([29])	Competent authorities	Economic operators maintain response readiness and consistent master data, but do not operate the module.
Clinical Investigations and Performance Studies	Under analysis, not mandatory	Future sponsor and authority workflows	Keep national processes and monitor a future functionality notice. Norway reported no known readiness date in June 2026 ([3]).
Vigilance and Post-Market Surveillance	In development, not mandatory	Future economic-operator and authority workflows	Continue applicable national processes. No binding date had been set as of June 2026 ([30]).

The matrix prevents a common planning error: treating EUDAMED as one release. The two unfinished modules will not have a voluntary-use period before becoming mandatory (^[31]). Their future notices should therefore trigger new readiness workstreams, but they should not be represented as current submission obligations.

Actor registration is the first dependency because associated actors must exist before a device can be registered (^[19]). An Actor ID or SRN is an EU-wide unique economic-operator identifier (^[32]). It is tied to a role, so a group cannot assume that one number covers every legal entity or operating role.

Minimum actor workflow

1. Resolve legal identity: match registered name, address, country, tax and registry evidence across corporate systems. Austria's authority expects the company name to be consistent across the commercial register, documents, and EUDAMED (^[33]).

2. Select the role: determine whether the entity is an EU manufacturer, non-EU manufacturer, authorised representative, importer, or pack producer. Austria distinguishes SRNs for manufacturers, representatives, and importers from Actor IDs for other actors (^[34]).

3. Prepare relationship evidence: a non-EU manufacturer needs an active authorised representative and a mandate summary (^[35]).

4. Sign the security declaration: all actors upload a signed information-security responsibility declaration (^[36]).

5. Submit for authority approval: the authority verifies the record before EUDAMED issues the identifier.

6. Provision individual users: each person acting for the registered actor requests access separately (^[37]).

7. Maintain the record: changed actor data must be updated within one week (^[38]). Accuracy is confirmed within one year after registration and every two years thereafter (^[39]).

The operational implication is that SRN work cannot sit only in a launch project. Legal-entity events such as address or representative changes need a monitored feed into regulatory operations. Importers also need a device-level verification control. Poland explicitly requires the importer to confirm registration and add its own data (^[40]).

The EUDAMED device model is not a flat product list. It is a relationship graph among a model family, a specific device identifier, packaging identifiers, actors, nomenclature, certificates, and market information.

Table 2 shows the identifier levels and the control questions that matter during remediation.

Identifier level	What it represents	Typical controlled attributes	Governance test
Basic UDI-DI	Primary identifier of a device model and the main key used across certificates and declarations ([9])	Manufacturer SRN, risk class, model grouping, certificate references	Do all linked UDI-DIs share intended purpose, risk class, and essential design and manufacturing characteristics?
UDI-DI	Identifier specific to one manufacturer and device ([41])	Catalogue reference, unit quantity, direct marking, UDI-PI type, EMDN code, status	Does the record match label, enterprise resource planning, product lifecycle, and regulatory sources?
Package UDI-DI	Identifier for each applicable higher packaging level	Issuing entity, package DI, quantity per package, status ([42])	Is every orderable packaging level linked, with shipping containers excluded?
UDI-PI	Production identifier for a unit of production	Lot, serial, software version, manufacture or expiry elements as applicable	Is production information correctly encoded on labels without being mistaken for the EUDAMED device master key?
Legacy EUDAMED DI	Substitute identifier when a legacy device has no UDI-DI	Manufacturer device identifier, linked actor, EMDN, certificate and status data	Was an EUDAMED DI supplied or generated, and is the later Regulation record linked when the UDI-DI is reused?

The hierarchy matters because UDI-DIs inherit attributes from their linked Basic UDI-DI and device DI (^[43]). A wrong family-level value can therefore affect many device records. EMDN, the European Medical Device Nomenclature, is required for manufacturer device registration (^[44]).

Issuing-entity rules also matter. In GS1, the UDI-DI is represented by the Global Trade Item Number and the Basic UDI-DI by the Global Model Number (^[45]). ICCBBA limits its Basic UDI-DI to 25 characters and requires a check character (^[46]) (^[47]). HIBCC's generator uses a case-sensitive global model identifier of 1 to 17 alphanumeric characters (^[48]). The Commission identifies HIBCC as one of four issuing entities designated to provide manufacturers with a list of UDIs to assign on medical devices; the designations were renewed until 27 June 2029 (^[49]).

Legacy-device decision sequence

• Was the device first placed from 28 May 2026? If yes, register before first placement. Treat it as a Regulation device, not a transition backlog item.

• Was it first placed earlier but still placed after mandatory use? If yes, apply the transitional registration period and plan to the earliest competent-authority date.

• Does it already have a UDI-DI? Use it where the legacy workflow permits. If not, provide an EUDAMED DI (^[50]).

• Should EUDAMED generate the DI? The legacy workflow can generate one during registration from the manufacturer's device identifier (^[51]).

• Is the same UDI-DI later used under MDR or IVDR? Preserve enough lineage for EUDAMED to link the legacy and Regulation records (^[52]).

• Is the record still commercially relevant? Establish evidence for whether it remains placed on the market, rather than bulk-registering every historical catalogue item without classification.

The regulatory record should be assembled from controlled sources, not maintained as an isolated spreadsheet. FDA's UDI preparation guidance, useful as a general master-data benchmark, recognizes that required information may live in multiple systems and locations and recommends standard operating procedures for records management (^[53]) (^[54]). IMDRF likewise recommends validation procedures that improve consistency across internal regulatory systems and reduce duplicate entry (^[55]) (^[56]).

Table 3 maps common EUDAMED data groups to accountable sources and validation rules.

EUDAMED data group	Authoritative source system	Accountable owner	Pre-submission validation
Legal entity and SRN	Corporate legal-entity master, representative mandates	Regulatory operations with legal	Exact name and address match; active mandate; role-specific SRN; signed security declaration.
Basic UDI-DI family	Regulatory information management and product lifecycle management	Global UDI steward	Same intended purpose, risk class, and essential design characteristics; certificate and declaration alignment. ICCBBA places the mapping responsibility on manufacturers ([57]).
UDI-DI and label attributes	Labeling system, ERP item master, issuing-entity registry	UDI and labeling teams	Identifier checksum, issuing entity, catalogue reference, unit quantity, direct-marking logic, exact label match.
Packaging hierarchy	ERP packaging bill, logistics master	Supply-chain master-data owner	All applicable package levels linked; quantities coherent; shipping containers excluded. IMDRF expects every level in a related hierarchy ([58]).
Classification and EMDN	Regulatory information management	Regulatory affairs	MDR or IVDR class agrees with evidence; lowest applicable EMDN code selected; family inheritance checked.
Certificate data	Quality and regulatory certificate repository	Quality assurance and notified-body liaison	Certificate number, scope, dates, status, notified body, Basic UDI-DI linkage reconcile to the certificate-module record.
Market information	Commercial country master and regulatory launch status	Regulatory operations with supply chain	Country additions or removals are approved and translated into the designated market-information operation.
Submission status and errors	Integration log and regulatory submission register	EUDAMED service owner	Correlation ID, payload hash, response, error code, retry state, acceptance state, and EUDAMED record identifier retained.

The table implies a federated ownership model. Regulatory operations remains accountable for the submission, but cannot credibly own every source attribute. Danish guidance assigns manufacturers both entry and ongoing maintenance responsibility (^[59]) (^[60]). A RACI should therefore distinguish data creation, approval, submission, and reconciliation.

Manual user interface

Manual entry is the lowest-infrastructure option. The Commission defines it as direct manual input through the application (^[61]). It fits a small, stable portfolio and low change volume.

• Use when: fewer than roughly 100 devices, few packaging levels, low update frequency, and named trained users.

• Strength: minimal technical setup and immediate visibility of on-screen validation.

• Constraint: repeated typing, inconsistent evidence capture, and weak scalability unless a controlled submission worksheet and peer review sit behind it.

• Required control: record the source value, submitter, approver, timestamp, and returned EUDAMED identifier outside the interface.

Bulk XML upload and download

Bulk exchange is semi-automated because file upload and download remain manual (^[62]). It is a practical middle path for a finite remediation backlog or periodic controlled releases.

• Use when: roughly 100 to 1,000 devices, data can be normalized into XML, and releases occur in batches.

• Strength: repeatable transformation and validation without operating an access point.

• Constraint: manual file movement, version control, and response handling can create handoff risk.

• Required control: validate against the current XML Schema Definition (XSD), freeze each payload, ingest the full response, and reconcile accepted counts to requested counts.

Machine-to-machine data exchange

M2M automatically exchanges data between an external backend and EUDAMED (^[63]). It becomes attractive for large portfolios, frequent changes, or multiple submitting entities, but it is an integration product with ongoing ownership.

• Architecture: install and configure a dedicated Connecting Europe Facility eDelivery Access Point (^[64]). Both endpoints must be AS4 compliant, and EUDAMED uses Domibus (^[65]) The Commission describes Domibus as its implementation of an eDelivery AS4 access point (^[66]).

• Prerequisites: register as an actor, obtain a security key for each module, complete Playground onboarding, and provide proof of successful testing before production (^[67]) (^[68]).

• Reliability: implement correlation, idempotency, retry, and permanent-failure alerting. The underlying AS4 profile includes duplicate detection or elimination (^[69]) and notification after permanent delivery failure (^[70]).

• Lifecycle: monitor release notes and XSD changes. XML on a noncurrent schema is rejected (^[71]).

The threshold should not be applied mechanically. (Hypothetical Example) A company with 300 stable records might choose bulk upload, while one with 300 frequently changing records across several legal entities may justify M2M. The decision model should price build and validation effort, access-point operation, schema-change maintenance, submission volume, error-rework labor, and the business impact of delayed updates.

The available evidence supports a capacity model rather than a market-size analysis. The central quantitative variables are object counts, deadlines, message limits, update windows, and completion rates.

Official sizing and technical limits

• Channel breakpoints: user interface up to 100 devices, bulk exchange from 100 to 1,000, and M2M above 1,000 (^[72]). These ranges overlap at 100 and 1,000, so they are directional selection points, not exclusive legal boundaries.

• Access points: economic operators may have up to two access points in relevant onboarding statuses (^[73]).

• Message size: for ZIP-based exchange, XML is limited to 1 MB and the attached binary to 50 MB. M2M XML is limited to 50 MB (^[74]) (^[75]).

• Atomic rejection: a file containing an error is rejected in full, with nothing recorded, while the response identifies all detected errors (^[76]) (^[77]).

• Maintenance windows: actor-data changes have a one-week update requirement; certain UDI record changes that do not require a new UDI-DI must be reflected within 30 days (^[78]).

Readiness calculator

Organizations should calculate readiness only from their own verified object inventory. Do not infer completeness from the number of visible records alone.

• Actor completeness: completed required actor-role records divided by total required actor-role records.

• Device completeness: accepted required device records divided by total required device records.

• Certificate reconciliation: certificate records matched to the correct Basic UDI-DI and notified-body entry divided by certificates requiring reconciliation.

• Overall readiness: completed required records across all three populations divided by total required records, reported alongside the three component rates.

• First-pass acceptance: payloads accepted without correction divided by payloads submitted.

• Reconciliation closure: accepted EUDAMED records matched back to a source-system object divided by accepted records.

(Hypothetical Example) An inventory of 12 actor-role records, 4,800 device records, and 160 certificate relationships should not be reported as 95 percent ready merely because actors are complete. Each denominator and completion rate should remain visible. A weighted overall rate may support management reporting, but only the component rates reveal the constraint.

No public EUDAMED benchmark establishes an expected first-pass acceptance rate or reconciliation cadence. A defensible internal target should therefore derive from risk and update timing. IMDRF recommends documenting field type, length, edit rules, and whether a change triggers a new UDI-DI (^[79]). Those attributes can become measurable validation rules rather than qualitative review prompts.

For comparison only, other official UDI services publish explicit refresh patterns: openFDA states that its UDI API updates weekly (^[80]). This is not an EUDAMED service commitment, but it illustrates why a reconciliation cadence should be defined rather than assumed.

Submission success is not the same as data correctness. MDR assigns manufacturers responsibility for initial UDI submission and updates (^[81]) and requires periodic verification for devices still on the market (^[82]). The operating model needs preventive, detective, and corrective controls.

Preventive controls

• Schema validation: validate each payload against the production XSD version and the Commission business rules.

• Referential integrity: confirm actor, representative, Basic UDI-DI, UDI-DI, package, certificate, and EMDN references exist and are mutually compatible.

• Controlled vocabularies: map source terms to EUDAMED codes through versioned lookup tables.

• Change classification: decide whether a proposed change is editable, requires a new UDI-DI, or needs a new Basic UDI-DI. A new UDI-DI does not automatically require a new Basic UDI-DI (^[83]).

• Four-eyes review: require independent approval for initial registration, family reassignment, identifier change, certificate linkage, and market-status change.

Detective controls

• Count reconciliation: compare requested, rejected, accepted, and visible records for every batch.

• Field reconciliation: compare high-risk values in EUDAMED back to their systems of record. FDA's UDI quality guidance frames the goal as sufficient confidence in data accuracy and completeness (^[84]).

• Hierarchy reconciliation: detect orphan package DIs, duplicated natural keys, broken family links, and missing certificate relationships.

• Aging review: monitor open errors against one-week, two-week, 30-day, and transition deadlines.

• Public-view comparison: where data are public, compare published presentation to the accepted internal record.

Corrective controls

• Triage by cause: separate source-data defects, transformation defects, schema-version defects, access problems, and EUDAMED service responses.

• Preserve evidence: retain payload, response, correlation ID, operation code, timestamps, and approvals.

• Retry safely: use idempotency and duplicate controls. EUDAMED's rules call for a retry mechanism for delivery errors (^[85]).

• Correct upstream: fix the authoritative system first unless an urgent controlled exception is documented. Otherwise the next synchronization can restore the wrong value.

• Close the loop: confirm the corrected EUDAMED state and link the resolution to the initiating change record.

Three implications follow for the post-deadline operating model. First, EUDAMED is now master-data infrastructure, not a one-time regulatory form. Device information must remain consistent across submitted documents and EUDAMED (^[86]). Regulatory, quality, labeling, supply-chain, and IT controls should therefore share identifiers and change events.

Second, automation transfers work rather than removing it. Manual entry concentrates effort in submission. Bulk exchange shifts effort into mapping and batch control. M2M shifts it into access-point operation, security keys, service monitoring, schema releases, and reconciliation. The Commission technical set includes XSDs and business-rule constraints (^[87]); someone must own their lifecycle.

Third, the remaining modules require a watch function, not premature migration. The Commission says Vigilance is unavailable for voluntary use, so economic operators continue national processes (^[88]). Norway's non-binding indication of a possible 2027 Vigilance implementation is useful for scenario planning, but not a legal deadline (^[89]). Readiness teams should monitor Commission notices, reserve architecture capacity, and keep unfinished-module data models separate from current mandatory scope.

This EUDAMED device registration guide addresses the main search variants directly: EUDAMED registration requirements 2026, the EUDAMED mandatory registration deadline, EUDAMED UDI device registration, EUDAMED actor registration requirements, EUDAMED data integration, EUDAMED API integration, legacy devices, and EUDAMED compliance for manufacturers.

Is every EUDAMED module mandatory in 2026?

No. Four modules became mandatory on 28 May 2026. Clinical Investigations and Performance Studies remained under analysis, and Vigilance and Post-Market Surveillance remained in development as of 18 September 2026. Market Surveillance is mandatory for competent authorities and the Commission, not a direct economic-operator submission workspace.

Who must complete EUDAMED actor registration?

EU and non-EU manufacturers, authorised representatives, importers, and system or procedure pack producers are within the Commission's stated actor scope (^[90]). Distributors are not required to register solely as distributors, but national obligations should still be checked.

What is the EUDAMED mandatory registration deadline?

Newly placed qualifying devices have needed registration before first placement since 28 May 2026. For legacy and Regulation devices placed on the market before mandatory use, the Commission-published deadline to register the device in the UDI/Device module is 28 November 2026 (^[8]). Manufacturers should also check applicable Member-State requirements.

Is the Basic UDI-DI printed on the label?

No. It groups the device model and connects regulatory records. ICCBBA expressly states that its Basic UDI-DI does not appear on a trade item (^[91]). The UDI-DI and applicable production identifier are the labeling-level concepts.

Is there an EUDAMED API?

The official integration mechanism is Data Exchange Machine-to-Machine, not a casual public REST API. It uses AS4 messaging through a dedicated eDelivery access point, module-specific security keys, Commission schemas, business rules, and onboarding in the Playground environment. The Commission describes production as containing real market data and Playground as containing valid but fake test data (^[92]).

What should a manufacturer do first after finding a registration gap?

Classify the gap by object and deadline, confirm the actor and SRN dependency, identify the authoritative source system, correct the source, validate the record, submit through the appropriate channel, and reconcile the accepted EUDAMED state. A record should not be marked complete merely because a payload was sent.

EUDAMED registration in 2026 is a live operating obligation with a precise boundary. Four modules are mandatory, two are not yet mandatory, and each has a different accountable party. For manufacturers, actor and SRN readiness precedes device registration. Device readiness then depends on a coherent Basic UDI-DI, UDI-DI, packaging, EMDN, certificate, and legacy-record model.

The most reliable remediation program starts with an object inventory and clear denominators. It assigns every attribute to an authoritative source and accountable owner, selects manual entry, bulk XML, or M2M according to portfolio scale and change volume, and treats acceptance responses as inputs to reconciliation rather than proof of completeness. For legacy and Regulation devices placed on the market before mandatory use, it applies the Commission-published 28 November 2026 deadline to register the device in the UDI/Device module and separately checks applicable Member-State requirements (^[8]).

The durable outcome is not a one-time backlog reduction. It is a controlled data supply chain that detects legal-entity changes, product and packaging changes, certificate changes, schema releases, and submission exceptions early enough to meet the applicable update window. That operating model will also make future module activation easier, without incorrectly presenting the two unfinished modules as current requirements.