EU Digital Product Passport Checklist

Start by separating mandatory DPP obligations from preparation work. Under ESPR, the detailed passport requirements for a product depend on delegated acts adopted for the relevant product group. Until a product group is covered, the team can prepare data and architecture, but it should not describe the ESPR passport as live mandatory compliance for that product.

For every stock-keeping unit (SKU), model, batch, or item under review, record the product group, economic operator placing it on the EU market, importer or EU responsible person where relevant, commodity code if import release may be involved, and whether another Union law already requires digital product information for the product.

Build the field list from the delegated act and Annex III, then map each field to a system of record. Do not publish a passport field just because marketing, sustainability, or procurement can provide text; the field needs a defined data source, validation rule, update owner, and evidence artifact.

As a planning catalogue, screen product identifiers, commodity codes where relevant, compliance documentation, user instructions and safety information, manufacturer and importer details, EU responsible economic operator details, operator and facility identifiers, and the DPP service provider hosting the back-up copy. Mark each field required, permitted, or not applicable under the relevant product rule.

A DPP readiness check should prove that the physical product can reliably resolve to the correct digital record. ESPR requires the passport to be connected through a data carrier to a persistent unique product identifier, with the carrier placed on the product, packaging, or accompanying documentation as specified by the relevant delegated act.

Identifier work should include lifecycle controls. If operator or facility identifiers are missing, the economic operator creating or updating the passport must confirm that no identifier exists before requesting one on behalf of the relevant actor.

The passport should not expose every field to every reader. ESPR requires easy access based on actor-specific access rights, while preserving security, privacy, data integrity, and restrictions on who can introduce, modify, or update passport data.

Create an access matrix before implementation. Include consumers, dealers, online marketplaces, manufacturers, importers, distributors, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, trade unions, and any product-group-specific actors named in the delegated act.

Supplier evidence is a passport control, not a one-time questionnaire. The economic operator placing the product on the market needs enough validation to keep passport data accurate, complete, and up to date after supplier changes, engineering changes, remanufacturing, repair, or end-of-life handling.

For each supplier-provided field, require the supplier to identify the measured value or declaration, method used, date of evidence, affected component or material, responsible contact, change-notification trigger, and confidentiality tier.

Operational readiness includes the public and authority-facing infrastructure around the passport. The Commission launched the DPP Registry and a separate testing environment on 20 July 2026. The Registry indexes DPPs using unique identifiers, registration data, and high-level metadata rather than storing the full passport; for covered imports it also supports commodity-code and registration checks.

Before release, test whether the passport record, back-up copy, data carrier, unique registration identifier, commodity code, and access matrix line up. Customs release checks under ESPR are not proof of full compliance, so the evidence file must still show the underlying field validation and approvals.