EUDAMED Registration Deadlines for Devices and Certificates in 2026

TL;DR

The first four EUDAMED modules became mandatory on 28 May 2026: Actor Registration, UDI/Device Registration, Notified Bodies and Certificates, and Market Surveillance. The last of these belongs to competent authorities and the European Commission, distinct from manufacturers' upload responsibilities. Manufacturers should now distinguish the work already required from the remaining transitional registration tasks. ¹

For qualifying devices whose first units were placed on the market before mandatory use and whose additional units continue to be placed on the market, the Commission's timeline identifies 28 November 2026 as the device-registration deadline. For qualifying MDR/IVDR certificates issued before mandatory use, the certificate-registration timeline identifies 28 May 2027. These are different obligations, with different owners and conditions. ^{2 3}

The certificate date has important event-specific exceptions. New certificates issued after mandatory use, and updates or decisions after that date concerning older Regulation certificates, must be registered under the mandatory regime. The older-certificate backlog provision is limited to Regulation devices that need to be, or already are, registered in the UDI/Device module. A single spreadsheet column labeled “EUDAMED deadline: May 2027” can therefore conceal work that is already due. ^{3 4}

For regulatory affairs and market-access teams, the immediate decision is to classify each device identifier and each certificate history into the right case. The output should be a reconciled list of registration duties, evidence, owners and unresolved dependencies—not an assumption that every public record must appear on the same date.

Use the legal trigger for each module

Commission Decision (EU) 2025/2371, dated 26 November 2025 and published in the Official Journal on 27 November, declared the relevant electronic systems functional. Regulation (EU) 2024/1860 had established the gradual-rollout framework and amended the transitional provisions. The Commission's current overview translates that trigger into mandatory use from 28 May 2026. Those official dates, rather than an old planning-quarter estimate, should drive the register. ^{5 6 1}

As checked on 11 October 2026, the overview still distinguishes the two remaining modules from the four already mandatory. Vigilance and post-market surveillance is described as in development; Clinical Investigations and Performance Studies is under analysis. The page says these remaining modules will be released at mandatory use, without a preceding voluntary-use period. Prepare for their rollout while distinguishing forecast milestones from the applicable Official Journal trigger. ¹

The underlying vigilance and clinical-investigation obligations continue through that transition. It concerns the electronic route and its staged implementation. The applicable interim or national processes remain a separate compliance question. Keep reporting obligations separate from the date a particular EUDAMED module becomes mandatory. The Commission's rollout Q&A discusses the transition between existing processes and the future vigilance module, including subsequent actions on reports begun before mandatory use. ⁴

The first useful management table therefore separates the event that triggers a duty from the date attached to one transitional population:

Source: Commission overview, device and certificate timelines, and rollout Q&A, particularly questions 7–11. The table is a management summary, not an exhaustive statement of all EUDAMED obligations. ^{1 2 3 4}

Classify devices by identifier and actual placement history

The rollout Q&A distinguishes individual sales units from a device registration. Registration in the UDI/Device module is at the device-identifier level, excluding production identifiers such as lot or serial numbers. One relevant identifier can cover multiple individual units placed on the market at different times. That is why both the first-unit history and continued placement of additional units matter. ⁴

For a Regulation device with a new UDI-DI whose first unit is placed on the market on or after 28 May 2026, the registration must precede that first placement. For a qualifying Regulation or legacy device whose first unit was placed before mandatory use and whose additional units are placed afterward, the transitional device-registration deadline is 28 November 2026. An entirely new device identifier remains subject to the pre-placement rule. ^{2 4}

The manufacturer's register should consequently not classify a whole product family by the age of its brand name. A long-established brand can include a new identifier with a different registration timing. Additional units under an existing qualifying identifier may use that identifier's record, subject to the applicable registration rules. The relevant record needs to connect the commercial model to the identifier used for registration.

