A QR code on a product is not a Digital Product Passport. Nor is a spreadsheet of material data, a supplier declaration saved in an inbox, or an AI-generated product description. A Digital Product Passport is retrievable structured product information — a controlled way to make relevant product information accessible, traceable and supportable with evidence for the product groups and requirements that apply. For teams placing products on the EU market, the immediate challenge is less about choosing a QR code provider and more about establishing whether product data, supplier information, documents and internal ownership can withstand scrutiny. The regulatory framework is progressing in stages. Preparation can progress now, without presenting developing requirements as settled law. This is general guidance, not legal advice.
What a Digital Product Passport is — and is not
A Digital Product Passport, usually shortened to DPP, is a digital record linked to a product, batch or model that makes defined information available across the product lifecycle. Under the current ESPR framework it is a product-specific data set made accessible electronically through a data carrier. The carrier on the product, packaging or documentation is the pointer. The passport is the retrievable data behind that pointer. Precise content, data model, access rules and implementation dates depend on the applicable product legislation and delegated measures.
It is
Retrievable product information
A governed, product-specific data set accessed electronically through a data carrier under the rules that apply to that product.
It is not
A QR code by itself
A QR code, PDF, spreadsheet or marketing page is not a passport. The carrier does not prove sustainability or compliance.
One field list for every product
There is no universal EU DPP dataset. Product-specific delegated acts or sectoral laws set the fields.
A central warehouse of all product files
The DPP Registry indexes identifiers and required registration data. Detailed product information stays with operators or their service providers.
How carrier, identifier, Registry and data storage relate
The Commission describes a decentralised DPP system. Product data remains the responsibility of the relevant economic operators, who may host it themselves or through DPP service providers. The Registry is the EU-level index, not a copy of every confidential product file.
- ProductProduct
- Data carrierIdentifier
- RecordDPP data
- AccessAuthorised actors
DPP Registry = identifier / registration index. It is not a central warehouse of every product file.
In text: a product is linked through a data carrier to an identifier; that identifier retrieves DPP data for authorised actors. The DPP Registry indexes identifiers and registration data. It does not hold every product file.
Decentralised product information
The operator, or an authorised processor, holds the passport content and must keep it accurate, complete and up to date under the applicable act.
Pointer on the product
A QR code is one possible data carrier. The applicable act decides carrier type and placement. The carrier is not the passport.
Product identifier and registration identifier
The unique product identifier is provided by the economic operator. After successful Registry validation, a unique registration identifier is generated and stored. These are different identifiers.
Role-based views
Consumers, repairers, recyclers, authorities and other actors see the fields the applicable law assigns to them. Not every field is public.
Confirmed requirements and developing measures
The EU Ecodesign for Sustainable Products Regulation — Regulation (EU) 2024/1781 — creates the framework for Digital Product Passports across a broad range of product groups. It provides for information connected to products to be made available through a data carrier and sets conditions around identifiers, access and interoperability. It does not mean that every product already has the same live passport obligation or an identical dataset.
For specified batteries the position is more advanced. Regulation (EU) 2023/1542 Article 77 requires a battery passport for each light means of transport (LMT) battery, each electric-vehicle battery, and each industrial battery with capacity greater than 2 kWh placed on the market or put into service from 18 February 2027. A QR code duty from the same date is a separate Article 13(6) obligation. Not every battery needs an Article 77 passport. Teams should read the Regulation on EUR-Lex against their products and supply-chain role.
For textiles, apparel, electronics, iron and steel and other ESPR groups, teams should distinguish the confirmed framework from future product-specific requirements. Iron and steel remain early preparation. A sensible programme does not wait for every field to be finalised. It concentrates first on the information and evidence that will remain useful whichever detailed measure follows.
- Check whether a reviewed instrument may apply
- Digital Product Passport requirements
- EU battery passport requirements
- Digital Product Passport timeline
ESPR — Regulation (EU) 2024/1781
Horizontal framework. Product-specific delegated acts determine whether a passport applies, the dataset, access, carrier and timing.
Battery passport — 18 February 2027
Each LMT battery, each EV battery, and each industrial battery greater than 2 kWh placed on the market or put into service. QR marking applies to all batteries; the passport does not.
Toys and detergents
In-scope toys: model-level DPP from 1 August 2030. Detergents and specified end-user surfactants: model-level DPP from 23 September 2029. Those dates are enacted application dates, not 2026 duties.
Textiles, electronics, iron and steel
The Commission’s current Working Plan indicates adoption windows. Those years are planning targets, not application dates. Do not treat anticipated fields or generated suggestions as adopted law.
Digital Product Passport explained: three levels of certainty
A practical DPP programme separates regulatory facts from internal decisions. Mixing them is how an early-stage data project gets mistaken for compliance.
Primary legal sources
EUR-Lex regulations and published Commission material: the ESPR framework, the role of delegated acts, and the battery passport provisions. A DPP does not replace other product, chemical, market-surveillance or labelling duties already in force.
Planning signals, not conclusions
Proposed, consulted or expected measures. Product categories, data fields, timing and technical standards may change before adoption. Use them to prioritise architecture and supplier work, not to lock a template that may not match the final rules.
Operational work you can do now
Map the product record, identify evidence, ask suppliers for missing information, establish owners and log remediation. These steps improve readiness. They are not a certificate of legal compliance, even where data appears complete.
The operational problem behind most DPP projects
Most organisations do not lack data entirely. They lack a reliable chain between the product, the claim, the source document, the supplier and the person responsible for keeping the record current.
A material composition may sit in product development files, recycled-content evidence with a tier-one supplier, repair information with after-sales, and a bill of materials in an ERP system. None of those sources automatically forms a usable passport record. Teams need to determine which version applies to which product variant, whether the evidence is current, whether it supports the stated claim, and who can correct it when something changes.
The problem becomes sharper for importers and brands sourcing internationally. Suppliers may provide declarations in inconsistent formats, records may be tied to a shipment rather than a model, and sub-supplier information may be unavailable or commercially sensitive. A credible preparation process records those constraints rather than filling the gap with assumptions.
Assess readiness across six dimensions
A useful diagnostic examines readiness as an operating model, not simply as a data upload exercise. DPPLogic model 1.0.0 scores these six operational dimensions only.
Product data
Start with a clear product identity: model, variant, batch or serialisation level where relevant, category, market placement and the attributes held today. If two teams use different model names for the same item, passport preparation becomes unreliable quickly.
Supplier data
Identify which data must originate outside the business and which supplier or tier can provide it. Collection needs defined questions, deadlines, validation and escalation. A generic request for “all sustainability data” usually produces incomplete returns.
Traceability
Connect a product record to the relevant materials, components, facilities, batches or economic operators at the required level. More granularity is not automatically better if it cannot be maintained or evidenced.
Evidence and documents
Every significant data point should have a source, a date, a scope and a status. A document can be present but unsuitable: another variant, an expired method, a missing issuer, or a claim without supporting detail.
Systems and integration
Assess where data lives, how it is updated, and whether systems can exchange identifiers without manual re-entry. Earlier-stage programmes often get more value from controlled workflows before major technical investment.
Governance
Someone must own each field, decision and remediation task. Without named request, review, approval and change routes, a passport can look complete on launch day and become untrustworthy six months later.
Build a preparation record before publishing anything
The most effective sequence is usually to assess, evidence, remediate and then prepare passport records. Starting with the public-facing experience reverses the hard part.
First, select a representative product family rather than attempting the entire catalogue. Map its product data and list the information already held. Next, classify each item as available and evidenced, available but unverified, missing, or not yet determined by final product-specific rules. This simple status view prevents teams from treating every empty field as equally urgent.
Then create remediation actions with an owner, due date and expected evidence. A missing supplier declaration may require a procurement action. A product identifier mismatch may belong with master data. A claim supported only by an internal presentation may need a compliance or technical review. The action should state what will close the gap, not merely that a gap exists.
Finally, define publication controls. Before information is included in a passport record, check the applicable scope, evidence provenance, confidentiality position, approval status and version. QR codes and other data carriers can point users to information, but they do not validate its accuracy or prove that the underlying regulatory obligations have been met.
Standards and interoperability
Implementing Decision (EU) 2026/1736 cites six harmonised DPP standards for defined ESPR Article 10 and 11 requirements: data-exchange protocols, unique identifiers, data carriers, storage and persistence, APIs, and system interoperability. Using a cited harmonised standard can support presumption of conformity only for the requirements it covers. A published standard does not, by itself, create a product DPP duty or prove that product data is accurate.
Two further requested standards covering access-rights/security and data authentication/integrity were not treated as Official Journal-cited on 18 September 2026. GS1 Digital Link and similar identifier practices are implementation options unless a product-specific rule requires a named method.
Where tools help, and where they do not
Technology can make DPP preparation more manageable by structuring assessments, collecting supplier information, maintaining evidence registers and assigning remediation. DPPLogic helps teams assess readiness across the six operational dimensions and turn identified gaps into accountable preparation work.
A platform cannot create supplier evidence that does not exist, settle legal applicability for every product, or convert an AI suggestion into verified fact. AI can assist with classification, extraction and drafting where human review is built in. It should not be the sole basis for a regulated claim or a decision to publish product information. The public guidance and readiness assessment are deterministic. The DPPLogic workspace does not use runtime AI on your data: values, evidence references and review decisions are entered and made by people, on every plan. DPPLogic does not publish passports, and a general-purpose generative or regulatory assistant is not offered.
The same restraint applies to data completeness scores. They are useful management signals, especially when comparing product families or tracking remediation. They are not regulatory approval, legal certification or proof of compliance. DPPLogic model 1.0.0 and Quick Check qc-1.0.0 remain self-reported preparation tools.
Start with the gaps that would block progress
The next practical step is not to promise a finished passport date. Choose one product family, establish the relevant product and supplier evidence trail, and assign owners to the gaps that prevent a defensible record. That work remains valuable as requirements develop, because it replaces fragmented information with a maintainable basis for action.
Common misconceptions
- Common misconception
A QR code is a DPP. The carrier is the pointer; the passport is the governed data.
- Common misconception
A spreadsheet, inbox declaration or AI-generated description is a passport. Those may be inputs. They are not a controlled, retrievable record.
- Common misconception
ESPR means every product needs a passport now. ESPR is a framework. Product acts decide.
- Common misconception
Working Plan years for steel or textiles mean those DPPs are already mandatory. Planning windows are not application dates.
- Common misconception
The Registry holds all product data. Commission materials describe identifiers, registration data and high-level metadata in the Registry, with product information stored decentrally.
- Common misconception
A readiness score, QR generator or software licence proves compliance. None of those is a legal determination.
Primary and authoritative sources
Source links are provided for verification. Scope, consolidated versions and later measures should be checked again before implementation or reliance.
Regulatory disclaimer. This content provides general diagnostic and preparation information. It is not legal advice, certification or regulatory approval. Requirements may differ by product category, jurisdiction, market and supply-chain role and may change over time.