What is a Digital Product Passport?

Executive Summary

A Digital Product Passport (DPP) is a structured, machine readable set of product data that is accessible through a data carrier physically attached to a product, its packaging or its documentation. The legal basis in the European Union is Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation (ESPR), which entered into force on 18 July 2024.

ESPR sets the framework: it establishes that passports will exist, what technical properties they must have, and who is responsible for them. It does not, on its own, define the data every product must carry. The specific data fields, the applicable data carrier and the access rights per user group are set product group by product group through delegated acts. The first of these are progressing under the ESPR working plan, with batteries following a separate and earlier track under Regulation (EU) 2023/1542.

This article is written for manufacturers, compliance teams, technology teams and consultants who need an accurate picture of what is already fixed in law and what is still being defined. The single most important takeaway: the obligation to hold a passport is confirmed, the per product data model is not, and the work that pays off today is product data governance rather than early commitment to a specific field list.

Key Takeaways
  • Every Digital Product Passport has four layers: regulatory, governance, information and technology. Programmes fail when they build one layer and assume the rest. - ESPR (Regulation (EU) 2024/1781) is the regulatory layer’s framework; the binding data requirements arrive through delegated acts per product group. - Batteries are the first regulated case, under Regulation (EU) 2023/1542, from 18 February 2027. - The governance layer decides accountability: the economic operator placing the product on the EU market owns passport accuracy and availability. - The information layer is the hard part and the slowest to build. The technology layer is the visible part and the fastest to change. - Preparation that holds its value under any delegated act: unique identification, supplier data collection, and data quality governance.
FrameworkTBF-001
The Four Layers of a Digital Product Passport

Separates a passport into regulatory, governance, information and technology layers so programmes can see which layer they have actually built.

Table of Contents

Definition

Definition
Digital Product Passport (DPP)

A product specific set of data, specified in a delegated act adopted under ESPR, that is accessible electronically through a data carrier and linked to a unique product identifier. The passport makes information about a product, its components, its materials and its compliance available to defined groups of users, including consumers, economic operators, repairers, recyclers and market surveillance authorities.

Three properties distinguish a passport from other forms of product information. Where a term below is defined formally, it links to its glossary entry.

  1. It is identified. Each passport is bound to a unique product identifier, and to a unique operator identifier and unique facility identifier where the delegated act requires them.
  2. It is machine readable. Data is structured and interoperable, so it can be read by systems and not only by people.
  3. It is access controlled. Different user groups receive different subsets of the data. Public information is available to anyone who scans; restricted information is available only to authorities or to specified operators.

The Four Layers of a Digital Product Passport

The most useful way to think about a passport is not as a feature or a file, but as four layers that have to be built and maintained together. Each layer answers a different question, is owned by a different part of the organisation, and moves at a different speed.

Layer 1: Regulatory

The regulatory layer establishes that a passport must exist, for which products, from which date, and with which enforcement consequences. In the EU it is set by ESPR (Regulation (EU) 2024/1781) as the framework, by delegated acts per product group for the detail, and by separate instruments such as Regulation (EU) 2023/1542 for batteries and Regulation (EU) 2024/3110 for construction products.

This layer is not under your control and it is not yet complete. That is a planning constraint, not a reason to wait: the framework obligations are fixed even where the field lists are not.

Layer 2: Governance

The governance layer decides who owns each attribute, who is allowed to change it, who approves publication, who may read which subset, and how long the record must survive. Legally, the economic operator placing the product on the EU market carries the obligation. Operationally, the data originates across product development, quality, procurement, sustainability and suppliers.

Governance is the layer most often skipped, because it produces no visible artefact. It is also the layer that determines whether the passport stays accurate after the launch project ends.

Layer 3: Information

The information layer is the structured product data itself: identity, composition, substances of concern, durability, repairability, conformity and end of life handling. It is also where product traceability and sustainability data meet, because most of it either does not exist yet, exists only as unstructured documents, or sits with a supplier who has never been asked for it.

This layer is also the most durable investment. A governed, complete, well sourced data set can be mapped to whichever field list a delegated act eventually specifies.

Layer 4: Technology

The technology layer makes the information reachable and machine readable: unique identifiers, data carriers such as QR codes carrying a GS1 Digital Link URI, a resolver that routes a scan to the correct passport view, and APIs that let other systems consume the record. ESPR requires this layer to be based on open standards, interoperable, and free of vendor lock in.

It is the fastest layer to build and the easiest to replace. It is therefore the wrong layer to start with, and the wrong layer to judge a programme by.

Best Practice
Read the layers top down, build them bottom up in value

