EU Ecodesign for Sustainable Products Regulation DPP obligations FAQ
ESPR creates the framework for Digital Product Passports, but product-specific delegated acts decide the operative passport requirements for each covered product group.
This FAQ helps separate settled ESPR framework duties from fields, dates, and procedures that still depend on product rules, standards, or service-provider requirements. For products covered by an applicable delegated act, manufacturers must ensure that the passport is available; importers, distributors, and dealers have distinct verification and access duties.
obligations under ESPR should be read as a framework plus delegated-act dependency. ESPR already defines core passport concepts, carriers, identifiers, access rights, registry and web-portal mechanics, but the data set, passport level, access model, update rights, and availability period are specified for each product group through delegated acts. For a product covered by an applicable delegated act, the manufacturer must ensure that the passport is available, including the required back-up copy. Importers verify availability, distributors verify the required link where relevant, and dealers ensure customer access as specified in the applicable act.
Search this module
Find a question or answer quickly
6 of 6 questions
Question 1
Does ESPR already require a Digital Product Passport for every product?
No. ESPR sets a horizontal framework. Article 9 says information requirements shall provide that products can be placed on the market or put into service only if a is available in accordance with the applicable delegated act and Articles 10 and 11.
The operative obligation depends on the product rule. First identify whether an ESPR delegated act covers the product group, then read that act for the required data, carrier, passport level, access rights, update rights, and availability period.
Do not publish a universal ESPR DPP field list for all products.
Do not assume a passport is required until the relevant product group rule says so.
Track the Commission working-plan and delegated-act process for products your business places on the EU market.
Prepare data governance now, but label unfinalised product fields as delegated-act dependent.
Commission consultation page confirms DPP system development questions for storage, service providers, and possible certification.
future Digital Product Passport
Question 2
What will the product-specific delegated act decide?
The delegated act is where ESPR turns the passport framework into product-group instructions. Article 9 requires delegated acts to specify the passport data, , carrier layout and position, whether the passport is at model, batch or item level, customer pre-contract access, stakeholder access rights, who may create or update data, update arrangements, and how long the passport remains available.
Annex III lists candidate data categories, including the , commodity codes, compliance documentation, user manuals or warnings, manufacturer and importer information, operator and facility identifiers, and the DPP service provider hosting the back-up copy. It does not mean every listed element is mandatory for every product.
Map each proposed field to the product-specific delegated act before treating it as required.
Record whether the product passport level is model, batch, or item.
Separate public information from restricted information for authorities or defined value-chain actors.
Keep voluntary extra information distinct from required passport information.
CEN-CENELEC workshop material describes design choices for carrier, information portal, contents, and information exchange.
data carrier, information portal contents
Question 3
What do ESPR Articles 10 to 14 say about identifiers, carriers, access, and infrastructure?
Article 10 requires the passport to be connected through a to a persistent . The data carrier must be physically present on the product, packaging, or accompanying documentation as specified in the applicable delegated act.
Article 11 adds technical design requirements: passports must be interoperable, access must be free of charge and easy based on delegated-act access rights, data and update rights must be controlled, reliability and integrity must be ensured, and the passport must remain available for the specified period, including after insolvency, liquidation, or cessation of activity of the responsible operator.
Articles 12 to 14 cover unique identifiers, the Commission registry, and a public web portal for searching and comparing passport data according to access rights. The Commission launched the registry with a testing environment on 20 July 2026. The current testing phase precedes the first implementation deadline on 18 February 2027 for certain large batteries. The registry and portal do not replace the product-specific delegated act.
Commission Implementing Regulation (EU) 2026/1778 enters into force on 6 August 2026 and sets the process. For a product whose applicable Union rule requires both a passport and registry registration, a verified economic operator registers the passport at the model, batch, or item level required by that rule. The registry returns a unique registration identifier and can generate downloadable proof of registration. That proof remains available for 90 calendar days and can be regenerated. Automated registry checks and proof of registration do not establish substantive product compliance.
Choose carrier and identifier approaches that can support ISO/IEC 15459 alignment where relevant.
Design for open, machine-readable, structured, searchable, and transferable data without vendor lock-in.
Treat customer personal data as out of scope unless there is explicit consent under GDPR.
Plan for back-up copy arrangements through a DPP service provider where Article 10 applies.
For imports covered by a delegated act, plan to provide the unique registration identifier to customs in accordance with the applicable implementation timing; customs release is not proof of ESPR compliance.
Retain the verified-operator record, submitted identifiers and commodity code where applicable, passport granularity, unique registration identifier, version timestamps, and generated proof of registration.
Published registry rules entering into force on 6 August 2026 for operator verification, model-batch-item registration, unique registration identifiers, proof of registration, versioning, and the limit of automated registry checks.
automated verifications should not be deemed to constitute proof of compliance
Commission launch notice for the registry and testing environment, including the current testing phase and the first implementation deadline for certain large batteries.
The current testing phase
Question 4
How should teams govern DPP data and supplier evidence before final product rules are settled?
Map data lineage before fixing a field list. For each likely passport data point, identify the internal owner, supplier source, calculation method, update trigger, evidence location, access classification, and whether the field is required by law, proposed in draft product work, or voluntary.
Supplier evidence should be tied to the data it supports. CIRPASS and CEN-CENELEC materials both highlight practical design issues around supply-chain information exchange, interoperability, access control, traceability, and data availability, but they are not substitutes for the legal delegated act.
Create a field inventory with status labels: required, draft, voluntary, unknown, or blocked.
Require supplier evidence for material composition, durability, reparability, recycled content, conformity documents, or other claims only where the source rule or chosen voluntary disclosure needs it.
Keep versioning and timestamping for DPP information changes, especially model-level changes that could affect many units.
Document who may read, write, approve, or correct each field.
CIRPASS recommendations identify standards, value-chain, data quality, and implementation challenges for DPP rollout.
Recommendations for policy, business and IT
Recommended next step
Prepare DPP evidence without overclaiming
This ESPR FAQ helps separate framework requirements from delegated-act-dependent product details before teams publish DPP claims or supplier data requests.
Which details still depend on a product rule or later binding act?
Do not state final DPP fields, universal product deadlines, penalties, certification obligations, or mandatory service-provider arrangements unless the claim is based on ESPR, an applicable delegated act, or a later binding act. The Commission consultation material shows that service-provider storage, management, and certification questions are still part of policy development.
Keep a conditional record for each product: the applicable delegated act, its mandatory fields and access rights, the horizontal technical requirements, the supporting standards or common specifications, and any unresolved service-provider requirement.
Do not treat CIRPASS, CEN-CENELEC, ETSI, or GS1 materials as binding ESPR product requirements by themselves.
Do not turn Annex III candidate elements into a universal mandatory checklist.
Do not promise that a QR code alone satisfies ESPR; the delegated act decides carrier details and access requirements.
Do not assume public users, suppliers, repairers, customs, and market surveillance authorities all see the same data.
Commission impact-assessment page shows future service-provider requirements and certification feasibility were still under assessment.
future requirements for DPP service providers
Question 6
Questions and answers
Does every product need an ESPR ?
No. A product needs a when an applicable ESPR delegated act requires one. The act defines the covered product group, required data, model-batch-item level, carrier, access rights, update responsibilities, and availability period.
Who creates and checks the ?
For a product covered by an applicable act, the manufacturer must ensure that the passport is available and provide the required back-up copy. The importer verifies that the passport is available, the distributor verifies the required link and documents where relevant, and the dealer gives customers access to the required information, including in distance selling. The delegated act can assign more specific creation and update rights.
Can a QR code by itself satisfy ESPR?
No. A QR code can be a , but the applicable delegated act decides the carrier, its placement and layout, and whether it identifies a model, batch, or item. The linked passport must also meet the required data, access, interoperability, integrity, update, back-up, and availability rules.
What data belongs in an ESPR passport?
Use the product-specific delegated act. Annex III lists possible elements such as product and commodity identifiers, compliance documents, manuals or warnings, manufacturer and importer details, facility identifiers, and back-up service-provider information, but it is not a universal mandatory field list.
What evidence should support each passport field?
Keep the source, product scope, calculation or test method, supplier evidence, owner, approver, access level, version date, and update trigger for each field. The current passport must stay aligned with technical documentation, declarations, labels, manuals, and the model, batch, or item identified by the .
When should a be reassessed?
Reassess it when the delegated act or supporting specification changes, when product design, production, supplier data, test results, conformity documents, warnings, or responsible operators change, and when an authority or internal review finds an inaccurate or incomplete value. Record the changed field, source evidence, approver, date, and affected model, batch, or item.
What does registration prove?
Registration proves that the passport was registered and gives the responsible operator a unique registration identifier. A generated proof remains available for 90 calendar days and can be regenerated. The registry's automated checks can test structure, identifiers, granularity, completeness, and other configured fields, but neither those checks nor the proof of registration establishes substantive product compliance.
Published implementing regulation entering into force on 6 August 2026 for verified-operator access, passport registration, unique registration identifiers, proof of registration, versioning, and the limits of automated registry checks.
Published registry rules entering into force on 6 August 2026 for operator verification, model-batch-item registration, unique registration identifiers, proof of registration, versioning, and the limit of automated registry checks.
"automated verifications should not be deemed to constitute proof of compliance"
Commission launch notice for the registry and testing environment, including the current testing phase and the first implementation deadline for certain large batteries.