EUDAMED Registration Mistakes: The 10 Most Common Errors and How to Fix Them Before May 28, 2026

The Deadline Is Real and It Is Close

On November 27, 2025, the European Commission published Commission Decision (EU) 2025/2371 confirming that four EUDAMED modules — Actors, UDI/Devices, Notified Bodies/Certificates, and Market Surveillance — are fully functional. This triggered the six-month transition period established under Regulation (EU) 2024/1860. On May 28, 2026, EUDAMED transitions from a voluntary system to a mandatory requirement for placing medical devices and IVDs on the EU market.

The key deadlines are not abstract milestones. They are legally enforceable:

Date	Requirement	Legal Basis
May 28, 2026	Actor registration (SRN) mandatory; new devices must be registered in EUDAMED before market placement	MDR Art. 29, Art. 31; IVDR Art. 26, Art. 28
November 27, 2026	Legacy devices already on the market before May 28, 2026 must be registered	Regulation (EU) 2024/1860, transitional provisions
May 28, 2027	Notified Bodies must complete uploading all certificates issued before May 2026	MDR Art. 33(2)(a)-(b)

If your economic operators do not have Single Registration Numbers and your device data is not in EUDAMED, you cannot legally place devices on the EU market after May 28, 2026. For a full walkthrough of the registration process itself, see the EUDAMED Registration Guide. For role-specific actions on and after the mandatory date, see the EUDAMED Day Zero Role-Specific Playbook.

This article focuses on a different problem: the mistakes manufacturers are making right now as they attempt to complete registration. Based on regulatory consulting experience and Competent Authority feedback, these are the ten most common errors — and exactly how to prevent or correct each one.

---

Mistake 1: Treating EUDAMED as an IT Project Instead of a Data Governance Challenge

The Problem

Many manufacturers assign EUDAMED registration to their IT department or treat it as a bulk data migration task. The thinking goes: "We have the data somewhere in our ERP system, so we just need to extract it and upload it." This approach fails because EUDAMED does not accept raw product data. It accepts structured, validated regulatory data that maps to specific MDR and IVDR requirements.

The data you need for EUDAMED — Basic UDI-DI groupings, EMDN codes, conformity assessment procedures, risk classifications, PRRC details, certificate references — lives across multiple systems and multiple teams. Your ERP has SKU numbers, not UDI-DIs. Your quality system has risk classification rationale, but not in a format EUDAMED can ingest. Your regulatory affairs team holds the certificate data, but the certificates themselves must be confirmed by your Notified Body inside EUDAMED.

What This Looks Like in Practice

• A manufacturer discovers that its product catalog lists 2,000 SKUs but has only 300 Basic UDI-DIs defined. The remaining 1,700 entries have no regulatory grouping.
• Another company exports device data from its PLM system, only to find that risk classes were entered as free text ("Class IIa") rather than structured codes that EUDAMED expects.
• A third manufacturer attempts XML bulk upload and receives hundreds of validation errors because the data model does not match EUDAMED's schema.

How to Fix It

Treat EUDAMED as a regulatory data governance program, not an IT deliverable.

1. Appoint a cross-functional EUDAMED steering group. Include regulatory affairs (lead), quality assurance, IT, and commercial operations. Regulatory affairs must own the data definitions and validation rules.
2. Conduct a data audit before you touch EUDAMED. Map every data element required by MDR Annex VI Part B against your current source systems. Identify gaps. For each gap, assign an owner and a deadline.
3. Build a data dictionary. Define what each EUDAMED field means in regulatory terms, where the authoritative source data lives, who is responsible for maintaining it, and what validation rules apply.
4. Establish a data quality workflow. Data extraction, regulatory review, validation, upload, and post-upload verification should be separate steps with separate accountable roles.
5. Test with a subset. Before bulk uploading, register 10-20 representative devices manually through the web interface. This teaches you the data model, exposes validation rules, and reveals gaps in your source data.

For the broader regulatory framework that shapes these data requirements, see the EU MDR and IVDR Complete Guide.

---

Mistake 2: Delaying Actor Registration (SRN)

The Problem

