Search every question across sub-FAQs

Keep evidence that proves the access decision for each data field. A visitor, auditor, authority, supplier, repairer, or customs broker should be able to see why a field was public, restricted, authority-only, customs-relevant, or excluded from publication.

The evidence should also show who can change passport data. Read access for a recycler, repairer, authority, or customer does not automatically mean write access.

The Registry is the central EU register for DPP identifier data and associated mandatory metadata. Article 13 requires it to store at least unique identifiers; for products intended for release for free circulation, it also stores the commodity code. Applicable legal acts can require additional registration data.

The Registry is not the public product passport page or a complete product-data repository. The economic operator or a DPP service provider stores the complete passport, while the Registry supports registration, authentication, authority access, and future automated customs checks.

The economic operator placing the product on the market or putting it into service uploads the data required for the registry. Once that data is uploaded, the registry automatically communicates a unique registration identifier associated with the unique identifiers uploaded for that product.

The Commission also says an economic operator can request proof of registration as a secure electronic document. That document evidences registration; ESPR separately says the Registry's identifier communication is not proof of compliance with ESPR or other Union law.

For products intended to be placed under the customs procedure for release for free circulation, customs authorities verify at minimum that the unique registration identifier and the commodity code correspond to the registry data. The verification is electronic and automatic once the registry-to-customs interconnection is operational.

The Registry is live, but the EU CSW-CERTEX interconnection has its own timetable: ESPR requires it to become operational within four years after the Registry implementing act enters into force. Until the interconnection is operational, do not describe automatic DPP customs matching as live. A later successful customs release will still not prove compliance with ESPR or other Union law.

The Registry is a secure identifier and metadata record. It is neither the public passport page nor a complete product-data store, and its identifier communication does not prove compliance. The passport itself remains distributed across economic operators and service providers.

The Registry does not expose every passport field. It stores at least unique identifiers and, in customs cases, commodity codes. Delegated acts can specify additional stored data under the criteria in Article 13.

For binding passport planning, separate the battery passport from the ESPR Digital Product Passport. The Batteries Regulation says that from 18 February 2027 each LMT battery, each industrial battery with a capacity greater than 2 kWh, and each electric vehicle battery placed on the market or put into service must have an electronic battery passport.

For ESPR product groups, there is no single universal DPP start date. The adopted working plan gives indicative years for adopting measures. After an ESPR delegated act is adopted, economic operators normally receive at least 18 months before its requirements apply, subject to the act's stated transition.

The adopted 2025-2030 working plan selects textiles and apparel, furniture, tyres, mattresses, iron and steel, and aluminium for new product work. It also includes horizontal work on repairability and on recycled content and recyclability of electrical and electronic equipment, plus carried-over measures for specified energy-related products.

Its indicative adoption sequence is iron and steel in 2026; textiles and apparel, tyres, aluminium, and repairability in 2027; furniture in 2028; and mattresses plus the electrical and electronic equipment horizontal measure in 2029. These are dates for planned adoption of measures, not product compliance dates.

Under ESPR, the delegated act is where the general framework becomes product-specific. ESPR Article 9 says products can be placed on the market or put into service only if a digital product passport is available in accordance with the applicable delegated acts, and Article 9 also says those acts specify which data must be included, the data carriers to be used, and how the carrier is presented and positioned.

A priority category, consultation, or technical standard can support early architecture work but does not create the final product duty. Check the delegated act before locking product labels, carrier placement, access tiers, registry fields, or contractual supplier-data duties.

For batteries, use the Batteries Regulation passport scope if the business places covered LMT, industrial greater-than-2 kWh, or electric vehicle batteries on the EU market or puts them into service. That work should include the battery category decision, the responsible economic operator, QR-code access, and the information set in Annex XIII.

For ESPR products, prepare the parts that are unlikely to be wasted: product-group mapping, supplier data ownership, identifier strategy, data-quality controls, and change monitoring. Hold back from asserting final product-group passport dates, mandatory fields, or carrier layout until the delegated act for that group exists and has been reviewed.

For an ESPR product covered by a delegated act, start with the economic operator that places the product on the EU market or puts it into service. ESPR Article 10 requires the operator placing the product on the market to make available a back-up copy of the DPP through a DPP service provider. Article 13 requires the operator placing the product on the market or putting it into service to upload the required registry data.

For manufacturers, Article 27 adds a direct duty to ensure that a DPP and its current back-up copy are available for covered products. Article 9 then requires the product-group delegated act to specify the actors that create the DPP or update passport data, what they may change, and the arrangements for doing so.

The manufacturer obligation is the strongest anchor in ESPR. For covered products, Article 27 requires manufacturers to ensure the product is accompanied by required information and that a DPP is available, including a back-up copy of the most up-to-date passport version stored by a DPP service provider.

Importers and distributors are not passive. Before placing a covered product on the market, importers must ensure that the manufacturer has handled conformity assessment, required information, and DPP availability. Before making the product available, distributors must verify that the product is labelled or linked to a DPP where the delegated act requires it, and they must stop making it available if the product or manufacturer is not compliant.

Suppliers are usually data contributors, not the default public owner of the final-product passport. ESPR Article 38 says that, when the delegated act specifies it, supply-chain actors must provide relevant information free of charge to manufacturers, notified bodies, and competent national authorities, allow manufacturer assessment when information is absent, and enable verification of information related to their activities.

DPP service providers are different from suppliers. They may store or process passport data for the economic operator, but ESPR Article 11 limits their processing to what is necessary for the service unless specifically agreed with the operator placing the product on the market or putting it into service.

A useful DPP responsibility record should identify the legal trigger, the product group, the market-placement actor, the delegated-act rule, and the teams allowed to create or update passport data. It should also show how supplier data is requested, checked, corrected, and locked before publication.

Before the product-specific delegated act exists, keep a product-group watchlist rather than assigning unsupported legal roles. Once the act defines product scope, passport level, data content, access rights, creation and update actors, registry data, and application details, turn those rules into named internal owners.