There is no single universal workflow for creating a Digital Product Passport. First determine whether an adopted instrument requires one for that product, then follow that act’s data, identifier, carrier, access and registration rules. Collect evidence, distinguish source data from verified data, structure the record, attach a data carrier if required, and keep the data accurate after any publication the act requires. Creating a QR code, uploading a PDF, publishing a web page, or filling one universal EU template is not creating a DPP. The EU DPP Registry records registration data; it does not store the full product file. DPPLogic does not generate, host or register passports. This is general guidance, not an implementation certificate.
What this guide covers
This guide covers the order of the work: who does what at each step, what goes in, what comes out, and where implementations usually fail. To check whether a passport applies to your product, start with Who needs a Digital Product Passport. For the data and evidence to prepare, see Digital Product Passport data requirements. Duties by role are on the manufacturer, importer and exporter guides.
A regulation-first sequence
These steps are a preparation order. Skip or expand them only when the applicable act says so. Product-specific requirements are not all finalised. Working Plan years are not application dates. DPPLogic does not currently generate, host or register passports.
- Determine whether a DPP is relevant
- Identify the applicable product-specific rules
- Identify required product data
- Map who owns each field
- Identify supplier dependencies
- Collect evidence and distinguish source from verified data
- Handle missing or conflicting information
- Structure the passport record
- Separate public and restricted information
- Prepare identifier, carrier and QR work
- Validate the dataset and assign updates
- Prepare for publication or Registry work only when required
- Maintain the record
A QR code is not a Digital Product Passport
A data carrier points to an identifier. The identifier retrieves the passport data. Access rights decide who sees which fields. The record must stay accurate, complete and up to date for the period the act requires. A QR code is one common carrier. ESPR Article 10 treats the carrier more broadly than a QR code and asks for open, interoperable, machine-readable formats without vendor lock-in.
Printing a code onto packaging does not create the underlying data, the access rules, the registry entry or the legal duty.
- Common misconception
Creating a QR code is not creating a compliant DPP.
- Common misconception
GS1 Digital Link is a widely used identifier syntax; it is not the only legally possible route unless the applicable act says so.
- Common misconception
Registry registration is not the same as storing the full product file in a central EU database.
1. Determine whether a DPP is relevant
ESPR does not create a general duty for every product sold in the EU. A Digital Product Passport is required only where an adopted instrument imposes one for that product. Confirm the product class, whether it is placed on the Union market or put into service, the actor role, and whether a DPP article has been adopted.
Use the existing applicability checker. Do not start by buying software or a QR package.
2. Identify the applicable product-specific rules
Cite the instrument, the product class in that act, and the application date. Battery Article 77 is enacted for specified classes from 18 February 2027. Most ESPR groups still await a product-specific delegated act. Inclusion on the Working Plan is not a duty.
If the act is not adopted, record requirement developing and continue with data ownership — not a fake deadline.
3. Identify required product data
Do not copy ESPR Annex III as a mandatory list. The applicable act decides which fields, granularity and units apply. For specified batteries, Annex XIII is the field source — and not every item is due for every battery on the same day.
4–5. Map field owners and supplier dependencies
For each candidate field record: internal owner, source system, supplier dependency, and whether the value is known. A non-EU factory does not automatically become the legally responsible importer. Contractual customer requests can still arrive before a product-specific duty applies.
6–8. Evidence, verification and conflicts
Separate the originating value from the file that supports it. A received supplier cell is not a verified field. Date, scope, version and reviewer stay visible. Conflicting chemistry, capacity or identifier rows stay open until a named person reconciles them. Do not invent a value to close a gap.
| State | Meaning | Do not |
|---|---|---|
| Source | Originating system or document | Treat as verified |
| Evidence | Dated, scoped supporting file | Keep only in a personal inbox |
| Review | Named acceptance for a stated scope | Equate received with true |
| Passport field | Value that may be published if the act requires it | Publish an unverified gap |
9–11. Structure, access and the data carrier
Structure the approved fields as a machine-readable record, not a brochure PDF labelled as a DPP. Public access to a required passport does not make every technical record public. The applicable act and any access-rights measure decide who sees which fields.
Prepare the identifier and carrier only after the product class and granularity are known. ESPR Article 10 treats the carrier more broadly than a QR code.
12–13. Validate the dataset and assign updates
Check identifiers for collision, units for consistency, evidence for expiry, and access labels against the intended audience. Name who may change a field after first publication. A record with no update owner is not ready.
14–15. Publication, Registry and maintenance
The Commission DPP Registry User Guide for Economic Operators (DG GROW, last published 24 August 2026, v1.02) states that only verified economic operators may register and manage Digital Product Passports under Regulation (EU) 2024/1781. Enrolment uses EU Login and organisation verification, including a Commission-sealed PDF that the operator countersigns or counterseals. Registration then needs a Unique Product Identifier that resolves to hosted DPP data.
Implementing Regulation (EU) 2026/1778 describes a decentralised product-data model: the Registry holds registration data; the detailed file stays with the operator or service provider. Registry availability is not a finding that every product already has an adopted DPP duty. DPPLogic does not enrol organisations or register passports.
After any required publication, keep the data accurate, complete and up to date for the period the act requires. No process after go-live is a common failure.
Responsibility matrix
These are typical roles, not a legal allocation for a specific product.
| Work item | Typical placing operator | Typical supplier / non-EU factory | Notes |
|---|---|---|---|
| Decide whether a DPP is required | Owns the decision before placing | Supplies product facts | Start with the applicability checker |
| Required DPP creation and accuracy | Primary responsibility | Upstream inputs | Commission operator guidance, 11 September 2026 |
| Article 27 duties when an ESPR product measure applies | Placing manufacturer | Not automatic by nationality | Current law |
| Article 29 importer checks | EU importer | Not automatic | Current law |
| Article 10(4) back-up | Manufacturer creates; importer checks | A worksheet is not the back-up | Current law |
| Evidence files | Owns the request and gap list | Returns dated, scoped files | See supplier data collection |
| QR / carrier artwork | Owns identifier and access path | May print a specified mark | A QR code is not the passport |
What each step needs
- Map data, evidence and supplier dependencies with the preparation checklist
- Define supplier requests and resolve evidence gaps
| Step | Input | Output | Common failure |
|---|---|---|---|
| Applicable legislation | Product class, market, role | Cited instrument and status | Treating a Working Plan year as a duty |
| Product-specific requirements | The adopted act | Data, carrier, access, date | Copying Annex III as a mandatory list |
| Identifiers | SKU, model, batch or item decision | Persistent unique identifier | Reused or colliding codes |
| Information map | Act plus internal dictionary | Field, source, owner | Marketing names instead of legal fields |
| Evidence | Certificates, tests, declarations | Linked, dated, scoped files | Personal inboxes as the register |
| Missing data | Gap list | Owned requests and exceptions | Buying software to hide the gaps |
| Structure the record | Approved fields and versions | Machine-readable product record | A PDF brochure labelled as a DPP |
| Carrier and access | Act plus audience | Carrier, placement, rights | One public page for every actor |
| Roles | Operator map | Who may publish or update | Assuming every supplier holds the legal file |
| Publish and maintain | Approved record | Retrievable, correctable history | Treating Registry login as the product file |
Worked examples — not determinations
ILLUSTRATIVE / SYNTHETIC. These scenarios explain the sequence. They are not legal advice and not a finding about any real SKU.
Non-EU factory plus EU placing brand: an LMT battery made outside the EU and placed in France in 2027 under an EU company’s name. The EU company is typically the placing manufacturer. The factory should expect contractual data and evidence requests. Article 77 may require a battery passport for that class from 18 February 2027. The QR mark is a separate Article 13(6) duty.
Apparel on the Working Plan: no textiles delegated act adopted. Record product group prioritised / requirement developing. Prepare data ownership. Do not claim a 2027 or 2028 apparel DPP deadline.
If you cannot say who places the SKU or under whose name: more information required. Do not buy a QR package to close that gap.
Build, buy or hybrid
Internal systems
Fits when product volume is high, ERP/PIM/PLM already holds structured data, and you can staff evidence, access and monitoring. Cost is mostly people and integration, not a licence headline.
Commercial DPP software
Fits when you need a faster record, carrier or registry interface and can still own applicability and evidence. Do not buy a generator to decide whether a duty exists.
Integrate a layer
Fits most mid-size programmes: keep product master data where it already lives; add supplier, evidence or publication tools only for the missing layer.
Implementation considerations
Product volume, ERP/PIM/PLM maturity, supplier complexity, data governance, regulatory monitoring, evidence control, integration and maintenance all change the mix. There is no reliable public price table that maps those variables to a lawful outcome. Do not treat vendor “from €X/month” pages as a compliance budget.
If the product group is only on the Working Plan, the honest work is data ownership and monitoring — not a claim that a passport has a fixed application date. As of 11 September 2026 the iron-and-steel delegated act was not identified as adopted. Battery Article 77(9) access details remain open. Specified battery passports still apply from 18 February 2027 for the Article 77 classes.
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.