Scope from the regulatory layer, because it defines what must be true. Assign the governance layer before collecting anything, because unowned data decays. Spend the majority of the programme on the information layer. Treat the technology layer as configuration, not as the project.

Why Digital Product Passports Are Being Introduced

The policy driver is the circular economy. The European Commission’s position is that a large share of a product’s lifecycle environmental impact is determined at the design stage, and that decisions about repair, reuse, remanufacture and recycling are currently blocked by missing information.

Four concrete information failures are being addressed.

FailureConsequence todayWhat a passport changes
Material composition opaqueRecyclers cannot sort or separate reliably, so material value is lostComposition data travels with the product to end of life
Repair data unavailableProducts are discarded when a spare part or procedure would have sufficedRepairers can retrieve part references and instructions
Claims unverifiableSustainability claims are hard to substantiate or to challengeClaims are anchored to structured data that can be checked
Fragmented compliance dataThe same data is requested repeatedly in different formatsOne structured record serves consumers, operators and surveillance authorities

There is also an enforcement dimension. ESPR gives market surveillance authorities and customs access to passport data, which makes non compliant products easier to identify at the border and in the market.

Regulatory Context

Regulation Summary
Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781
Jurisdiction
European Union
Status
In force as framework legislation; product requirements pending delegated acts
Applies from
18 July 2024 (entry into force)

ESPR replaces the 2009 Ecodesign Directive and extends it from energy related products to almost all physical goods placed on the EU market. It establishes the Digital Product Passport as a horizontal instrument and sets its technical, operational and governance requirements. Binding data content is set separately, per product group, in delegated acts.

What is confirmed in the framework itself:

  • The passport must be connected to a persistent unique product identifier and accessible through a data carrier.
  • Data must be accurate, complete and up to date, and the economic operator placing the product on the market is responsible for it.
  • The passport must remain available for a period defined in the applicable delegated act, including after an operator ceases trading, which is why a backup mechanism is required.
  • Data must be interoperable, based on open standards, and free of vendor lock in.
  • A Commission operated registry will store passport identifiers; customs authorities will be able to verify them.

What is not yet confirmed for most product groups:

  • The exact list of mandatory data attributes.
  • The required data carrier type and its placement.
  • The access rights matrix per user group.
  • The retention period.
  • The compliance date.

Two adjacent instruments matter for scoping. Regulation (EU) 2023/1542 introduces a battery passport for LMT batteries, industrial batteries above 2 kWh and electric vehicle batteries from 18 February 2027, on its own legal basis. Regulation (EU) 2024/3110 introduces a separate digital product passport system for construction products. Neither is governed by an ESPR delegated act, so requirements should be read from the relevant regulation directly.

Example
Reading the timeline correctly

A textiles manufacturer reading in 2026 that textiles are a priority product group under the first ESPR working plan should conclude that a passport obligation is coming and that the data model is not yet fixed. The correct action is to establish product level identification and supplier data collection now, and to defer field level mapping until the textiles delegated act is adopted.

What Information a Digital Product Passport Contains

The precise content is set per product group. The categories below reflect what ESPR allows to be required and what appears in the battery regulation and in current draft work. Treat them as the shape of the requirement, not as a confirmed field list for any specific product.

CategoryTypical contentPrimary audience
Product identificationUnique product identifier, model, batch or serial, manufacturer identifiersAll users
Compliance and conformityDeclarations of conformity, applicable standards, certifications, test dataAuthorities, importers, distributors
Materials and substancesMaterial composition, recycled content, substances of concernRecyclers, authorities
Environmental performanceDurability, carbon or environmental footprint where requiredConsumers, procurement teams
Repair and maintenanceSpare part references, disassembly and repair instructions, availabilityRepairers, consumers
End of lifeCollection, take back, recycling and disposal guidanceRecyclers, waste operators
Supply chain and provenanceFacility identifiers, origin data where required by the product groupAuthorities, downstream operators

Access is tiered. A consumer scanning a code sees the public subset. A recycler or an authority may be granted access to restricted attributes such as substances of concern or full composition. The tiering is defined in the delegated act, not chosen freely by the operator.

How a Digital Product Passport Works

Within the technology layer, four stages make a passport reachable in practice.

1

Identification

Each product, batch or item receives a unique identifier. In practice this is most often a GS1 identifier such as a GTIN, extended with batch or serial keys where item level granularity is required.

2

Data carrier

The identifier is encoded in a carrier attached to the product, its packaging or its documentation. A QR code carrying a GS1 Digital Link URI is the most common approach; NFC and RFID are used where the product or process justifies them.

3

Resolution

Scanning the carrier produces a URL. A resolver service maps that URL to the correct passport, and can route different requesters to different destinations, for example a consumer view, a machine readable representation, or a recycler view.