The Single Registration Number is the gateway to everything else in EUDAMED. Without an SRN, you cannot register devices, your Notified Body cannot link certificates to your actor record, and your importers cannot identify you in the system. Despite this, many manufacturers delay actor registration. Some assume it is a formality that takes a few days. Others wait for "perfect" data before submitting.

What the Delay Costs

Actor registration is not instant. The process requires:

1. Creating an EU Login account
2. Completing the actor registration form with organization details, PRRC information, and role-specific data
3. For non-EU manufacturers: verification by the Authorized Representative, followed by Competent Authority validation
4. For EU operators: direct Competent Authority validation

Competent Authorities are processing thousands of registration requests. Validation timelines range from a few days to several weeks depending on the member state and the completeness of your submission. If you submit incomplete data, the Competent Authority sends it back. You correct it. You resubmit. The clock restarts.

If you do not have your SRN by May 28, 2026, you cannot register devices. You cannot place new devices on the market. Your certificate data cannot be linked. Every downstream activity is blocked.

How to Fix It

1. Register now if you have not already. As of April 2026, if your SRN is not issued or in Competent Authority review, you are behind schedule.
2. Submit complete data on the first attempt. Prepare all required documents before you begin: PRRC qualifications (degree, CV, proof of employment), organization registration documents, and authorized representative details. Incomplete submissions are the single biggest cause of SRN delays.
3. Assign at least two Local Actor Administrators (LAAs) immediately after receiving your SRN. The UDI/Device Module will not activate until your actor record has a minimum of two LAAs. This is a hard system requirement.
4. If you operate in multiple roles (for example, you are both a manufacturer and an importer), register for each role separately. Each role receives its own SRN.

---

Recommended Reading

Home-Use and Self-Test IVDs: Regulatory Pathway, Human Factors, Labeling, and Post-Market Risk Controls

IVD & Diagnostics Regulatory2026-04-30 · 11 min read

Mistake 3: Flawed Basic UDI-DI Strategy

The Problem

The Basic UDI-DI is the highest level of device identification in EUDAMED. It groups devices that share the same intended purpose, risk class, and conformity assessment procedure. Think of it as the regulatory family identifier. Get this wrong, and every device linked to that Basic UDI-DI inherits the error.

Common errors include:

• Too many Basic UDI-DIs. Some manufacturers create a separate Basic UDI-DI for every product variant, defeating the purpose of the grouping structure. EUDAMED becomes cluttered with thousands of Basic UDI-DI records that should have been consolidated.
• Too few Basic UDI-DIs. Other manufacturers group devices with different risk classes or different conformity assessment procedures under a single Basic UDI-DI. This violates MDR Annex VI and causes validation failures.
• Confusing Basic UDI-DI with UDI-DI. The Basic UDI-DI identifies the device family. The UDI-DI identifies the specific product at a given packaging level. They serve different purposes and have different data requirements in EUDAMED. Mixing them up is a fundamental structural error.

How to Fix It

1. Apply the grouping criteria strictly. Devices may share a Basic UDI-DI only if they share the same manufacturer, the same intended purpose, the same risk class (or are covered by the same conformity assessment procedure), and the same generic device group as defined by the EMDN nomenclature. Review MDR Annex VI Part C for the detailed criteria.
2. Map your portfolio before generating Basic UDI-DIs. Create a device grouping matrix that lists every product, its risk class, its conformity assessment procedure, its intended purpose, and its EMDN code. Group products that share all four attributes. Each group gets one Basic UDI-DI.
3. Align with your Notified Body. For devices that require Notified Body involvement, the Basic UDI-DI is referenced on the certificate. Your Notified Body must confirm the Basic UDI-DI in EUDAMED. If your grouping does not match the certificate structure, the Notified Body will reject it.
4. Document the rationale for each Basic UDI-DI grouping. Competent Authorities may audit your device identification strategy. Having a documented rationale for why certain devices share a Basic UDI-DI — and why others do not — is essential.

For a deeper treatment of UDI structure and device identification, see the Medical Device Labeling and UDI System Guide.

---

Mistake 4: GMDN vs EMDN Nomenclature Confusion

The Problem

EUDAMED uses the European Medical Device Nomenclature (EMDN), not the Global Medical Device Nomenclature (GMDN). This is a frequent source of error, especially for manufacturers who have built their product classification systems around GMDN codes for FDA submissions, Health Canada registrations, or other markets.

