On 29 April 2026 the European Commission published the draft implementing regulation for the Digital Product Passport register (Ares(2026)4424976). It gives concrete shape to Article 13(5) of the ESPR (Reg. 2024/1781) and sets out how the register operated by the Commission will work technically and organisationally.
The text is marked as a draft and has not yet been adopted. The essential mechanisms are already clearly recognisable, however - and they have immediate consequences for every manufacturer that has to issue a DPP from 2027.
What the register is - and what it is not
One clarification up front: the EU register does not store the DPP data itself. It is a central directory service that holds, for each registration, a unique ID, the commodity code, the identity of the economic operator, a hash of the DPP version and a reference to the back-up copy held by the DPP service provider.
Recital 3 calls this a “decentralised model”: the product data continues to live with the manufacturer or with its DPP platform. The register is the canonical address list, not a data silo.
Functionally, the register consists of:
- a web interface and an API for registrations
- a verification platform for economic operators
- a list of the authorised DPP service providers
- a semantic repository (multilingual, DCAT-AP structured) as a reference for data attributes, model structures and roles
- a logging system with staggered retention periods
Verification before registration
No DPP is created in the register before the submitting economic operator is recorded as a verified economic operator (Art. 4). Verification takes place directly with the register and uses the eIDAS means from Reg. 910/2014:
- Legal person in the EU: qualified electronic seal or electronic attestation of attributes
- Natural person as a sole trader in the EU: qualified electronic signature, eID level “high”, or attestation of attributes
- Operators outside the EU: qualified signature or seal or attestation of attributes
The verification is valid for a maximum of three years. Anyone who does not renew is set to “unverified” and loses the right to register new DPPs or change existing ones (Art. 4(4)).
This verification is the legal precondition. It sits between the manufacturer and the Commission - and it is not delegated even when a service provider such as Transpareo takes over the operational registration.
Granularity: model, batch or item
Article 8 requires DPPs to be registered at the granularity level specified by the relevant sector act - model, batch or item. Where an item DPP is created and batch or model IDs exist, they must be carried along. For batch DPPs the same applies to model IDs.
For manufacturers this means: the internal master data needs a clean hierarchy between model, batch and individual product. Without this linkage the automatic validation of the registration fails.
Versioning, hash and retention
Every DPP version is linked to the original registration ID. With every change the register requires a hash of the current DPP version - cryptographically verifiable, not produced manually.
The proof of registration (Art. 9) is an electronic document that the Commission seals in qualified form and timestamps. Content at minimum: registration ID, commodity code, operator identity, date and hash of the latest version. Valid for 90 days, regenerable at will.
Standard retention: 10 years from registration, unless Union law or sector law specifies another period (Art. 10(3) of the DPP register implementing regulation). Even insolvency or liquidation of the manufacturer does not release them from the availability obligation (ESPR Art. 11(e)).
Logging system
The register logs at three levels (Art. 14):
- Access and authentications: 6 months
- Data changes: duration of the registration
- Administrative actions and data exchange: 5 years
National authorities are granted access in the event of incidents, audits or spot checks.
Personal data - what the Commission stores
Article 18 lists which data sits exclusively with the register: the first and last name of every user, login credentials, auth tokens, postal address, email. For natural persons additionally passport or ID-card number, eID, tax ID. This data is none of the DPP service provider’s business. The Commission is the controller of this account data, the economic operator remains the controller of its DPP data.
How Transpareo maps the requirements
Most of the requirements touch architectural decisions that Transpareo already makes in this form. In detail:
Decentralised model. Transpareo is a multi-tenant platform with an isolated database per customer. The DPP data lives in the database of the economic operator, not in a central pool - exactly the architecture that Recital 3 assumes.
Processor role cleanly delineated. Articles 19(5) and 20(3) provide that the economic operator remains the controller, even when it commissions a third party with the registration. Transpareo already works today as a processor with a data processing agreement - the roles are clear.
Stable back-up URL per DPP. Every Transpareo DPP is reachable via a permanent URL that does not change even across version changes. This is exactly what Art. 8(6)(d) requires as a “link to the back-up hosted by a DPP-SP”.
Granularity. The Transpareo data model distinguishes between product model, batch and individual product and allows links along the hierarchy - the precondition for meeting Article 8(3)/(4).
Multilingual semantic mapping. The Commission’s repository is multilingual following DCAT-AP. Transpareo carries every data point in 39 languages, including all 24 official EU languages, with translation as part of the plan.
Version hash. Deterministic serialisation following the JSON Canonicalization Scheme (RFC 8785) and a SHA-256 hash per DPP version are already shipped. The only open point is the exact hash-pinning format of the EU register; as soon as the Commission publishes it, we map it in addition.
Listing as a DPP service provider. Transpareo will apply for the official list of DPP service providers (Art. 2 No. 32 of the ESPR) as soon as the admission procedure is published.
Registration on behalf. We are preparing the service to take over the registration on behalf of authorised customers - the customer’s legal responsibility remains unaffected by this under Art. 19(4).
Timeline
Entry into force is governed by Article 23: 20 days after publication in the Official Journal. Which day that will be depends on when the Commission adopts the final version. The parent mandate from Article 13(5) of the ESPR is dated 19 July 2026 - by then the register must be in place.
The register is expected to become noticeably productive only with 18 February 2027: on that day Article 77 of the EU Batteries Regulation 2023/1542 takes effect, and the DPP becomes mandatory for industrial, EV and LMT batteries above 2 kWh. We have written down the details and the open implementing-act questions in the ESPR timeline 2027. Until then around nine months remain. Anyone budgeting time for supplier contracts, master-data migration and internal approvals knows: that is tight, not ample.
What remains open
The regulation itself describes the organisational framework. What is missing is the technical specification of the API - the exact interface format, the schemas, the validation rules. This is expected to follow as a separate Commission guideline under Art. 15(1), probably still in the course of 2026.
Until then the direction is unambiguous, however: decentralised architecture, verified operators, qualified signatures, unique registration IDs, version chaining, semantic interoperability. All concepts that will not go away again.
The Commission’s official consultation initiative is available on Have Your Say.