A Digital Product Passport is not a QR-code microsite. It is a governed product record: the right identity, evidence, version, access rules, and owner must survive while packaging, suppliers, software, and regulation change.
The short answer
If you manufacture, import, or sell physical products in the EU, first map which legislation and product groups may cover you. Then prepare an exportable product-data layer with stable identifiers, field ownership, source evidence, validation, versions, and access classes. Pilot it on a representative product family. Do not guess fields that a product-specific act has not defined, and do not mistake a vendor demo for compliance.
The European Commission describes the DPP as a digital container for product, component, or material information. The EU Registry stores identifiers and required registration metadata; the complete product information remains the responsibility of the economic operator and may be hosted by that operator or a service provider. That distinction determines the architecture: the Registry is an index in a decentralised system, not your new PIM.
What changed in 2026—and what did not
The EU Digital Product Passport Registry became operational on 20 July 2026, with a separate testing environment. The Commission updated its battery data-point guidance on 15 August and published further preparation guidance on 21 August. This makes DPP operational work more concrete than it was a year ago.
It does not mean that every physical product needs the same passport today. Requirements arrive through product-specific delegated acts under the Ecodesign for Sustainable Products Regulation, or through separate legislation. The Commission’s current timeline is explicitly indicative: certain batteries are first, with a mandatory date of 18 February 2027; other groups follow on their own schedules. After an ESPR delegated act is adopted, economic operators receive a transition period of at least 18 months.
Prepare the machinery now; populate the final legal field set only from the applicable act.
This article is an implementation framework, not a legal scope opinion. Confirm your role, product classification, market, exemptions, and national enforcement position with a qualified specialist.
Start with an applicability register, not a platform shortlist
Create one row for each product family and market. Record the legal entity placing it on the market, whether you are manufacturer, importer, authorised representative, dealer, or marketplace, the product group and commodity code, relevant EU instrument, likely granularity, delegated-act status, evidence owner, and next review date.
Use three scope states:
- Confirmed: an applicable legal instrument defines the requirement and date.
- Expected: the product appears on an official work plan, but final sector fields or dates are pending.
- Monitor: coverage is plausible but not established. Assign a review trigger instead of inventing a deadline.
Separate regulatory applicability from business priority. A high-volume textile family with fragmented supplier evidence may deserve an early data pilot even while final sector rules are pending. A low-volume product with clean master data may wait.
Build a readiness contract around data, not claims
The Commission’s Joint Research Centre recommends defining DPP information from use cases and separating essential, strongly recommended, and voluntary data through value, effort, and feasibility analysis. Apply the same discipline internally. The following are governance fields for your readiness layer, not a claim that each one is legally required in every DPP.
| Control | Question it answers | Failure prevented |
|---|---|---|
| Product identity | Which model, batch, or item is this? | Evidence attached to the wrong object |
| Field definition | What does this value mean and in which unit? | Supplier and channel semantics drifting |
| Source and owner | Which system and person may assert or update it? | Conflicting values with no authority |
| Evidence link | Which certificate, test, calculation, or declaration supports it? | Unverifiable sustainability claims |
| Validation | Which type, range, vocabulary, and cross-field rules apply? | Structurally valid but impossible records |
| Validity and version | When did it apply, what replaced it, and why? | Silent overwrites and expired proof |
| Access class | May consumers, partners, repairers, or authorities see it? | Leaking restricted data or hiding public facts |
| Publication state | Is it draft, approved, active, recalled, or retired? | A live QR resolving to unfinished content |
Do not choose model, batch, or item granularity by convenience. ESPR says the applicable delegated act specifies that level. Your model should support all three without duplicating common data: shared model facts, batch-specific origin or test evidence, and item-level events only where required or genuinely useful.
Use a product-data spine with replaceable edges
Source
PLM, PIM, ERP, QMS, suppliers, laboratories
Normalise
Identity, vocabulary, units, validation, evidence
Publish
Versioned record, resolver, DPP service, registry
Serve
Buyer, marketplace, repairer, recycler, authority
Give every product object a stable internal ID and map it to external identifiers. Treat the data carrier as a persistent doorway, not a PDF address. GS1 Digital Link is one open method for expressing identifiers such as GTINs in web addresses and resolving them to changing information without reprinting the code. The applicable act and standards decide what you ultimately use.
Expose separate views over one governed record. A shopper may see materials, care, repair, safety, and recycling information; a business partner may need machine-readable logistics fields; an authority may require compliance data. Role-based access should filter fields, not create contradictory copies.
Design for export from day one. Article 10 of ESPR requires open, interoperable, machine-readable, structured, searchable, and transferable data without vendor lock-in where appropriate. Preserve identifiers, field meanings, evidence links, version history, and access rules in the export—not just rendered pages.
Treat evidence as a first-class object
A value such as “72% recycled content” is incomplete without the material scope, method, unit, reporting period, issuer, document, validity, and product or batch it covers. Store the assertion separately from its proof. One certificate may support several products; one product may rely on several documents. A simple evidence graph avoids copying a PDF into every SKU.
Add expiry and change triggers. A new supplier, formulation, factory, certificate, or calculation method should identify affected records and open a review. Publishing can require two-person approval for high-risk claims. Retain the old version and its effective dates; do not edit history to make the current state look timeless.
Personal customer data does not belong in the passport by default. ESPR prohibits storing customer personal data there without explicit consent, and sector rules define access rights. Keep ownership registration, warranty accounts, and marketing profiles in separate systems unless a specific lawful design requires a connection.
Ask vendors for a recovery drill, not a feature tour
- Can we export the full structured record, evidence references, access rules, and history in a documented format?
- Who controls the identifier namespace, resolver domain, and QR destination if the contract ends?
- How does the system distinguish model, batch, and item data without copying everything?
- Which EU Registry and testing-environment workflows are supported today, and which are roadmap items?
- How are schemas, standards, and delegated acts versioned? Can old passports remain interpretable?
- How do approvals, expiring evidence, recalls, outages, and corrections work?
- Can a second provider restore a sample export and keep the same physical carrier useful?
Do not award points merely for blockchain, AI extraction, a polished consumer page, or a compliance badge. Each can be useful in a specific design; none replaces correct scope, authoritative evidence, interoperability, and accountable operations.
Use AI to accelerate review, never to manufacture proof
AI can extract candidate fields from supplier PDFs, map terminology to a controlled vocabulary, translate public instructions, compare certificates, flag unusual values, and draft a review queue. Every extracted fact should retain the source location, confidence, model or rule version, and human decision.
Do not let a model infer a missing carbon value, certification, material origin, or legal classification and publish it as fact. “Likely polyester” is a research lead, not product evidence. Deterministic validation should still enforce identifiers, units, required relationships, access, and publication state.
The same governed layer can improve commerce before a deadline. Marketplaces, product pages, support, wholesale portals, repair instructions, and AI discovery all benefit from consistent product facts. McKinsey’s 2026 B2B Pulse found inconsistent information across teams was the leading stated reason for switching suppliers; using the DPP programme to repair product truth is a business inference from that broader signal, not a promised DPP revenue effect.
Run a 30-day evidence-to-scan pilot
Choose a small but awkward product family: variants, two suppliers, at least one batch document, a changed certificate, and a consumer instruction. The goal is not a pretty demo. It is to expose identity collisions, missing proof, unclear ownership, and manual handoffs while they are still cheap to fix.
Test a supplier correction, expired evidence, renamed SKU, split batch, recalled item, unavailable hosting provider, restricted field, and export into a clean environment. Scan the same physical carrier before and after a content update. If the architecture works only on the happy path, it is not ready.
Measure readiness honestly
- Products in scope with confirmed classification and owner.
- Required or expected fields with an authoritative source and current evidence.
- Records passing structural and business-rule validation.
- Evidence expiring within 30, 60, and 90 days.
- Time from source change to approved public and restricted views.
- Unresolved identity collisions and supplier exceptions.
- Successful export, restore, resolver, and access-control tests.
A readiness score is not legal conformity. Product rules, standards, Commission guidance, and national practice will continue to evolve. Environmental calculations need the relevant method and competent review. Supplier evidence may remain unavailable. Small companies should avoid building a general platform when a governed catalog extension and a replaceable service are enough.
Frequently asked questions
What is an EU Digital Product Passport?
It is a product-specific set of data accessible electronically through a data carrier. Depending on the applicable rules and audience, it can support transparency, circularity, compliance, repair, recycling, and market surveillance.
Does every product sold in the EU need a DPP now?
No. Requirements are introduced progressively through product-specific ESPR delegated acts and other EU legislation. Confirm your product group, role, instrument, transition period, and date.
Must an online store show the DPP before purchase?
ESPR says product-specific requirements define how the passport is accessible before a distance-sale contract. It also requires operators to provide dealers and online marketplaces with a digital carrier copy or unique identifier where relevant. Follow the applicable act.
Is a QR code the Digital Product Passport?
No. The code is a data carrier that connects a physical product, packaging, or documentation to a persistent identifier and digital record. Identity, data, evidence, access, hosting, and updates make the system useful.
Should we wait for final sector rules?
Wait before declaring final compliance or hard-coding uncertain fields. Do not wait to classify products, repair identifiers, assign data ownership, connect evidence, test exports, and monitor official triggers.
Sources and verification date
Verified 24 August 2026 against the European Commission’s current Digital Product Passport overview and timeline and Registry documentation; the consolidated Ecodesign for Sustainable Products Regulation, especially Articles 9–11; the European Commission Joint Research Centre’s 2026 methodology for DPP data requirements; the current GS1 Digital Link standard overview; and McKinsey’s 2026 Global B2B Pulse report. Always recheck the applicable delegated act and latest Commission guidance before implementation.
Continue: build a source-grounded catalog content workflow, audit structured product promises for AI shopping, or ask Rendframe to design the product-data and integration layer behind your DPP programme.