The two systems are not interchangeable. GMDN and EMDN have different structures, different code hierarchies, and different definitions for similar device types. Automated GMDN-to-EMDN mapping tools exist, but they produce approximations, not regulatory-grade classifications. Relying on automated mapping without regulatory review introduces systematic errors across your entire portfolio.

A particularly dangerous error is selecting mid-level or high-level EMDN codes instead of the required "leaf" level codes. EUDAMED requires the most specific (lowest-level) EMDN code available for each device. Selecting a parent code instead of a leaf code will cause registration failures or, worse, will register devices under incorrect nomenclature that is difficult to correct after the fact.

How to Fix It

1. Use the official EMDN database. The European Commission publishes the EMDN on its website. Download the latest version and use it directly. Do not rely on third-party tools that claim to convert GMDN to EMDN.
2. Select leaf-level codes only. When browsing the EMDN hierarchy, always drill down to the most specific code that describes your device. If a code has child codes beneath it, you must select from among the children.
3. Assign a regulatory affairs professional to nomenclature selection. This is not a data entry task. The person selecting EMDN codes must understand the device's intended purpose, mechanism of action, and anatomical application well enough to pick the correct code from a hierarchy of thousands.
4. Validate against your technical documentation. Cross-check each EMDN code against the intended purpose statement in your technical file. If the EMDN code describes a device category that does not match your intended purpose, the code is wrong.
5. Build an EMDN mapping table for your portfolio. Once you have identified the correct EMDN codes, maintain a reference table that maps each product to its code. This prevents rework when you register new devices or update existing records.

---

Mistake 5: Underestimating Legacy Device Volume

The Problem

Legacy devices — those legally placed on the EU market under MDD, AIMDD, or IVDD certificates before May 28, 2026 — must be registered in EUDAMED by November 27, 2026. This sounds like a generous window. It is not.

The challenge is volume and data availability. Legacy devices were certified under the old directives. Many do not have Basic UDI-DIs because the UDI requirement did not exist under MDD or IVDD. Many have certificates that do not follow the MDR certificate structure. Many have technical documentation that uses classification nomenclature inconsistent with EUDAMED's data model.

For legacy devices without a Basic UDI-DI, EUDAMED assigns an EUDAMED-DI. This is a system-generated identifier that serves as the device family identifier within EUDAMED. The manufacturer does not generate it; EUDAMED creates it during the registration process. But the manufacturer must still provide all the associated data: intended purpose, risk class, certificate reference, EMDN code, and market placement information.

What the Scale Looks Like

Consider a mid-sized manufacturer with 150 active certificates and an average of 20 device variants per certificate. That is 3,000 legacy device records that need to be created in EUDAMED within six months. Each record requires multiple data fields, cross-referencing with certificate data (which must be uploaded by the Notified Body), and validation. The throughput requirement is not trivial.

How to Fix It

1. Inventory your legacy portfolio now. You cannot register what you have not cataloged. Build a complete list of every device legally on the EU market as of May 28, 2026, with its certificate number, risk class, and intended purpose.
2. Prioritize by certificate expiry. Legacy devices whose certificates expire soonest should be registered first. If a certificate is withdrawn or expires before the device is registered, the device loses its legal basis for being on the market.
3. Use XML bulk upload for legacy devices. Manual entry is not viable for large portfolios. Invest in preparing a validated XML file for each batch of legacy devices. Test with a small batch first.
4. Coordinate with your Notified Body on certificate data. Your Notified Body must upload certificate information before you can complete device registration for certified devices. Ensure your Notified Body has your complete certificate list and has begun uploading.
5. Budget adequate resources. Legacy device registration is a dedicated project. Assign specific team members, set weekly throughput targets, and track progress against the November 27, 2026 deadline.

---

Recommended Reading

Clinical Evaluation Report Template: EU MDR CER Structure, Tables, and Evidence Traceability

Clinical Evidence EU MDR / IVDR2026-04-30 · 18 min read

Mistake 6: Not Coordinating with Authorized Representatives

The Problem