4

Data service

The resolved passport is served from a data service that holds the structured record, enforces access rights, keeps a version history, and exposes both a human readable rendering and a machine readable representation.

Two properties of this architecture are frequently underestimated.

The identifier must be persistent. It has to keep resolving for the full retention period, which may extend well beyond the commercial life of the product and beyond the life of the company. ESPR therefore requires a backup arrangement so that passports survive an operator ceasing activity.

The record should be immutable per publication. When product data changes, the correct pattern is to publish a new passport version and retain the previous one, so that a passport scanned in the past can still be reconstructed. Overwriting data in place destroys the audit trail that authorities and downstream operators depend on.

On the tieback platform these four layers map to product master data, carrier generation, the resolver, and published passport snapshots. The same separation applies to any competent implementation; it is not specific to one vendor.

Who Will Be Affected

Responsibility sits with the economic operator that places the product on the EU market. That is a broader group than manufacturers alone.

  • EU manufacturers are responsible for the passports of products they place on the market.
  • Importers carry the obligation for goods they bring into the EU, including goods made by non EU manufacturers.
  • Authorised representatives may hold the obligation where a non EU manufacturer has appointed one.
  • Non EU manufacturers are affected commercially even without a direct obligation, because their EU customers cannot comply without upstream data.
  • Distributors and retailers must verify that the passport is present and accessible before making a product available.
  • Suppliers of components and materials are affected through data requests from their customers, since composition and provenance data originates upstream.
  • Repairers, recyclers and waste operators are data consumers, and are the intended beneficiaries of the repair and end of life sections.

Micro enterprises may receive exemptions or lighter requirements, but this is determined in each delegated act rather than granted horizontally by ESPR.

Digital Product Passport vs QR Code

This is the most common conceptual error in early programmes. A QR code is a data carrier. A passport is the data, the identifier, the access rules and the service that delivers them. The QR code is one visible component of the passport, and the easiest one to implement.

AspectQR codeDigital Product Passport
NatureEncoding of a string, usually a URLStructured data record plus identifier and access rules
ContentCarries no product data itselfCarries the regulated data set
Machine readingYields a URLYields structured, interoperable data
Access controlNoneTiered by user group
PersistencePrinted onceMust remain resolvable for a defined retention period
VersioningNot applicableVersion history required in practice

A programme that stops at generating QR codes that point to an existing product page has built the carrier and none of the passport.

Digital Product Passport vs PDF

A PDF is a document intended for human reading. A passport is a data set intended for both human and machine consumption. The distinction has practical consequences.

  • A PDF cannot be queried by attribute, so a recycler cannot ask for the polymer type without reading the whole document.
  • A PDF has no access tiering, so restricted data cannot be separated from public data within one artefact.
  • A PDF has no reliable update path once distributed; passports require the served record to reflect the current published version.
  • A PDF is not interoperable in the ESPR sense, which requires open standards and structured data.

PDFs remain legitimate as attachments inside a passport, for example the declaration issued after conformity assessment or a repair manual. They cannot be the passport.

Why Organisations Get DPP Projects Wrong

Most failed or stalled passport programmes fail for the same reason: they build one layer and assume the other three will follow. The five patterns below account for the large majority of the damage.

Common Mistake
Treating the passport as a QR code

Teams print codes that resolve to an existing marketing page and record the programme as complete. This is the technology layer alone. None of the regulated requirements, structured data, access tiering, persistence and versioning, have been met, and none of the information layer exists.

Common Mistake
Treating the passport as a PDF

Publishing a specification sheet or declaration behind a scan looks like compliance and is not. A document cannot be queried by attribute, cannot separate public from restricted data, and cannot be kept current in the hands of everyone who downloaded it. PDFs belong inside a passport as attachments, never as the passport.

Common Mistake
Starting with technology rather than product data

Selecting a platform first makes the programme feel like it is moving, then stalls it for a year while the data to publish is assembled. The technology layer takes weeks. The information layer takes quarters. Sequence accordingly.

Common Mistake
Ignoring governance

Without named owners, approval steps, access rules and retention decisions, the passport is accurate on launch day and drifts from then on. Because the record is publicly resolvable, that drift becomes regulatory exposure rather than an internal data quality issue.

Common Mistake
Waiting for every delegated act before preparing

The field list is unknown; identification, supplier data collection and data governance are not. Organisations that wait compress years of upstream data work into the compliance window, at the point when every competitor is asking the same suppliers for the same information.

Common Mistake
Assuming one data model fits all products

Requirements are set per product group. A textiles passport and a battery passport differ in legal basis, content and timing. A single hardcoded schema will not hold.

