The EU Digital Product Passport Registry became operational on 20 July 2026. It indexes required passports and their registration metadata; it does not make every product subject to a DPP today.
The European Commission made the Digital Product Passport Registry operational and opened an accompanying testing environment. This completes the central Registry infrastructure required by ESPR Article 13. It is an important implementation milestone, but it is not a universal DPP deadline: product-level duties still arise from the relevant delegated act or other EU product legislation.
The Registry is the EU indexing and registration layer for Digital Product Passports. It stores unique identifiers, registration data, high-level metadata, and—where relevant—the commodity code used for release for free circulation. The full detailed passport remains decentralised under the responsibility of the economic operator or a service provider acting for it. A Registry record and a product passport are therefore connected but different technical objects.
No. Implementing Regulation (EU) 2026/1778 governs products that are already required by applicable Union law to have a DPP and register it. Article 1 covers products under future ESPR delegated acts as well as scoped batteries, construction products, toys, detergents and end-user surfactants, and any later EU legislation using the same Registry. The Registry being live does not activate a missing product-specific obligation.
The responsible economic operator registers the DPP, or authorises a verified third party to perform the action on its behalf. Delegating the technical task does not transfer legal responsibility: Article 19 of the implementing regulation keeps the verified economic operator responsible for the accuracy, completeness, currency, and security of the information it submits. Procurement contracts should reflect that boundary clearly.
At minimum, an operator needs a verified organisation account, the unique product identifier, the passport URL and data carrier relationship, the level of granularity required by the applicable law, and any required customs commodity code. Item-level passports also register corresponding batch and model identifiers where those levels exist; batch-level passports register the model identifier. Handmade or inherently unique products are treated differently where no model or batch design exists.
The Registry provides a secure user interface and an API. That supports both manual registration and integration from PIM, ERP, traceability, or DPP platforms. The regulation also provides a semantic repository for authoritative data models, structures, definitions, and versioning. Software buyers should ask whether an integration uses the documented Registry contract, how it handles schema versions, and how registration failures are reconciled.
A verified operator can generate a secure electronic proof of registration through the UI or API. Under Article 9 of Regulation (EU) 2026/1778, that document can evidence that the registration obligation was fulfilled and contains the product identifier, operator identity, timestamp, and a hash of the passport version. It does not prove that the underlying product or passport complies with every substantive requirement. ESPR Article 13 makes the same distinction for the unique registration identifier.
Registration is not a one-time upload that can be forgotten. The verified operator must keep Registry information accurate, complete, and current. Changes, deletions, transfers, and other registration events are logged. Teams therefore need an operating trigger for product changes, identifier changes, organisational transfers, withdrawals, and passport-version updates, with evidence of who approved each action.
Commission Implementing Decision (EU) 2026/1736 published references to six harmonised DPP standards covering areas such as unique identifiers, data carriers, interoperability, APIs, data exchange protocols, and data storage. Conformity with the referenced harmonised parts can support a presumption of conformity for the ESPR requirements they cover. It does not settle the product-specific data fields or deadline.
The applicable product rule still determines whether a DPP is required, the effective date, the model/batch/item level, required data, carrier placement, access rights, and passport availability period. Batteries already have an adopted 18 February 2027 date for scoped batteries. Most ESPR priority products still await delegated acts. Registry readiness should therefore be run beside—not instead of—category monitoring.
Use the testing environment to validate account ownership, identifier mappings, registration granularity, API authentication, error handling, and proof-of-registration retention. Keep test records out of production workflows, document which product law triggers each registration, and retain an export path independent of any one DPP vendor. The useful output is a repeatable controlled process, not a screenshot showing that a QR code resolves.
CATEGORY DISPATCH
Updates cover official changes, category timing, source updates, and vendor-claim notes. No legal advice, no spam.