For non-EU manufacturers, the Authorized Representative (EC REP) plays a critical role in EUDAMED registration. The AR must verify the non-EU manufacturer's actor registration before it is submitted to the Competent Authority. The AR's Competent Authority is the one that validates and issues the SRN. Without the AR's active participation, non-EU manufacturers cannot complete actor registration.

Beyond actor registration, the AR is referenced in device registration records. EUDAMED links the non-EU manufacturer to the AR by SRN. If the AR has not registered or has registered with incorrect data, the link fails. The device record cannot be completed.

This creates a coordination problem. Non-EU manufacturers often assume the AR will handle their side automatically. ARs, in turn, may wait for the manufacturer to initiate the process. The result is a stalemate that costs weeks.

How to Fix It

1. Contact your AR immediately if you have not discussed EUDAMED coordination. Confirm that your AR has registered in EUDAMED and has an active SRN.
2. Agree on a registration sequence. The AR must verify your actor registration. Schedule a specific date for this. Do not leave it open-ended.
3. Share your device registration data with your AR before uploading. The AR is legally responsible under MDR Article 11 for certain device data. The AR should review the data that will be linked to their actor record.
4. If you have multiple ARs in different member states, coordinate with each one separately. Each AR is verified by a different Competent Authority, and processing times vary by country.
5. Include EUDAMED coordination in your AR agreement. If your mandate under MDR Article 11 does not specifically address EUDAMED cooperation obligations, amend it. The regulation requires cooperation, but a clear contractual framework prevents misunderstandings.

---

Mistake 7: Ignoring Module Interdependencies

The Problem

EUDAMED's four active modules are not independent databases. They are interconnected, and data in one module flows into and constrains data in others. Treating them as standalone inputs causes cascading failures.

The key interdependencies are:

Source Module	Target Module	Dependency
Actor (SRN)	UDI/Device	Manufacturer cannot register devices without SRN
Actor (SRN)	Notified Bodies/Certificates	NB cannot link certificates to manufacturer without manufacturer SRN
Notified Bodies/Certificates	UDI/Device	Basic UDI-DI for certified devices must be confirmed by NB before status moves to "Registered"
UDI/Device	Market Surveillance	Competent Authorities use device data for surveillance activities
Actor (AR SRN)	UDI/Device	Non-EU manufacturer device records reference AR SRN

Consider a scenario: a manufacturer uploads Basic UDI-DI data and several UDI-DI records. The device status shows "Submitted" but never moves to "Registered." The reason is that the Notified Body has not yet uploaded the corresponding certificate data. Without the certificate confirmation, the device record is locked in a pending state. The manufacturer assumes the upload was successful and moves on, not realizing the devices are not yet visible in the public database.

How to Fix It

1. Map the dependency chain for your specific situation. Every manufacturer's dependency chain depends on their risk class, conformity assessment route, and whether they are EU- or non-EU-established. Write it out.
2. Track status across modules. Do not assume that a successful upload equals a successful registration. Monitor the status of each device record (Draft, Submitted, Registered) and each certificate record. If something is stuck in "Submitted," identify which dependency is blocking it.
3. Establish a communication cadence with your Notified Body. For any device above MDR Class I (self-declared) or IVDR Class A, your Notified Body must confirm the Basic UDI-DI. Agree on a timeline for this confirmation. Without it, your device records remain in limbo.
4. Test the full workflow end to end before scaling. Register one Basic UDI-DI, get it confirmed by the Notified Body, then register the associated UDI-DIs. Verify that the full chain works before you attempt bulk upload.

---

Mistake 8: Delegating to Non-Regulatory Personnel

The Problem

EUDAMED data entry is often delegated to administrative staff, junior employees, or outsourced data entry teams who do not have working knowledge of MDR classification rules, UDI structure, conformity assessment procedures, or the regulatory implications of the data they are entering. The result is systematic errors that are difficult to detect because the data "looks right" at a surface level but is wrong in regulatory terms.

Examples of errors caused by insufficient regulatory knowledge:

• Selecting the wrong conformity assessment annex (for example, Annex IX instead of Annex XI Part A for a specific device) because the data entry operator did not understand the distinction
• Entering the wrong risk class because the operator referenced an outdated classification document
• Listing incorrect device characteristics (sterilization method, single-use status) because the operator copied data from a marketing brochure instead of the technical file
• Failing to link the correct certificate to a Basic UDI-DI because the operator did not know which certificate covered which device group