The placing-on-market assessment must be substantive. MDR Article 2 defines placing on the market as the first making available of a device on the Union market; making available concerns supply for distribution, consumption or use in commercial activity, whether paid or free. A manufacturing date, border crossing or warehouse receipt supplies only part of the evidence needed for that legal assessment. Keep the supply-chain evidence and the rationale for the conclusion rather than automatically treating a customs date as the registration trigger. ⁷

A practical portfolio review can use three cases:

Illustrative cases based on Commission Q&A questions 7, 8 and 14; apply the actual facts for a manufacturer-specific determination. ⁴

The third case deserves care. A device still being used by patients can be different from a device for which additional units are still being placed on the market. The Q&A says qualifying legacy and Regulation devices no longer placed on the market at mandatory use need not be registered unless the specified post-market surveillance/vigilance situation arises. Retain the identifier mapping and the ability to support future vigilance action. ⁴

Distinguish legacy and Regulation identifiers

Legacy-device registration has its own identification logic. The Commission's current help documentation distinguishes EUDAMED DI, corresponding to the Basic UDI-DI identification level, from EUDAMED ID, corresponding to the UDI-DI level when no UDI-DI has been assigned. The latter can be generated from the former. It is inaccurate to describe EUDAMED ID as simply the substitute for a missing Basic UDI-DI. ⁸

This distinction matters when reconciling a legacy portfolio with later MDR or IVDR records. A spreadsheet should retain the actual identifiers and the documented relationship between the legacy and Regulation device, not overwrite one with the other. Otherwise, a public-search result or a certificate linkage can be interpreted against the wrong item.

The rollout Q&A says a legacy device need not be separately registered when the “same device” is already registered as a Regulation device, subject to the stated exceptions. It describes shared identification and characteristics and says a change requiring a new UDI-DI also makes the devices different for that purpose. The exception is therefore not established merely because two products have similar trade names. ⁴

Question 14 adds a relevant vigilance boundary: when the reportable action concerns the legacy device and not the same Regulation device, the legacy device may need exceptional registration and reference for that action. The Q&A distinguishes legacy devices from old devices and custom-made devices, excluding the latter two from the ordinary UDI/Device registration route. Preserve those separate categories in the backlog exercise. ⁴

For an operational register, record regulatory basis, identifier type, whether an equivalent Regulation record exists, the evidence supporting that equivalence and the person responsible for revisiting it. This is a proposed data-management structure. The record makes the manufacturer's reasoning auditable within the exception's existing legal conditions.

Separate certificate backlog from certificate events

The certificate timeline is the part most likely to be misread when a team is trying to reduce immediate workload. The 28 May 2027 date concerns registration of qualifying MDR/IVDR certificates issued before mandatory use of the Notified Bodies and Certificates module. The Q&A limits that population to Regulation devices that need to be, or are, registered in the UDI/Device module and specifies the latest certificate version and, where applicable, the latest notified-body decision related to it. ^{3 4}

For an older certificate, assess subsequent events separately from its original issue date. The same Q&A says updates and decisions issued after mandatory use concerning earlier Regulation certificates must be registered in the module. The Commission's one-page certificate timeline repeats this condition in a prominent note. New certificates issued from mandatory use are also within the mandatory registration regime. ^{3 4}

Consider a hypothetical certificate issued in February 2026 with no subsequent change. Its initial backlog registration needs to be assessed under the transitional rule. Now consider a July 2026 decision concerning that same certificate. Apply the July event's mandatory registration treatment, even though February remains the original issue date. The certificate history, not just its first date, changes the analysis.

A manufacturer should therefore obtain a current status reconciliation from its notified body: certificate identity and scope, current version, relevant decisions, applicable registration status and any missing linkage information. The notified body has the registration duty for certificate information; the manufacturer still needs sufficient coordination to identify dependencies and to avoid presenting an outdated certificate history in its own regulatory records.

The Q&A also says that once a certificate has been registered in the module, subsequent updates and decisions relating to it must be registered, including during the earlier voluntary period. Continue maintaining existing EUDAMED records according to the applicable rules. ⁴

