← Back to insights

A Medical-Device Team Needs EUDAMED Registration: Which Data Handoff Must Be Fixed First?

Route an EUDAMED onboarding request by the failed actor, UDI/device or notified-body certificate object instead of selling one generic registration package.

An EUDAMED request routes to the actor, UDI/device or notified-body certificate object that failed
#EUDAMED#UDI#Medical Devices#Registration Data

Signals to watch

  • A named economic operator or device has a mandatory-module task after 28 May 2026
  • The failure is located in actor registration, UDI/device registration or a notified-body certificate relationship
  • A market placement, submission, certificate or customer decision has an owner and date

“EUDAMED registration” is not one record. Fix actor registration first when the legal operator or Single Registration Number is wrong; fix UDI/device registration when the product identity or model relationships fail; fix the certificate handoff when notified-body records do not support the device relationship. The service request is ready when one object, owner, module response and dated output are named.

This matters to a medical-device data-services BD lead reviewing authorized regulatory-affairs, manufacturer and distributor Telegram groups. The useful Signal is a blocked mandatory-module task, not any mention of EUDAMED. Seeing it a day late can miss a submission or market-placement review. Sending every request to “device registration” can bury an actor or certificate defect under another data upload.

The following is an illustrative composite, not a real manufacturer, device or submission:

“EUDAMED is mandatory now. UDI upload rejects our device because the manufacturer record doesn’t match. Certificate is visible to the notified body.”

The fragment leaves unknown the economic-operator role, SRN, Basic UDI-DI, UDI-DI, device class, regulation, notified body, certificate identifier, module response, legacy status, competent authority and sender authority.

Start with the module status that is true in 2026

The European Commission’s EUDAMED overview says the first four modules became mandatory on 28 May 2026:

  • Actor Registration;
  • UDI/Device Registration;
  • Notified Bodies and Certificates; and
  • Market Surveillance, for competent authorities and the Commission.

EUDAMED has six interconnected modules. The same overview lists Clinical Investigations and Performance Studies as under analysis, and Vigilance and Post-Market Surveillance as in development. Do not turn “first four mandatory” into “all six complete.”

Regulation (EU) 2024/1860 enabled completed modules to become mandatory after a functionality notice and transition period instead of waiting for the whole database. The Commission records that Decision (EU) 2025/2371 was published on 27 November 2025, triggering the six-month transition to 28 May 2026.

Handoff one: the actor record establishes who is acting

Actor Registration covers economic operators such as manufacturers, authorised representatives, importers and system/procedure-pack producers under the applicable medical-device rules. SRN means Single Registration Number, the identifier issued through the actor-registration process after validation by the relevant national competent authority.

Check the legal name, address, operator role, authorised-representative relationship where relevant, responsible-person information and SRN. Then compare the actor identifier used in the device record. A spelling difference is not always cosmetic: it may show that a local account, corporate entity and registered actor have been mixed.

If the authority has not validated an actor or the wrong entity owns the record, a device-data consultant cannot bypass that step. Route the task to the actor owner and competent-authority process before remapping product data.

Handoff two: the UDI/device record establishes product identity

UDI means Unique Device Identification. A Basic UDI-DI groups devices at the model or family level for regulatory purposes and is not placed on the product label. A UDI-DI identifies a specific device or packaging level and is part of the UDI carrier and database record.

The device record needs the correct responsible actor, Basic UDI-DI relationship, UDI-DI, nomenclature, risk class, status and other required attributes under the applicable Medical Devices Regulation or In Vitro Diagnostic Medical Devices Regulation.

A valid UDI format does not prove that the device belongs under the selected Basic UDI-DI or actor. Preserve the exact module message and compare the relationship, not just the identifier string.

For example, if the upload says the manufacturer does not match, check whether the device record references the manufacturer’s SRN expected for that regulatory role. Do not create a second actor record simply to make an upload pass.