These errors create a compliance problem that is worse than no data at all. Incorrect data in EUDAMED is a regulatory record. Correcting it requires formal amendment procedures and may trigger Competent Authority inquiries.

How to Fix It

1. The person entering data must understand what they are entering. This does not mean every data entry operator needs to be a regulatory affairs professional. It means they must be trained on the specific data elements they are responsible for, including what each field means, where to find the authoritative source data, and what validation rules apply.
2. Implement a two-person rule. One person enters the data. A second person with regulatory expertise reviews it before submission. This is a standard quality practice and it catches errors that self-review does not.
3. Create standardized data entry procedures. For each EUDAMED module, document step-by-step instructions that include the regulatory context for each field, the authoritative source for the data, and common errors to avoid.
4. Retain regulatory affairs ownership. The regulatory affairs team should own the EUDAMED registration process end to end. Data entry can be delegated, but accountability cannot.

---

Recommended Reading

RUO vs IUO vs IVD Labeling: When Research-Use and Investigational-Use Products Become Regulated Diagnostics

IVD & Diagnostics Regulatory2026-04-30 · 14 min read

Mistake 9: Inadequate UDI Data Validation

The Problem

EUDAMED enforces specific validation rules on UDI data. These rules are not always obvious from the user interface, and they are not the same as the validation rules used by FDA's GUDID or other UDI databases. Manufacturers who assume that data validated for one UDI database will pass EUDAMED validation are in for surprises.

Common validation failures include:

• Risk class and conformity assessment mismatch. EUDAMED checks whether the risk class is consistent with the conformity assessment procedure. For example, if you register a Class III device under a self-certification conformity assessment route (which does not exist for Class III), the system will reject the record.
• Inconsistencies between EUDAMED data and the Declaration of Conformity. The device description, intended purpose, and risk class in EUDAMED must match the Declaration of Conformity. If they differ, the record is inconsistent and may be flagged during Competent Authority review.
• Incorrect UDI formatting. Each issuing agency (GS1, HIBCC, ICCBBA) has specific formatting rules for UDI-DI and UDI-PI. EUDAMED validates the format against the issuing agency's standard. Incorrectly formatted UDIs are rejected.
• Missing or incorrect unit of use DI. The Unit of Use Device Identifier is required for devices where the lowest packaging level does not contain a single device. Omitting it or entering it incorrectly causes validation failures.

How to Fix It

1. Build a pre-upload validation checklist. Before entering any data into EUDAMED, validate each record against the following:
   • Risk class matches the classification rationale in the technical file
   • Conformity assessment procedure matches the certificate (for certified devices)
   • UDI-DI format is valid for the issuing agency
   • Basic UDI-DI grouping is consistent with the certificate structure
   • Device description matches the Declaration of Conformity
   • EMDN code is at leaf level and matches the intended purpose
   • All mandatory fields are populated
2. Use the EUDAMED validation tools. EUDAMED provides data validation functionality for XML uploads. Use the validation step before submitting. It catches formatting errors and some logical inconsistencies.
3. Cross-reference with your technical documentation. Every data point in EUDAMED should be traceable to a specific section of your technical file, Declaration of Conformity, or certificate. If a data point cannot be traced, it has not been validated.
4. Review existing records for consistency. If you registered devices during the voluntary phase, review them now. Data entered voluntarily may not have been subject to the same rigor as data entered under the mandatory deadline.

---

Mistake 10: Missing the Early Readiness Window

The Problem

The transition period from November 27, 2025 to May 28, 2026 was designed to give manufacturers time to complete registration. In practice, many manufacturers delayed action. Some waited for guidance documents that have since been published. Others assumed the deadline would be extended. As of April 2026, the system is approaching capacity.

What happens when everyone tries to register at the last minute:

