EU Digital Product Passport Product-Group Readiness Checklist

Start with the legal status of the product group. ESPR is framework legislation: concrete ecodesign and information requirements are set later through product-specific or horizontal delegated acts. The Commission page states that the first ESPR and Energy Labelling Working Plan was adopted in April 2025 and that product rules will be developed through planning, impact assessments, Ecodesign Forum consultation, and specific consultations.

Mark a product group as ready for DPP implementation only when the team can point to the relevant delegated act, draft consultation material, or working-plan priority and can label that status correctly. If the product group is only being monitored, the output should be a readiness backlog, not a live passport specification.

Create a field inventory before designing screens or supplier forms. ESPR Annex III lists the types of passport data that delegated acts can draw from, including product information required by Article 7, the unique product identifier, GTIN or equivalent identifiers, commodity codes, compliance documentation, instructions and safety information, manufacturer and importer information, operator and facility identifiers, and the passport service provider reference.

For each candidate field, name the system of record, update owner, evidence source, public/confidential status, and whether the value applies at model, batch, or item level. Leave fields in a pending state when the delegated act has not yet selected them.

A product group is not ready if the manufacturer cannot obtain controlled, updateable data from suppliers and downstream actors. ESPR requires passport data to be accurate, complete, and up to date, and Article 9 allows the delegated act to specify who may create or update the passport and what data each actor may introduce or update.

Convert this into supplier controls. Each field should have a named supplier source, evidence format, validation rule, confidentiality classification, and change-notification trigger. This is especially important for substances, material origin, recycled content, repair information, and facility or operator identifiers.

Do not treat a QR code, NFC tag, or web URL as the passport by itself. ESPR requires the passport to be connected through a data carrier to a persistent unique product identifier. The delegated act specifies the carrier, layout, positioning, and whether the passport is established at model, batch, or item level.

The readiness check should prove that identifiers can remain unique, verifiable, and durable across packaging changes, product variants, domain changes, service-provider changes, and market surveillance or customs checks.

The readiness checklist should classify every field by access class before it is loaded into a passport system. ESPR requires access to be regulated by the essential requirements in Articles 10 and 11 and by product-group access rights in the applicable delegated act. It also lists audiences that may need access, including customers, economic operators, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, and trade unions.

Use access classes to avoid two common errors: hiding information that the delegated act makes available to a class of actors, or exposing business-sensitive and personal data beyond the allowed purpose.

Registry readiness is a separate workstream from the public passport page. ESPR Article 13 requires the Commission to set up a digital registry that stores at least unique identifiers securely; for products intended for release for free circulation, the registry must also store the commodity code. Delegated acts can specify other data to store in the registry to support passport authenticity, market surveillance, and customs controls while avoiding disproportionate administrative burden.

Treat a product group as registry-ready only when the team can generate valid identifiers, bind them to the correct commodity codes where relevant, submit or expose the expected registry payload, and reconcile registry records with the passport resolver and internal product master data.