Handoff three: the certificate record belongs to the notified-body route

For devices requiring notified-body involvement, the Notified Bodies and Certificates module contains certificate information and its relationships. The notified body owns its certificate actions; the manufacturer owns its product and device data. One party seeing a certificate does not prove that the other party used the same identifier or relationship.

Record the notified body, certificate type and number, status, covered device or Basic UDI-DI relationship, dates and any module message. If the certificate is absent or incorrectly linked, decide whether the owner is the notified body, manufacturer data team or an authority—not whichever consultant received the screenshot.

Build one onboarding packet, not one giant spreadsheet

The packet for the failed object should include:

  1. applicable regulation and operator role;
  2. legal actor identifiers and SRN status;
  3. Basic UDI-DI, UDI-DI and device/packaging level;
  4. certificate and notified-body relationship where applicable;
  5. exact EUDAMED module, environment, record ID and response;
  6. current owner and authority dependency; and
  7. required output and date.

Separate public device information from restricted account records and personal data. Do not paste credentials, personal contact details or confidential technical documentation into group chat.

Completion is observable: the correct actor owns the device record, the intended Basic UDI-DI and UDI-DI relationship validates, and any applicable certificate reference resolves to the right object. This does not certify that the device complies or may be placed on the market; those conclusions remain with the responsible economic operator, notified body and authorities.

A successful module action is not a market-access decision

EUDAMED records support transparency and traceability, but a green module status answers only the database question tested. It does not replace device classification, conformity assessment, clinical evidence, labelling, post-market duties or the national handling of a particular legacy or transitional situation.

Keep two outputs in the onboarding record. The database output says which object was created or corrected, which relationship validated and when. The regulatory decision says who concluded that the device can proceed to the next business or conformity step and on what evidence. The data provider may deliver the first while the manufacturer, notified body or competent authority owns the second.

This separation also prevents a supplier from promising “EUDAMED compliance” after one upload. A more accurate delivery statement is: “Actor and device records were submitted successfully in the mandatory modules; certificate linkage and the manufacturer’s market-placement decision remain with their named owners.”

The medical-device testing demand article covers laboratory and certification timing, not EUDAMED data. For an unlinked regulatory screenshot, use the official-source ladder. The European Accessibility Act supplier article is a separate product-requirement route.

TOP Prospect can connect incomplete fragments from groups the user deliberately connects and may access, preserve source and time, remove obvious duplicates and rank the request for review. It cannot access an EUDAMED account, create an SRN, register a device, alter a certificate, determine regulatory scope or contact the writer. The pricing page describes the discovery workflow.

The original message becomes a scoped onboarding request when “manufacturer record doesn’t match” is replaced by the actor SRN, device record, failed relationship, exact module response and the owner of the next submission.

Frequently asked questions

Which EUDAMED modules became mandatory on 28 May 2026?

The Commission lists Actor Registration, UDI/Device Registration, Notified Bodies and Certificates, and Market Surveillance. Market Surveillance is mandatory for competent authorities and the Commission.

Are all six EUDAMED modules mandatory in August 2026?

No. The Commission overview says Clinical Investigations and Performance Studies is under analysis, while Vigilance and Post-Market Surveillance is in development.

Does an SRN complete device registration?

No. An SRN identifies a registered actor after the applicable authority process. UDI/device records and certificate relationships are separate objects and can still be incomplete.

What should an onboarding provider request first?

Ask for the operator role and identifiers, device and Basic UDI-DI/UDI-DI information, applicable certificate or notified-body relationship, exact module response, authority context and the dated output the team must complete.

Sources and further reading

RESEARCH & DEFINITIONS

How a Signal worth attention is found

See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.

Open the methodology and core definitions

START WITH ONE MONITORED GROUP

Try the workflow free for seven days.

Open the product, connect one authorized group, and describe the Signal you want to find. If you need help choosing the scope, ask us on Telegram.

Back to homepage