• EUDAMED test environment slots become scarce. The European Commission provides a test environment (the "sandbox") for manufacturers to practice registration. Slots are limited and booking windows fill up as the deadline approaches.
• Competent Authority processing times increase. Competent Authorities have finite resources for validating actor registrations. As the volume of submissions surges, processing times extend from days to weeks.
• Notified Body bandwidth is constrained. Notified Bodies must confirm Basic UDI-DI records and upload certificate data. They are processing requests from all their clients simultaneously. Priority goes to clients who initiated early.
• Consultant availability tightens. Regulatory consultants specializing in EUDAMED are booking out. Late movers face longer wait times and higher fees.
• EUDAMED help desk response times slow. The European Commission's EUDAMED help desk handles technical issues, account problems, and data questions. During peak periods, response times increase significantly.

How to Fix It

1. If you have not started, start this week. You are late, but you are not out of time. Prioritize actor registration first (Mistake 2), then Basic UDI-DI registration for your highest-risk devices, then bulk upload for the remaining portfolio.
2. If you have started but are stuck, identify the blocker immediately. Is it waiting on Competent Authority validation? Contact the Competent Authority. Is it waiting on Notified Body confirmation? Escalate with your NB. Is it a technical issue? Open a help desk ticket now, not next week.
3. Do not wait for perfection. A registered device with minor data imperfections is better than an unregistered device. You can amend data after registration. You cannot retroactively register a device that should have been registered before market placement.
4. Book test environment slots now if you need them. Do not wait until May to discover that all slots are taken.

---

Practical 30-Day Countdown Checklist

If your EUDAMED registration is not complete, here is a prioritized action plan for the final weeks before May 28, 2026:

Days 30-25: Actor Registration Sprint

• Confirm SRN status for all economic operators (manufacturer, AR, importers, SPPP producers)
• If SRN not yet issued: verify Competent Authority validation status; follow up if pending
• Verify at least two LAAs are assigned per actor record
• Confirm EU Login accounts are active for all EUDAMED users
• Confirm AR SRN is active and linked to your manufacturer record

Days 25-20: Data Preparation

• Complete the device grouping matrix (Basic UDI-DI assignments)
• Validate all EMDN codes against the official database (leaf level only)
• Cross-check risk classes against classification documentation
• Cross-check conformity assessment procedures against certificates
• Verify UDI-DI formats against issuing agency standards
• Prepare PRRC documentation for any missing actor records

Days 20-15: Notified Body Coordination

• Share your Basic UDI-DI list with your Notified Body
• Confirm that your NB has uploaded or plans to upload all relevant certificates
• Agree on a confirmation timeline for Basic UDI-DI records
• Identify any certificate data discrepancies between your records and NB records

Days 15-10: Upload and Verify

• Upload Basic UDI-DI records for highest-risk devices (Class III, Class IIb) first
• Upload associated UDI-DI records
• Monitor status: track which records are Draft, Submitted, or Registered
• Resolve any validation errors immediately
• Confirm that device descriptions match Declarations of Conformity

Days 10-5: Legacy Device Planning

• Complete the legacy device inventory (due November 27, 2026)
• Prepare XML bulk upload files for legacy devices
• Test XML files against the EUDAMED validation tool
• Confirm EUDAMED-DI assignment process for devices without Basic UDI-DI

Days 5-0: Final Verification

• Verify that all new devices intended for market placement after May 28 are registered
• Confirm all actor SRNs are active and valid
• Verify AR linkages for non-EU manufacturers
• Document the current state: what is registered, what is pending, what remains
• Brief senior management on compliance status and remaining risks

---

Recommended Reading

Coordinated Vulnerability Disclosure for Medical Devices: Building a Post-Market Cybersecurity Program

Cybersecurity Regulatory2026-04-30 · 11 min read

Data Quality Framework for EUDAMED

Sustaining data quality in EUDAMED is not a one-time effort. Devices change, certificates are renewed, and new products are launched. Here is a framework for ongoing data governance:

Data Ownership

Assign clear ownership for each data domain:

Data Domain	Owner	Update Trigger
Actor information (organization, PRRC)	Regulatory Affairs	Organizational changes, PRRC changes
Basic UDI-DI groupings	Regulatory Affairs	New device groups, reclassification
UDI-DI records	Regulatory Affairs / Product Management	New product variants, packaging changes
Certificate references	Regulatory Affairs (linked to NB)	Certificate issuance, renewal, withdrawal
EMDN codes	Regulatory Affairs	New device types, EMDN updates
Market placement data	Commercial Operations / Regulatory Affairs	Market entry or exit in member states