Common Mistake
Overwriting passport data in place

Editing a published record destroys the ability to reconstruct what a scan returned at a given date. Publish new versions and retain the old ones.

Common Mistake
Choosing an identifier that cannot persist

Identifiers built on a current domain, a vendor URL or an internal ERP key create a migration problem later. The identifier must outlive the system that issued it.

Preparing for Digital Product Passports

Best Practice
Build the data foundation before the data model

Delegated acts will change the field list; they will not change the need for unique identification, reliable supplier data and controlled data quality. Sequence the work so that the foundation is ready and the field mapping is the last, cheapest step.

Seven workstreams make up a defensible preparation programme. They can run in parallel, but the first three determine whether the rest are possible.

1. Product data readiness

Inventory what you already hold against the attribute categories above. For each attribute record where it lives, which system is authoritative, how current it is, and whether it exists at all. Most organisations discover that the data exists in fragments across PLM, ERP, quality documents and spreadsheets, with no single accountable version.

2. Supplier data

Composition, provenance and substance data originates upstream, often at tier two and tier three. Start structured collection now: define the request format, put the obligation into contracts and supplier onboarding, and expect several rounds before the data is usable. This is almost always the critical path.

3. Governance

Assign an owner per attribute domain, define who approves publication, and decide the access tiering you will need for public, operator and authority audiences. Governance decisions made before data collection cost far less than governance retrofitted onto a live passport estate.

4. Existing enterprise systems

Decide where the passport record is assembled rather than duplicated. PLM, ERP, PIM and QMS each hold part of the truth. The goal is a defined flow from the authoritative system to the published passport, not a parallel data set that has to be reconciled by hand.

5. Identifiers

Choose the granularity you need, model, batch or item, and assign persistent identifiers, typically GS1 keys such as a GTIN extended with batch or serial. Item level serialisation is far harder to retrofit than to design in, and the identifier must remain resolvable beyond the life of the product and of the issuing system.

6. Data quality

Passport data is published data. Errors that are tolerable inside a PLM record become public and enforceable once resolvable. Put validation, completeness checks and unit and vocabulary standardisation in place before the first passport is published, not after the first correction.

7. Compliance monitoring

Track the ESPR working plan and the delegated acts relevant to your product groups, and keep an internal register mapping each product family to its expected obligation and date. Add a review cycle so that adopted acts trigger a mapping exercise rather than a new programme.

Example
Where the effort usually lands

In most first programmes, generating carriers and serving passports is a small share of the effort. The large share is obtaining material composition and provenance data from tier two and tier three suppliers who have never been asked for it in a structured form. Starting supplier engagement early is the highest leverage decision available.

Example
A workable first year

Quarter one: scope the regulatory layer and stand up governance. Quarter two: audit product data and begin supplier collection. Quarter three: assign identifiers and run one product family end to end through carrier, resolution and publication. Quarter four: harden data quality and formalise compliance monitoring. Field level mapping follows the delegated act.

Frequently Asked Questions

The framework is in force, but the obligation attaches per product group through delegated acts. The first binding case is the battery passport under Regulation (EU) 2023/1542, which applies from 18 February 2027. For other product groups, the compliance date follows the adoption of the relevant ESPR delegated act.

ESPR applies to almost all physical goods placed on the EU market, with limited exclusions such as food, feed and medicinal products. Coverage is phased: priority product groups are addressed first under the ESPR working plan, and each group is brought in by its own delegated act.

That is determined by the delegated act for your product group and is not yet fixed for most products. Plan against the categories described above, and treat any published field list as indicative until the act is adopted.

The applicable data carrier is specified per product group. QR codes carrying a GS1 Digital Link URI are the most common expectation, and the battery regulation points in this direction, but NFC and RFID are permitted carrier technologies where specified.

The economic operator that places the product on the EU market. For imported goods that is normally the importer, not the non EU manufacturer.

The retention period is set in the applicable delegated act. ESPR additionally requires a backup arrangement so that passports remain accessible if the responsible operator ceases activity.

Not necessarily. Access is tiered by user group. Sensitive attributes such as full composition can be restricted to authorities or specified operators while a public subset is shown to consumers. The tiering is defined by the delegated act.

Establish unique identification, start structured supplier data collection, and put data quality governance in place. These are prerequisites under every plausible field list.

The glossary holds the definition of record for the terms used above.

References

About This Article

tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve.

Page Metadata

FieldValue
Published2026-08-07
Last Reviewed2026-08-07
Reading Time12 min
Difficultybeginner
Authortieback
CategoryDigital Product Passports
TagsDigital Product Passport, DPP, ESPR, EU Product Compliance, Product Traceability, Circular Economy