Search every question across sub-FAQs

Do not assume the registry is a public passport page, a compliance certificate, or a complete product-data store. ESPR makes the registry a secure identifier record, while the passport itself remains distributed across economic operators and service providers.

Do not assume the registry will expose every passport field. The regulation requires a secure registry for at least unique identifiers and, in customs cases, commodity codes, while any additional stored data must come from the delegated acts and the criteria set 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 in the grounded sources for this page. ESPR creates the framework, requires the Commission to prioritise product groups in a working plan, and makes product-specific passport obligations depend on delegated acts adopted for the product group.

ESPR Article 18 sets the first working-plan priority list. The listed groups are iron and steel; aluminium; textiles, especially garments and footwear; furniture, including mattresses; tyres; detergents; paints; lubricants; chemicals; relevant energy-related products; and information and communication technology products and other electronics.

That list is useful for sequencing preparation because it tells product, sustainability, supply-chain, and data teams where to watch first. It does not answer the operational DPP questions by itself: what data must be in the passport, where the carrier sits, who gets which access rights, what conformity route applies, and when the product-specific requirements apply.

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.

That is why a company should avoid treating a priority category, a consultation, or a technical standard as the final compliance rule. They can justify early architecture work, but the delegated act is the source to check before locking product labels, QR placement, access tiers, registry fields, or contractual supplier data duties.

For batteries, build against the grounded 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 that operator to make available a back-up copy of the DPP through a DPP service provider, and Article 13 requires that operator to upload the required registry data.

That does not mean every operator in the chain may freely decide who creates or updates the passport. Article 9 says the delegated act for the product group must specify the actors that create the DPP or update passport data, what data they may introduce or update, and the detailed 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.

Do not publish a fixed DPP responsibility answer for every product line before the product-specific delegated act exists. Instead, keep a product-group watchlist and convert it into binding owners once the delegated act defines the product scope, passport level, data content, access rights, creation and update actors, registry data, and application details.