This distinction is useful in project planning. Device-registration tasks can be assigned to the manufacturer's data owner. Certificate-event tasks need a notified-body interface. A single overall completion percentage can hide one of those dependencies. Track submitted required device data, certificate information and unresolved linkages separately, then reconcile them to the portfolio rather than allowing one successful upload to stand for the entire process.

Public visibility and summary documents need their own checks

A public search provides one useful observation; determining compliance requires the obligation's scope, the relevant dates and the actual submission state. The Commission Q&A states that submitting all required device information satisfies the manufacturer's device-registration obligation, while for certain devices the UDI and device data become publicly visible only after the notified body enters the corresponding product-certificate information. An absent public result can therefore require investigation without proving noncompliance by itself. ⁴

A review should ask what was submitted, whether the required information is complete, what status the system shows, and whether a certificate dependency affects visibility. A visible record also requires verification of its fields, with other regulatory obligations assessed separately. Keep the underlying submission evidence and the substantive conformity documentation, not only a screenshot of a search result.

The summaries also need correct scope. Under MDR Article 32, the summary of safety and clinical performance, SSCP, applies to implantable and class III devices other than custom-made or investigational devices. Under IVDR Article 29, the summary of safety and performance, SSP, applies to class C and D devices other than devices for performance studies. Applying the MDR class III/implantable test to IVDs would classify the wrong population. ^{7 9}

The manufacturer prepares the relevant summary, and the notified body validates and uploads it under the respective provisions. The rollout Q&A links the notified body's EUDAMED upload obligation to registration of the related certificate. This is a reason to coordinate the summary and certificate workstreams, not a reason to postpone preparing a document otherwise required for conformity assessment. ^{4 7 9}

The practical acceptance check is therefore broader than “PDF uploaded.” Confirm that the summary belongs to the correct device scope and version, has the required validation, and is associated with the relevant certificate process. Keep the distinct applicability rules for SSCP and SSP visible in filenames, metadata and work instructions, even if the overall project uses a generic “SS(C)P” label.

Build an October reconciliation that resolves real dependencies

The remaining work is best organized around evidence, not around copying three dates into a slide. Begin with the marketed portfolio and map each item to its Regulation or legacy status and registration identifier. Reconcile that list with the actual placement history, the records already submitted and the certificate histories held by the notified bodies. Missing information becomes an assigned question with a named owner, not an assumed exemption.

The following register is a proposed implementation aid:

This structure also clarifies the role of an authorised representative or consulting partner. MDR Article 11 separately governs the representative's written mandate and tasks. Manufacturer obligations remain subject to the Regulation even where data preparation or system entry is delegated. Scope the support precisely and retain a manufacturer-side reviewer for the accuracy and completeness of the information. ⁷

For Pure Global support, the useful starting packet is the device-identifier inventory, regulatory status, EU placement history, existing EUDAMED exports, certificate versions and open notified-body questions. A regulatory support discussion can then be scoped around defined gaps. Certification, authority acceptance and market access depend on requirements beyond completing a database task.

Budget the registration cleanup as its own work package. Portfolio size, identifier reconciliation, missing source data and certificate coordination affect the work required. This report addresses specific EUDAMED obligations. Initial authorization costs across countries and the scope of any remediation quote require a separate assessment, beyond an annual representation fee. Any commercial proposal should state the covered tasks and exclusions explicitly.

The conclusion for manufacturers and notified-body coordination

By October 2026, the useful question is no longer whether the first four modules will become mandatory. They already are. The question is which records fall within a remaining transitional population and which new events have triggered current obligations. The Commission's device and certificate timelines provide different deadlines because they describe different duties, not because one is a general extension of the other. ^{1 2 3}

Prioritize the qualifying device backlog for 28 November 2026, identify post-mandatory certificate events without waiting for the older-certificate deadline, and reconcile public visibility with the actual data and certificate state. Preserve evidence for exclusions and legacy-to-Regulation mappings. Those actions turn a deadline calendar into a defensible portfolio assessment while keeping responsibilities, conditions and remaining uncertainty visible.