EU Digital Product Passport registry and web portal integration

Article 13 of Regulation (EU) 2024/1781 requires a Commission registry that stores at least unique identifiers. For products intended for release for free circulation, it also stores the commodity code. The Registry became operational on 20 July 2026. Commission Implementing Regulation (EU) 2026/1778, which enters into force on 6 August 2026, sets its practical arrangements, including access management, user verification, data registration, storage, and technical architecture.

After upload, the registry returns a unique registration identifier associated with the uploaded identifiers for the specific product. ESPR is explicit that this communication is not proof of compliance with ESPR or other Union law, so implementation records should not treat registration as a substitute for conformity assessment, technical documentation, or product-group passport content.

For the general ESPR registration route, a verified economic operator may register a DPP or correct an existing registration. A verified value-chain actor may perform Registry actions only where the applicable Union law permits that role. Under Implementing Regulation (EU) 2026/1778, from 6 August 2026 verified status ends when the actor's electronic identification means expire and in any event after three years; the actor must repeat verification before it can register or modify data again.

Keep a registry payload map next to the DPP data model: the identifiers and metadata required by the applicable law, the commodity code for release-for-free-circulation cases, and the returned registration identifier. Keep the full passport in the decentralised passport system unless the applicable delegated act or other Union legislation requires additional registry data. Do not assume that every Annex III field belongs in the registry.

Register at the granularity required by the applicable law. For an item-level DPP, also link the corresponding batch and model identifiers when those designs exist; for a batch-level DPP, link the model identifier when a model design exists. Unique-by-nature products such as handmade goods do not need nonexistent batch or model identifiers. If several Union laws require different levels for the same product, register at the most granular level.

A DPP integration should start with the identifier level that the applicable delegated act requires: product model, batch, or item. ESPR requires passport data to refer to the product model, batch, or item specified in the delegated act, and Annex III lists data elements that can include the unique product identifier, GTIN or equivalent identifiers, commodity codes, compliance documentation, operator identifiers, facility identifiers, and the reference to the DPP service provider hosting the backup copy.

The data carrier is the physical entry point. ESPR requires it to be physically present on the product, packaging, or accompanying documentation as specified in the delegated act. CEN-CENELEC guidance describes common options such as QR codes, DataMatrix, NFC, RAIN RFID, and BLE, while ETSI notes that online information is commonly reached through a web link obtained from a data carrier.

For resolver design, use the data carrier to resolve to the passport record or a controlled landing endpoint, then route by identifier, actor credentials, language, market, and access category. The resolver should be stable for the expected product life and should not depend on a single campaign URL or CMS page that may be retired before repairers, recyclers, customs authorities, or customers need it.

ESPR does not make every passport field public. Article 11 requires free and easy access based on the access rights set in the applicable delegated act for customers, manufacturers, importers, distributors, dealers, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, trade unions, and other relevant actors.

The Commission web portal required by Article 14 is a publicly accessible search-and-comparison layer for DPP data, but search results must follow the access rights in the applicable delegated act. Do not confuse that statutory portal with the Commission's July 2026 DPP information website or with an operator's own public passport page.

CEN-CENELEC guidance aligns with this split: public data should be available without requiring logins or personal data collection, while restricted data can be controlled through software roles, login, or other authentication. Avoid using customer personal data as a portal shortcut; ESPR states that customer personal data must not be stored in the DPP without explicit GDPR-compliant consent.

ESPR requires the economic operator placing the product on the market to make a backup copy of the DPP available through an independent third-party DPP service provider. It also allows the passport to be stored by the responsible economic operator or by DPP service providers.

A provider contract should identify the backup-copy scope, data retention period from the delegated act, recovery obligations after insolvency or cessation of activity, data export format, authentication responsibilities, security controls, incident handling, and limits on selling, reusing, or processing passport data. ESPR permits processing beyond what the service needs only when the economic operator specifically agrees.

Because the Commission may adopt provider requirements, certification rules, and digital-credential procedures, procurement should keep these obligations adaptable. Avoid locking the passport into a vendor-only identifier, proprietary resolver, or data model that cannot be moved into an open interoperable exchange network.

Review this checklist before committing to a DPP platform, public portal pattern, or product-label data carrier. Registry mechanics now have official implementation rules and a live environment. Product-group field lists, access rights, application dates, and the Article 14 search-and-comparison portal still require separate tracking.

Link each public claim and technical decision to a product group, delegated-act requirement, identifier scheme, data-carrier test, resolver result, access-control rule, provider contract, and registry upload status.