ESPR digital product passport checklist for businesses

If you place products on the EU market, the safest assumption is that digital product passport obligations are coming closer to your business, not further away. The Ecodesign for Sustainable Products Regulation, or ESPR, creates the legal framework for product-specific rules that will require certain goods to carry structured sustainability and compliance information in a digital product passport. The practical work does not start when the final delegated act for your product lands. It starts now, with product mapping, data ownership, supplier engagement and system design.

That is why we advise treating this as an operational readiness project, not just a legal watch item. A good ESPR digital product passport requirements checklist for businesses should help you answer three immediate questions. Are we likely to be in scope? What data will we need to hold and publish? Who inside the business is accountable for getting us there?

ESPR is an EU regulation designed to improve the sustainability, circularity and overall environmental performance of products placed on the EU market. It replaces the older ecodesign approach that focused mainly on energy-related products and creates a broader framework that can apply across many product groups.

The regulation itself does not impose the same detailed passport rules on every product from day one. Instead, it enables the European Commission to adopt delegated acts for specific product categories. Those delegated acts will set out the actual requirements for the products in scope, including performance rules, information requirements and, where relevant, digital product passport content.

A digital product passport is, in practical terms, a structured digital record linked to a specific product, model, batch or item, depending on the rule. It is intended to make key product information available to the right parties, which may include consumers, market surveillance authorities, customs authorities, repairers, recyclers and other economic operators. The exact audience and data fields will depend on the product-specific legislation.

For businesses, that means two things.

First, you cannot wait for a generic one-size-fits-all passport solution. The final data model, access rights, identifier rules and retention requirements will depend on the delegated act for your product group.

Second, you still should prepare before those detailed rules apply. Most businesses already know where the real difficulty lies. It is not generating a QR code at the end. It is tracing materials, validating supplier claims, version-controlling technical documentation, linking products to unique identifiers and making sure the same information appears consistently across ERP, PLM, compliance files, labelling and customer-facing channels.

If you sell into the UK as well as the EU, keep the legal position separate. ESPR is an EU regime. The UK is developing its own digital product policy direction in some sectors, but that is not the same legal framework and should not be treated as automatically equivalent. If you need a wider view of that difference, see how the UK digital product passport framework is taking shape.

The first question is not whether you manufacture. The first question is whether you act as an economic operator for products placed on the EU market.

Under EU product law, the key roles usually include manufacturer, authorised representative, importer and distributor. If you make products under your own name or trademark, or have them designed and manufactured for you and place them on the market under your brand, you are likely to be treated as the manufacturer for compliance purposes. If you bring products into the EU from a third country, you may be the importer. If you simply make products available further down the chain, you may be a distributor, but distributors still have obligations.

In scope does not only mean finished goods factories. It can affect brand owners, own-label sellers, assemblers, importers, marketplace sellers with their own branded products, and in some cases component or subsystem suppliers where upstream data must feed the final passport.

Product scope will be phased through delegated acts. ESPR prioritises categories with significant environmental impact and potential for improvement. Batteries already have a more advanced digital passport pathway under separate EU battery rules, which is why many businesses use batteries as the first practical model for passport readiness. If that is relevant to your organisation, our guides on how a digital product passport works in practice and how to build a battery digital product passport are useful starting points.

To decide whether your business is likely to be affected, work through these questions:

• Do we place physical products on the EU market under our own name or trademark?
• Do we import products into the EU from the UK, Asia, the US or any other non-EU country?
• Are any of our products in categories already identified as likely ESPR priorities?
• Do we sell products into sectors facing strong traceability pressure, such as batteries, electronics, textiles, furniture or construction-related goods?
• Are we already required to maintain technical documentation, declarations of conformity, material composition data or due diligence records that would likely feed into a passport?
• Do our customers already ask for sustainability, repairability, recycled content or end-of-life information at SKU level?

If the answer to several of these is yes, you should assume preparation is warranted even if your exact product category is not yet covered by a final delegated act.

A useful checklist is not a list of abstract principles. It is a set of actions that assign responsibility and expose gaps. We recommend working through the following areas.

Create a controlled product inventory covering every product family, model and variant sold into the EU. Include:

• internal SKU or part number
• product name and commercial description
• brand owner
• manufacturing location
• EU countries of sale
• whether the product is imported into the EU
• whether it contains batteries, electronics, textiles or other likely priority components
• existing regulatory files linked to the product

Do not rely on catalogue descriptions alone. The passport obligation will attach to legally defined products, not marketing groupings.

For each route to market, identify whether we act as manufacturer, importer, distributor or authorised representative. This matters because the obligation to create, maintain or verify passport data may sit with different parties depending on the legislation.

A single business may hold different roles across different products. For example, we may manufacture one line, import another from a non-EU factory, and distribute a third-party product in another category. The compliance workflow cannot be designed correctly until those roles are clear.

Set up a formal legal horizon-scanning process. At minimum, assign ownership for monitoring:

• ESPR delegated acts relevant to our product categories
• related implementing acts and technical standards
• sector-specific EU legislation that already imposes passport or data-sharing obligations
• national enforcement guidance where available

This should sit in a register, not in somebody's inbox.

Run a gap assessment between current product data and likely passport data. Typical data domains include:

• product identifiers
• manufacturer and economic operator details
• material composition
• substances of concern, where legally required
• recycled content claims
• repair, maintenance and disassembly information
• conformity and technical documentation references
• performance and durability information
• end-of-life handling information

