What is the register of digital product passports and what do I need to enter in it?

What you must do concretely

What is expected of you

The register of digital product passports is a central European system in which specific data on each product passport is stored, regardless of where the passport itself is hosted. Article 13 of the ESPR (Regulation (EU) 2024/1781) describes this register, and Article 14 describes the web portal through which supervisory authorities and other parties can access that data. The passport itself remains hosted by the manufacturer or importer — or, in the case of texpas.eu, by us as the hosting provider — but a portion of the identifying data is also sent to the register.

Registration of basic data per product

For each product for which a digital product passport is mandatory, a set of data is registered: including the unique product identification code and references to where the passport can be found. For a company with 10 to 100 employees, this means that registration is not separate from the way products are identified. A product without unique product identification code cannot be correctly entered in the register, so that identification is a prerequisite that must be in order earlier in the process.

Ensuring that registration data remains current

The register is not a snapshot at the time a product is launched. As long as the passport exists, the data in the register should correspond to reality: which passport belongs to which product, and where that passport can be consulted. For a company, this means that changes — a different hosting provider, an adjusted location of the passport, or discontinuation of a product line — also have consequences for what is recorded in the register. This directly touches on the question how long a product passport must remain available, because a registration that no longer matches practice is in itself already a problem, separate from the question of whether the passport is still accessible.

Ensuring that the passport is findable via the web portal

Article 14 of the ESPR describes a web portal through which data from product passports can be accessed. For a company, this means that the passport must not only be accessible via the QR code on the product itself, but that the underlying data is also made available in a way that aligns with what this portal expects. This is a different perspective from the question how the QR code gets onto the product: the QR code is access for the consumer in the store, the register and the portal are access for supervisory authorities and for the market as a whole.

Consistency between registration and the data in the passport itself

What is recorded in the register should logically align with what is to be read in the passport itself. A product code that is written differently in the register than in the passport, or a passport URL that no longer works, creates a mismatch that a supervisory authority will notice as soon as they access the portal. For companies working with multiple systems — an ERP package for inventory, a separate system for product data — this is a point where alignment is required, something that also comes up in the question of whether the product passport can be linked to an existing ERP or inventory system.

Where things go wrong in practice

A common situation is that a company changes the identification code of a product at a later date — for example during an internal cleanup of article numbers — without this change being made in the registration data. The result is that the passport still exists and is accurate in practice, but can no longer be found via the data recorded in the register.

A second situation occurs when switching to a different hosting provider for the product passport. The content of the passport moves with it, but the location where it can be found changes. If the registration data is not updated accordingly, the register points to an address that no longer exists.

A third situation arises with variants within a collection. When a company assumes that one registration is sufficient for an entire product line, while each size and colour actually requires its own passport, part of the registrations that should have been made is missing.

A fourth situation is an error discovered only after publication — an incorrectly entered identification code, or a passport linked to the wrong product. Companies often then wonder whether adjustment is still possible and whether that also needs to be updated in the registration; this is related to the question whether an error in a published passport can still be corrected.

A fifth situation occurs with business closure or acquisition. A product passport and its associated registration are not automatically linked to the continued existence of the company that created them, and confusion about this often only arises when the question becomes relevant, whilst this subject relates to what is described about what happens to the product passport when a company stops operating.

What you can record

• An overview of which identification code belongs to which product and which variant, including the moment at which these codes were created or modified.
• An internal process that establishes who is responsible for implementing changes to the registration data, whenever a product, a hosting location or a business structure changes.
• A log of amendments to published passports, with date and reason for the amendment.
• Agreements with the hosting party of the passport regarding who keeps the registration data current, and within what process that happens.
• An overview of products with multiple passports, where applicable, so that it is clear which registration belongs to which passport — relevant when a product requires multiple passports that complement each other.