Executive Summary
If you sell into the EU, DPP is not somebody else’s problem. Whoever creates the passport, you still have to find it, verify it, and serve it to the shopper.
Take one supplier passport reference. In many retail stacks it arrives with a supplier code the PIM has never seen, maps to three SKUs across two variants and a bundle, carries a GTIN that no longer matches the product record, and is issued per batch when the commerce platform stores only product-level identifiers. Until those identifiers resolve to one product, the passport cannot be verified or shown to a shopper. That is a catalog, supplier, and integration problem, and it sits with the retailer.
- Your role decides the workload. For branded lines bought from EU suppliers, passport creation generally sits upstream. For own-brand ranges and direct imports, it sits with you, along with the full manufacturer-side data burden.
- The dealer duty is yours regardless. Where DPP rules apply, you must make the passport easily accessible to shoppers, including when the product is sold online.
- Fix the product-data foundation first. Technology comes second. Map exposure, make supplier data intake repeatable, and make identifiers resolve before choosing any DPP platform.
- The same work pays twice. A catalog that can carry passports is a catalog search engines, marketplaces, and AI shopping agents can read.
Much of the Digital Product Passport conversation so far has centered on manufacturers: what data to collect, how to register it, and which delegated act applies. Retailers tend to appear as a footnote. Yet the retailer is where a passport either reaches the shopper or fails to, and where gaps in supplier data, product identifiers, and commerce systems become visible. This article sets out what DPP actually asks of a retailer, which dates matter for which categories, and six steps to make your catalog ready before the rules for your categories arrive.
Digital Product Passports Have Moved From Regulation To Implementation
On 20 July 2026 the European Commission’s Digital Product Passport Registry went live. Passports are no longer a policy debate. They are records your suppliers will register, your systems will have to receive, and your shoppers will expect to find on your product pages.
The easy misunderstanding is that a retailer that does not create passports can leave DPP to its suppliers. It cannot. The Ecodesign for Sustainable Products Regulation (ESPR) applies to any business making in-scope products available on the EU market. That includes UK and other non-EU retailers selling into the EU through their own site, a marketplace, or an EU subsidiary.
Your role decides how much of the work lands on you. Under ESPR, the passport is created and registered by whoever places the product on the EU market. For branded lines sourced from EU suppliers, that responsibility generally sits upstream. For own-brand products, and where you import products into the EU, it sits with you. Most retailers sit in both seats at once: the same catalog holds products you must passport yourself and products whose passports you must receive.
Dealers carry a separate duty in either seat. Where DPP requirements apply, they must make the passport easily accessible to customers and potential customers, including when the product is sold online.
Whoever creates the passport, your catalog, your suppliers, and your ecommerce platform still have to know what to do with it.
Retailers Do Not Create Every Passport, But They Support All Of Them
For a retailer, a passport is not a document. It is a reference that has to travel through the business intact, along the same chain as the rest of your product data. When the rules for a category come into force, each link in that chain has a job:
- Supplier: delivers the passport identifier and access information with the product data, and tells you when either changes.
- PIM: identifies which products fall within DPP requirements, links the right passport to the right product, variant, and batch, and records whether that passport has been verified.
- ERP: ties the passport to the supplier, purchase order, and inventory records that show which items you actually hold.
- Commerce platform: publishes only products whose required passports are verified, and exposes the passport data the shopper needs.
- Customer: reaches the passport from the product page, on any device, without leaving the buying journey.
That last link is a legal requirement, not a design preference. ESPR specifically requires dealers to make the DPP easily accessible to customers and potential customers, including in distance selling. A DPP is not simply a QR code on a physical product. If a customer is considering that product on your ecommerce site, the passport must be available through the digital buying journey, in whatever form the rules for that category specify.
Break any link and the passport fails at the point where a shopper or a regulator looks for it. For a retailer with thousands or millions of SKUs from hundreds of suppliers, that is a product-data and integration problem at scale, not a regulatory reading exercise.
The DPP Timeline Retailers Should Watch
No single date applies to every product. Requirements arrive category by category, so the deadline that matters is the one for what you sell.
- Batteries, 18 February 2027. Passports become mandatory under the EU Battery Regulation for electric vehicle batteries, light means of transport batteries (e-bikes and e-scooters), and industrial batteries above 2 kWh. This is the first fixed date, and it matters most to retailers of e-bikes, e-scooters, and battery systems.
- Other product groups, adoption from 2026 to 2029. The Commission’s Ecodesign Working Plan 2025 to 2030 sets indicative adoption years for the first ESPR delegated acts: iron and steel from 2026; textiles, tires, and aluminum from 2027; furniture from 2028; mattresses from 2029; and ICT and other electronics through horizontal repairability and recyclability rules from 2027 and 2029.
Those adoption years are not compliance deadlines. Each delegated act is normally followed by an application period of at least 18 months. That sounds like a long runway until you set it against the time it takes to get structured, validated passport data from hundreds of suppliers. The useful question is not when the deadline falls, but:
Which products in our catalog are affected, in which role, and how long will our suppliers take to deliver the data?
DPP is also not the first ESPR obligation to reach retail. The ban on destroying unsold apparel, clothing accessories, and footwear has applied to large enterprises since 19 July 2026.
Six Things Retailers Should Do Now
The six steps follow the path a passport takes through your business, from supplier to shopper. None of them starts with buying a DPP platform. Fix the product-data foundation first; technology comes second.
1. Map Your Catalog Against the DPP Timeline
Start with exposure, not technology. Identify which SKUs, categories, and suppliers intersect with current or expected DPP requirements.
What needs to change: for each category, establish:
- applicable EU legislation and its current status
- likely timing
- your role for that product: creator (own-brand or direct import) or dealer
- the manufacturer or importer, and the supplier responsible for passport data
- current identifiers
- availability of structured product and sustainability data
Why it matters: without an exposure map, retailers either fund a blanket compliance program they do not need or miss the categories where they are the creator and carry the full data burden. A fashion retailer, an automotive parts distributor, and a furniture marketplace should not have identical DPP roadmaps. Their product exposure, supplier structures, and timelines are different.
What good looks like: every affected or potentially affected product group has an owner, a supplier-data source, a regulatory status, and a target readiness date.
2. Turn Supplier Data Intake Into an Operating Process
For many retailers, the hardest DPP problem sits upstream. You cannot verify or expose passport information that the supplier never delivered, so DPP readiness has to become part of supplier onboarding and buying operations.
What needs to change: define, for every supplier:
- the DPP information suppliers must provide, with required identifiers and links
- formats and APIs for data transfer
- responsibility for updates, and notification when passport data changes
- validation rules and the process for incomplete or invalid submissions
- escalation where a supplier cannot meet the requirement
Why it matters: supplier data collection is the longest-lead item in DPP readiness, and it does not compress when a deadline gets close. A spreadsheet emailed once during onboarding will not hold up across hundreds of suppliers and changing passport data. The objective is a repeatable data supply chain.
What good looks like: new and existing suppliers provide required DPP information through a defined, validated process rather than through manual intervention for each product.
3. Fix Product Identifiers Before Worrying About Passport Presentation
A Digital Product Passport has to resolve reliably to the correct product. That becomes difficult when the same product exists under supplier codes, retailer SKUs, GTINs, variants, bundles, batches, and internal ERP identifiers that do not map cleanly to one another. ESPR allows passports to operate at model, batch, or individual-item level, depending on the rules set for the product group, so retail technology has to cope with more than a one-SKU-to-one-page relationship.
What needs to change: commerce, PIM, POS, and integration layers resolve persistent product identifiers consistently, at whatever granularity the rules for each category require. Retail is also moving toward 2D barcodes: GS1’s Ambition 2027 aims for retail point-of-sale systems to process defined GS1 2D barcodes by the end of 2027. That transition is relevant to DPP readiness, but the two should not be confused. The exact DPP data carrier and granularity will depend on the applicable regulation.
Why it matters: every later step depends on this one. A passport attached to the wrong product, variant, or pack size is worse than no passport at all, because it puts an incorrect claim in front of a shopper under your name.
What good looks like: a product identifier can be traced reliably from supplier data through PIM and commerce to the customer-facing product experience.
4. Build Passport Verification Into Catalog Operations
Receiving a DPP reference from a supplier should not make a product ready for sale. Where the applicable rules require a passport, distributors must verify that the product is linked to one before making it available on the market.
What needs to change: verification becomes a workflow in catalog operations rather than a manual compliance check. A retailer should be able to determine:
- whether a passport should exist
- whether an identifier has been provided
- whether the passport resolves correctly, and whether product and passport correspond
- whether required access continues to function
- who owns an exception when verification fails
The EU Registry now provides the infrastructure for registering and managing DPP identifiers, and its operational environment includes API access, so verification can run as a system process.
Why it matters: an exception caught at intake costs a supplier query. The same exception caught after listing costs a delisting and, potentially, a compliance finding. At catalog scale, manual checks will not keep up.
What good looks like: exceptions are identified before products reach customers, with a clear workflow back to the responsible supplier or product owner.
5. Decide Which System Owns Which Data; Do Not Bolt On Another Database
A DPP should not become another isolated product-information repository. The EU architecture itself is decentralized. The central Registry holds identifiers and high-level metadata, while the underlying passport information stays with the responsible economic operator or its DPP service provider.
What needs to change: each data domain gets a clear owner. The PIM may remain the source for merchandising information. A DPP platform may hold authenticated lifecycle and compliance data. ERP owns supplier and inventory information. Commerce exposes only the subset the customer experience requires, and the integration layer connects those systems reliably. The architecture also has to handle different levels of granularity: some product information sits at model level, some varies by production batch, and products such as batteries require item-level records. Not every DPP field will be public, because ESPR provides for different access rights for consumers, authorities, and other participants.
Why it matters: buying a DPP platform before ownership is settled adds another silo and another set of identifiers to reconcile. The architecture decision is about data ownership first. The platform choice follows from it.
What good looks like: systems have clearly defined ownership of each data domain, identifiers connect them consistently, and public or restricted information can be exposed to the appropriate audience.
6. Make the Passport Part of the Commerce Experience
This is the part customers see, and the point where the dealer duty is met or missed. A retailer can have perfectly structured DPP data upstream and still fail if customers cannot reach it through the product-buying journey.
What needs to change: the implementation will differ by category and delegated act, but the commerce layer should already be prepared to support:
- passport access from product detail pages, on mobile
- QR and GS1 Digital Link journeys
- product-level identifiers and structured product attributes
- multilingual information
- links to repair, care, recycling, or other lifecycle services
- machine-readable product feeds and APIs
Why it matters: DPP information can contain material composition, provenance, repairability, maintenance, safety, and recycling detail that affects a purchasing decision. A compliance link hidden at the bottom of a product page meets the letter of the rule and wastes the data. Implemented properly, the passport becomes part of the product experience rather than an interruption to it.
What good looks like: a customer moves from product discovery to trustworthy passport information without leaving the buying journey or having to understand the regulatory infrastructure underneath.
Connecting Fabacus DPP Data to the Retail Buying Journey
Net Solutions has partnered with Fabacus to help brands and retailers put Digital Product Passports to work across the systems they sell through.
Fabacus’s proprietary data platform, Xelacore, builds a trusted system of record for product data and authenticates the claims behind it. That is the foundation of its Digital Product Passport service.
Net Solutions’ role starts where the passport meets the retailer. We connect passport data to supplier intake, PIM, ERP, and the ecommerce platform so that each passport resolves to the right product, is verified before that product is listed, and reaches the shopper on the product page.
For a retailer, that means passports arrive through the same supplier process as the rest of the product data, exceptions surface before go-live rather than after, and shoppers find passport information inside the buying journey instead of behind a compliance link.
The objective is not to generate a passport. It is to make passport data work reliably from supplier to shopper.
The Bigger Opportunity Is a Product Record Machines Can Trust
Compliance sets the deadline. The bigger business opportunity sits in the same work. Making a catalog DPP-ready requires consistent product identity, structured attributes, reliable supplier information, traceable claims, and machine-readable product data. Digital commerce increasingly runs on exactly those things.
Search engines, marketplaces, and AI shopping agents need structured information to understand what a product is, whether it matches a customer’s requirement, and whether the available information can be trusted. That is why product data now decides AI commerce: a buyer’s agent cannot recommend what it cannot verify.
A passport does not make a product AI ready on its own. What carries over is the discipline behind it: a structured, verifiable product record connected through persistent identifiers, instead of claims scattered across supplier spreadsheets, PDFs, ecommerce copy, and internal systems.
Run DPP as a standalone compliance project and you get a passport. Run it as a product-data program and you also improve product discovery, marketplace syndication, customer confidence, after-sales service, and the ability of machines to interpret your catalog.
Conclusion
Digital Product Passports will reach every retailer selling in-scope products into the EU, whoever creates them, and the retailers that cope best will be the ones that treat them as a product-data discipline rather than a compliance add-on. Fix identifiers, supplier data, and system ownership first, and the passport becomes part of a catalog that shoppers, marketplaces, and machines can trust.
FAQs
Only where they make products available on the EU market. A UK retailer selling into the EU through its own website, a marketplace, or an EU subsidiary is caught by ESPR for those products. A retailer selling only in the UK has no ESPR obligation today, though the same product-data work will be needed for GS1 2D barcodes and for machine-readable commerce generally.
Yes. Passport creation for branded lines bought from EU suppliers generally sits with the brand, but where DPP rules apply you still have to receive the passport identifier, verify that the product is linked to a passport before selling it, and make the passport easily accessible to shoppers, including online. If you import branded products into the EU yourself, you may be the operator placing them on the market, which moves creation responsibility to you.
There is no single date. The first fixed deadline is 18 February 2027 for electric vehicle, light means of transport, and industrial batteries above 2 kWh. Other product groups follow through delegated acts under ESPR, with textiles, tires, and aluminum indicatively adopted in 2027, furniture in 2028, and mattresses in 2029, each normally followed by an application period of at least 18 months.
Where the rules for a product group require a passport, distributors must verify that the product is linked to one before making it available on the market. A product without a verifiable passport should not go live. That is why supplier data requirements, validation rules, and escalation paths need to be in place before the rules for a category apply.
No. The first work is mapping which products are exposed, making supplier data intake repeatable, and making product identifiers resolve consistently across PIM, ERP, and commerce. A DPP platform can then hold authenticated passport data, but it cannot fix identifiers or supplier processes that are not in place.
Treat it as a product-data program rather than a compliance project. That usually means a sponsor at CIO, CTO, or Chief Digital Officer level, the product-data or PIM owner running the work, and buying teams accountable for getting the data from suppliers.