At this stage, list source systems and document owners as well as the data field itself.

A digital product passport requires a reliable link between the physical product and the digital record. Decide early how that link will work. Questions include:

• Will the passport link sit at model, batch, serial or item level?
• Which existing identifiers can be reused?
• Will we use GTIN, serial number, internal product code or another accepted identifier?
• How will the identifier appear on the product, packaging or accompanying documentation?
• Who controls identifier issuance and uniqueness?

If this is left too late, the technical solution becomes expensive and inconsistent.

Many businesses already hold declarations, test reports, bills of materials and supplier certificates, but not under proper version control. We need one controlled approach for:

• document naming
• approval status
• effective dates
• superseded versions
• product linkage
• retention periods
• access permissions

Passport data cannot be trusted if the underlying evidence is unmanaged.

Supplier information is often the biggest blocker. Create a structured process for requesting, validating and updating upstream data. This should include:

• standard data request templates
• contractual information obligations
• deadlines and escalation routes
• evidence requirements for claims
• change notification obligations
• audit rights where appropriate

No passport programme survives if everyone assumes someone else owns it. Name accountable owners across legal, compliance, product, procurement, IT, quality and operations. One person should own overall delivery, but each data domain needs a business owner.

Most businesses already have pieces of the answer spread across different systems. The challenge is to turn fragmented records into a governed, repeatable passport process.

Start with the data model. We need a clear structure for each product category that distinguishes:

• mandatory data fields
• optional or customer-facing fields
• source of truth for each field
• evidence supporting the field
• owner responsible for maintenance
• update trigger
• publication rules and access rights

This matters because not every data point will be public, and not every audience should see the same information. A future delegated act may specify which data must be accessible to consumers, which to professional repairers, and which only to regulators or customs authorities.

Next, identify source systems. In many organisations, product data sits across ERP, PLM, PIM, supplier portals, quality systems, compliance folders and spreadsheets. We need to decide whether the passport layer will pull from those systems through integrations, or whether a central compliance repository will be used to normalise the data before publication.

In practice, the minimum system capability usually includes:

• a master record for each in-scope product
• controlled product identifiers
• document management with version history
• supplier data intake and validation
• workflow for approvals and updates
• an output mechanism for passport publication or exchange
• audit trail showing who changed what and when

For businesses with larger product ranges or frequent updates, manual handling will fail quickly. That is where API design and integration become important. If you are comparing architecture options, our guide on choosing an API for digital product passports sets out the practical considerations.

Operational processes matter just as much as systems. We recommend documenting at least the following workflows:

Before a product is launched into the EU market, the business should confirm whether it is in scope, whether required data fields are complete, whether the identifier has been assigned, and whether the supporting documents are approved.

If a supplier changes a material, manufacturing site, composition, component specification or certification status, we need a rule for deciding whether the passport data must be updated. This should align with existing engineering change or quality change procedures, not sit outside them.

Some data will need scheduled reconfirmation even where no product change has been declared. Supplier attestations, recycled content claims and supporting certificates should not remain live indefinitely without review.

There must be a route for missing data, disputed supplier claims, failed validations and urgent product holds. If a required field is incomplete, the business should know whether the product can still ship, who can approve an exception and what remediation timeline applies.

Retention periods will depend on the applicable legislation, but the business should define them in advance for both passport data and underlying evidence. This is especially important where products remain on the market for long periods or where after-sales and end-of-life information must remain accessible.

The most common gap is not lack of awareness. It is overconfidence about data availability. Businesses often assume they already hold the information because it exists somewhere in the organisation. When we test that assumption, the data is usually incomplete, inconsistent, locked in PDFs, or unsupported by evidence.

Supplier data is the second major risk. Upstream manufacturers may not be contractually obliged to provide the level of detail needed for a passport, particularly where products are sourced under older agreements. Some suppliers will also be reluctant to share composition or sourcing information without clear confidentiality controls and defined data-sharing rules.

Governance is another weak point. If legal monitors regulation, procurement speaks to suppliers, product teams manage specifications, and IT controls systems, but nobody owns the full process, gaps persist for months. The result is a compliance programme that looks active in meetings but does not move in operations.

Disconnected systems create a further problem. A product identifier in ERP may not match the identifier used in technical files. A bill of materials in PLM may not align with what procurement buys. A declaration stored in a shared drive may not be linked to any live SKU list. A digital product passport exposes those inconsistencies very quickly.

To prioritise action, we recommend a staged approach.

First, identify the product lines with the highest likelihood of near-term scope or highest EU revenue exposure. Start there rather than trying to solve every product at once.

Second, complete a legal role and product mapping exercise. This gives us the basis for every later decision.

Third, run a data gap assessment against likely passport fields and underlying evidence. Focus on where the information comes from, not just whether a field can be filled.

Fourth, design the identifier and system architecture early. Many delays happen because businesses leave technical design until after the legal review, when in reality the two need to progress together.

Fifth, engage suppliers now. Contract updates, onboarding templates and data validation routines take time to bed in.

Finally, put named accountability in writing. The businesses that handle ESPR well are the ones that treat it as a cross-functional product compliance programme with executive backing, not as a side project for one compliance manager.

The regulation will continue to develop product by product, but the readiness work is already clear. If we know our role, know our products, know our data and know who owns the process, we are in a far stronger position when detailed passport rules arrive. That is the real value of working through an ESPR digital product passport requirements checklist for businesses now, before the deadline pressure starts.