Validation Rules

Establish validation rules that are applied before every data submission:

1. Completeness check: All mandatory fields populated
2. Consistency check: Risk class matches conformity assessment; device description matches Declaration of Conformity
3. Format check: UDI-DI valid for the issuing agency; EMDN code is leaf level
4. Traceability check: Every data point traceable to source documentation
5. Currency check: Data reflects current state (not outdated certificates or superseded classifications)

Review Cadence

• Quarterly: Review all EUDAMED records for devices with active certificates. Verify that no certificates have expired without updating EUDAMED.
• Upon any change: Any change to a device's risk class, intended purpose, conformity assessment, or certificate status triggers an EUDAMED update review.
• Annually: Full portfolio audit. Verify that the number of registered devices matches your active product portfolio. Identify orphaned records, duplicate entries, and records that should have been deactivated.

---

The SWISSDAMED Parallel

If you market devices in Switzerland, you face a parallel registration requirement under the Swiss Therapeutic Products Act. Swissmedic operates SWISSDAMED, which follows a similar architecture to EUDAMED but with separate deadlines and actor identifiers.

Milestone	SWISSDAMED Date
Mandatory actor registration and new device registration	July 1, 2026
Legacy device registration deadline	December 31, 2026

Key differences from EUDAMED:

• Non-Swiss manufacturers must register through a Swiss Authorized Representative (CH-REP). The CH-REP must be established in Switzerland.
• The actor identifier is the CHRN (CH Registration Number), not the SRN. These are separate numbers issued by separate systems.
• The nomenclature requirements may differ. Verify Swiss-specific requirements directly with Swissmedic.
• The data model is closely aligned with EUDAMED, but it is not identical. Do not assume that EUDAMED data can be copied to SWISSDAMED without review.

If you operate in both the EU and Swiss markets, you are managing two concurrent registration projects with overlapping but not identical deadlines. Factor this into your resource planning.

---

Frequently Asked Questions

What happens if I miss the May 28, 2026 deadline?

After May 28, 2026, you cannot legally place new devices on the EU market without EUDAMED registration. Devices that are not registered, or devices placed by manufacturers without valid SRNs, are non-compliant. Competent Authorities can take enforcement action, including ordering the removal of non-compliant devices from the market. There is no grace period beyond the transition period that ends on May 28.

Do Class I devices (self-certified) also need EUDAMED registration?

Yes. All devices, regardless of risk class, must be registered in EUDAMED. For Class I devices under MDR (and Class A devices under IVDR), the manufacturer self-declares conformity and does not require Notified Body involvement. This means the Basic UDI-DI does not need NB confirmation — it moves directly from "Submitted" to "Registered" status. But the registration itself is mandatory.

Can I amend data after registration?

Yes, but amendments must be made within specific timeframes. Under MDR Article 29(4), the manufacturer must update device registration data without undue delay when changes occur. Amendments to Basic UDI-DI data that involve certificate changes require Notified Body confirmation. Plan your data entry carefully to minimize post-registration corrections.

How do I handle devices that are being discontinued before the legacy deadline?

If a legacy device will be permanently withdrawn from the EU market before November 27, 2026, and you do not intend to place it on the market again, you may not need to register it. However, you must maintain records demonstrating that the device was lawfully on the market during the transition period and that it was withdrawn before the registration deadline. Consult your Competent Authority for guidance on your specific situation.

What is the relationship between EUDAMED device registration and the UDI carrier on the label?

They are separate but related requirements. The UDI carrier (the barcode or human-readable identifier on the device label) must contain the UDI-DI and, where applicable, the UDI-PI. EUDAMED registration contains the data associated with that UDI-DI. If the UDI-DI on the label does not match a registered record in EUDAMED, the device is non-compliant. The label UDI and the EUDAMED record must be consistent.

Do importers need to do anything in EUDAMED beyond actor registration?

Yes. Importers must register as actors and obtain an SRN. After registration, importers must confirm in EUDAMED the devices they place on the market, per MDR Article 31. Importers also have obligations under the Market Surveillance Module when Competent Authorities conduct checks. Non-EU manufacturers should ensure their importers understand these obligations and have begun the registration process.