How Does a Digital Product Passport Work?
Executive Summary
A Digital Product Passport is often pictured as a QR code on a label. That picture is misleading. The code is only the doorway. What makes a passport work is the information flow behind it: how product data is created, collected from suppliers, validated, published against a persistent identifier, served to different audiences under different access rights, updated during the life of the product, and finally handed to whoever repairs, resells or recycles it.
This article sets out that flow as the Digital Product Passport Data Flow, a seven stage model that describes how a passport operates end to end. It then answers the architectural questions that come up in every implementation project: what the difference is between the physical product, the identifier and the passport, where the data physically lives, whether a single database is required, how access rights are enforced, how information changes over time, and what role APIs and interoperability standards play.
Throughout, regulatory requirements are kept separate from common technical implementation patterns. The European legislation fixes outcomes, not products or platforms. Where something is a widely used pattern rather than a legal obligation, this article says so.
It follows What is a Digital Product Passport?, Who Needs a Digital Product Passport? and What Information Does a Digital Product Passport Contain?.
- A Digital Product Passport is an information flow, not a file and not a label. - The flow has seven stages: product creation, supplier data collection, data validation, passport publication, market access, lifecycle updates and end of life. - The physical product, the product identifier and the passport record are three distinct things, and confusing them is the most common architectural error. - A data carrier such as a QR code resolves an identifier to a passport. It does not store the passport. - ESPR does not require a single central database. Data stays distributed and is reached through standard interfaces, with a Commission registry holding identifiers rather than full content. - Access rights are differentiated by user group and are enforced by whoever serves the data, not by the carrier. - Passport content changes over the life of the product, so versioning, provenance and retention have to be designed in from the start.
Traces the seven stages a passport passes through, from data capture to scan, resolution and presentation.
Table of Contents
- The Digital Product Passport Data Flow
- The Seven Stages in Detail
- Product, Identifier and Passport Are Three Different Things
- How QR Codes and Other Data Carriers Fit In
- Where Does the Data Physically Live?
- Must a Passport Be Stored in One Database?
- How Access Rights Work
- How Information Changes Through the Lifecycle
- Interoperability Between Systems
- The Role of APIs
- Common Architecture Misconceptions
- Practical Implementation Considerations
- Frequently Asked Questions
- Related Articles
- Related Glossary Terms
- References
- About This Article
- Page Metadata
- Related Docs
What the Law Actually Requires
ESPR fixes the operating properties of a passport rather than its technology. The passport must be connected to a persistent product identifier, reachable through a data carrier physically present on the product, packaging or documentation, based on open standards, interoperable, machine readable, structured and searchable. Data must remain available for a defined period even if the economic operator ceases trading, access must be differentiated by user group, and identifiers must be registered with a Commission registry. Which technology, which platform and which storage arrangement deliver those outcomes is left to the operator.
Two consequences follow, and they shape every architectural decision in this article. First, there is no mandated product, format or vendor. Second, the obligations are about behaviour over time: persistence, availability, accuracy and controlled access. A passport that renders beautifully on day one but cannot be updated, versioned or served to a recycler in 2035 does not meet the requirement.
The Digital Product Passport Data Flow
An educational framework describing how a Digital Product Passport operates end to end as an information flow across seven stages: product creation, supplier data collection, data validation, passport publication, market access, lifecycle updates and end of life. Each stage has a responsible party, an input, a quality gate and an output that the next stage depends on.
The framework exists because most implementation failures are not technical. They happen when an organisation treats the passport as an output to be generated at the end of a project, rather than as a flow that has to be operated continuously. The flow view makes the dependencies visible: you cannot validate data you have not collected, you cannot publish data you have not validated, and you cannot update a passport after sale unless publication was designed to allow it.
Product identity is established and core product data is created
Material, component and compliance data is collected from upstream suppliers
Information is checked for completeness, quality, provenance and compliance
The passport is created and associated with the product identifier and data carrier
Consumers, regulators, retailers and other authorised parties read the information they are entitled to see
Repair, maintenance, ownership, software and refurbishment information is added or updated
Recycling, reuse, remanufacturing and disposal information supports circular decisions
Lifecycle and end of life events feed back into validation, so the record stays accurate for as long as the product exists
The flow maps directly onto the earlier frameworks in this learning path. Stages 1 to 3 are where the six categories of the Product Information Readiness Model are assembled. Stage 4 is where Layer 4, the technology layer of the Four Layers of a Digital Product Passport, becomes visible. Stages 5 to 7 are where the Digital Product Passport Responsibility Model matters most, because the reader is no longer the manufacturer.
The Seven Stages in Detail
Stage 1: Product Creation
Identity comes first. Before any sustainability or compliance content exists, the product needs a persistent product identifier and a stable notion of what is being identified: a model, a batch or an individual item. That decision is difficult to reverse, because it determines how many passports exist and what a lifecycle event can be attached to.
Core product data is created alongside identity, usually in PLM or PIM systems: model and variant structure, technical characteristics, product category and the responsible legal entity.
Decide identity granularity before anything else. Model level passports are cheaper and adequate for many product groups. Item level passports are unavoidable when the passport must record repair history, ownership or warranty for a specific unit.
Stage 2: Supplier Data Collection
Most of the content an organisation does not already hold sits upstream: material composition, substances of concern, recycled content, country of origin, component level declarations and carbon data. Collection is the longest lead time activity in the entire flow, frequently measured in quarters rather than weeks, because it depends on contractual leverage and on suppliers who may themselves be several tiers away from the information.
A furniture brand needs recycled content percentages for the metal frame of a chair. Its direct supplier assembles the frame but buys tube stock from a mill in another country. The brand can only answer the question by pushing the request through two tiers, or by accepting a supplier declaration it cannot verify. The architecture must record which of those two happened, because a declared value and a verified value are not the same evidence.
Stage 3: Data Validation
Validation is the quality gate that separates a credible passport from a liability. Four checks matter: completeness against the applicable requirement set, quality against expected formats and ranges, provenance so every published claim links to a source and a date, and compliance against the delegated act for the product group.
Validate before publication, not after. A passport is a public statement made by the economic operator that places the product on the market. Correcting a wrong claim after publication means correcting a record that regulators, retailers and consumers may already have read and cached.
Stage 4: Passport Publication
Publication is the point at which validated data becomes a passport: a structured record bound to the product identifier, reachable through the data carrier, with access rules attached and the identifier registered with the Commission registry required by ESPR. In practice this stage also fixes the versioning model, because the published record is what everyone downstream will read.
Stage 5: Market Access
Access is where the passport does its work. A consumer scans a QR code and sees care, repair and durability information. A market surveillance authority queries the same identifier and sees conformity documentation. A recycler sees composition and disassembly information. One identifier, one record, different views.
Stage 6: Lifecycle Updates
After sale, information continues to arrive: repairs, spare parts fitted, software versions, ownership changes, refurbishment. ESPR anticipates that certain actors other than the manufacturer may be permitted to add information. Which actors, and to which fields, is set per product group.
Treating publication as the end of the project. A passport that cannot be updated after sale cannot support repair, resale or refurbishment, which are precisely the outcomes the regulation is designed to enable.
Stage 7: End of Life
At end of life, the passport becomes an input to someone else’s process. Recyclers need composition and hazardous substance information to sort and treat material safely. Remanufacturers need component identity. Reuse markets need provenance and condition history. This is where the circular economy rationale of the whole instrument is realised, and it only works if stages 1 to 6 preserved enough structure to be machine readable years later.
Product, Identifier and Passport Are Three Different Things
This is the single most useful distinction in passport architecture.
A physical or digital vehicle, such as a QR code, a data matrix or an RFID tag, that presents a product identifier so that it can be read by a person or a machine and used to reach the corresponding passport information.
Keeping these separate explains behaviour that otherwise looks contradictory. A label can be reprinted without creating a new passport. A passport can be corrected without touching the product. An identifier must survive both, which is why it should never encode business meaning that can become false, such as a factory code or a marketing name.
How QR Codes and Other Data Carriers Fit In
A carrier does one job: it makes an identifier readable. When a consumer scans a QR code, the code resolves to a web address that carries the identifier, a service interprets the identifier, decides who is asking, and returns the appropriate information.
GS1 standards are the most widely used approach in practice. GS1 Digital Link expresses an identifier as a structured web address, so one QR code can serve a consumer page, a regulator interface and a machine readable response depending on what is requested. Data matrix codes are common where space is limited, and RFID or NFC where scanning at distance or at speed matters.
Carriers are chosen per product group and are constrained by the delegated act, not by preference. Physical durability matters as much as data capacity: a carrier that is unreadable after two years of outdoor use fails the accessibility requirement even though the data behind it is perfect.
Assuming the QR code contains the passport. Encoding passport content directly into the carrier freezes the data at print time, which makes lifecycle updates impossible and defeats the purpose of the instrument. The carrier should carry the identifier, not the content.
Where Does the Data Physically Live?
In almost every real implementation, passport data does not live in one place. Identity and commercial attributes live in ERP and PIM. Engineering structure and bills of material live in PLM. Compliance documents live in document management. Supplier declarations live wherever the collection process put them. Lifecycle events arrive later from service and repair systems.
A passport service sits above these sources, assembles the published view, and serves it. Two patterns are common, and both are legitimate:
- Assemble and store. Validated data is copied into a passport record at publication time. The published record is a stable snapshot, which makes availability, auditability and long term retention straightforward.
- Assemble on request. The passport is composed from source systems when it is read. Data is never duplicated, but availability now depends on every source system remaining reachable for the full retention period.
Snapshot what must be provable, resolve live what must be current. Compliance claims and conformity evidence benefit from being frozen and versioned at publication. Repair status, ownership and software version are better read live. Most durable architectures mix the two rather than choosing one absolutely.
Must a Passport Be Stored in One Database?
No. ESPR does not require a central database of passport content. It requires that the information be findable through the identifier, available for a defined period, and accessible to the right parties. The Commission registry established by the regulation stores identifiers and related references so that authorities can locate passports, including at customs. It is a locator, not a content repository.
Believing that the European Union will operate one database holding every passport, and waiting for it before starting. The data stays with economic operators and their service providers. What is centralised is the ability to find it.
This distinction has a practical consequence. Because content is distributed, the burden of availability sits with the economic operator. ESPR expects passport data to remain reachable even if that operator ceases to trade, which is why arrangements such as escrow, delegated hosting or contractual continuity with a service provider belong in the architecture from the beginning rather than being discovered during due diligence.
How Access Rights Work
Different audiences see different subsets of the same record. The mechanism has three parts:
- Classification. Each attribute is assigned an audience: public, professional, authority or restricted. Classification is a data governance decision, not a coding decision.
- Identification. The service establishes who is asking. Public consumer views need no identification. Authority and professional views require authentication.
- Enforcement. Filtering happens where the data is served. It cannot be delegated to the carrier or the browser, because anyone can read a QR code.
A scan of the same code returns care and repair guidance to a consumer, disassembly and material composition to an authenticated recycler, full conformity documentation to a market surveillance authority, and a structured machine readable response to a retailer’s catalogue system. Nothing about the code changed. Only the caller did.
Publishing everything publicly because differentiated access seems complicated. Detailed composition, supplier identity and facility data are commercially sensitive, and once published they cannot be retracted from parties who have already retrieved them.
How Information Changes Through the Lifecycle
A passport is not static, so three mechanisms need to be designed explicitly:
- Versioning. Every published change should produce a new version with a timestamp and an author. Regulators may need to see the state of the record at the moment a product was placed on the market, not only its current state.
- Provenance. Each attribute should carry its source, its evidence and its date. This is what allows a declared supplier value to be distinguished from a tested one.
- Retention. The record must remain available for the period set by the applicable delegated act, which for durable goods can extend well beyond the commercial life of the product.
Design the update path before the first passport is published. Retrofitting versioning onto a system that only ever stored a current state is one of the most expensive corrections in this domain.
Interoperability Between Systems
Interoperability is an explicit legal requirement, and it operates at three levels.
- Syntactic. A common technical format so systems can parse each other’s data.
- Semantic. Shared vocabularies so that “recycled content” means the same thing to a manufacturer, a recycler and an authority.
- Organisational. Agreed rules about identification, access and trust between parties who have no commercial relationship.
The standardisation work supporting this sits mainly with CEN and CENELEC JTC 24, which is developing the European standards for passport data exchange, unique identifiers and system interoperability, alongside ISO and IEC work on identification and product traceability. The important editorial point is that these are standards being finalised, not a mandated platform. Building against open, widely adopted standards is a risk reduction strategy rather than a compliance shortcut.
The Role of APIs
APIs are how the passport becomes useful to systems rather than only to people. Four interfaces recur in practice:
- Ingestion. Bringing product, supplier and compliance data in from internal and upstream systems.
- Publication. Creating and updating passport records and binding them to identifiers.
- Resolution. Turning a scanned identifier into the right response for the right caller.
- Retrieval. Serving structured, machine readable content to retailers, recyclers, authorities and marketplaces.
Treat machine readable retrieval as a first class output, not an afterthought behind the consumer page. Retailers, marketplaces and recycling operators will consume passports through interfaces, and a human oriented page alone does not satisfy the requirement that passport data be structured, searchable and machine readable.
Common Architecture Misconceptions
Practical Implementation Considerations
Start with the flow, not the interface. Decide identity granularity, name an owner for each of the seven stages, and prove that data can move from supplier to validated record before choosing how the consumer page should look. The presentation layer is the cheapest part to change later; the identity model is the most expensive.
Practical sequence that works for most organisations:
- Fix identity granularity and the identifier scheme, and confirm it survives repackaging and relabelling.
- Map each of the six information categories to a source system and a named owner.
- Start supplier data collection immediately, because it gates everything downstream.
- Define the validation gate, including what evidence a claim must carry to be publishable.
- Choose carriers per product group against physical durability as well as data needs.
- Classify every attribute by audience before building any access control.
- Design versioning, provenance and retention before the first publication.
- Expose machine readable retrieval alongside the human readable view.
- Plan continuity so passports remain available if systems, suppliers or the business change.
Pilot with one product family end to end, through all seven stages including a simulated lifecycle update, rather than piloting stage 4 across a whole catalogue. The failures worth discovering early are in collection, validation and updating, not in rendering.
Frequently Asked Questions
Does a Digital Product Passport have to be online at all times?
ESPR requires passport data to be accessible to the relevant parties and to remain available for a defined period, including in circumstances where the economic operator ceases trading. Continuity arrangements are therefore an architectural requirement, not an operational nicety.
Can several companies write to the same passport?
Potentially, yes. ESPR anticipates that actors other than the manufacturer may be permitted to add lifecycle information, such as repairers or refurbishers. Which actors and which fields are determined by the delegated act for the product group, and the operator remains accountable for the record as a whole.
Is GS1 Digital Link mandatory?
No. It is a widely adopted open standard that satisfies the identifier and carrier requirements well, and it is the dominant pattern in retail supply chains. The legislation requires open standards and interoperability rather than a named scheme.
What happens when a product is repackaged or relabelled?
The identifier must remain persistent for the product it identifies. A new label is a new carrier, not a new passport. If the relabelling changes the product identity itself, for example a new model, that is a different product and requires its own passport.
How does a passport work at customs?
Customs and market surveillance authorities can use the identifier registered in the Commission registry to locate the passport and check the required information at the point of entry, which is why registration of identifiers is a distinct obligation from publishing the content.
Related Articles
- What Information Does a Digital Product Passport Contain?
- What is a Digital Product Passport?
- Who Needs a Digital Product Passport?
- Digital Product Passport
- What is GS1?
- How Will Digital Product Passports Change Product Compliance?
- What Are Delegated Acts?
- What is a Data Carrier?
Related Glossary Terms
Definitions of record for the terms used above live in the glossary.
- Digital Product Passport
- Product Identifier
- Data Carrier
- QR Code
- GS1
- GS1 Digital Link
- ESPR
- Delegated Act
- Economic Operator
- Market Surveillance
- Product Data
- Product Lifecycle
- Product Traceability
- Circular Economy
References
- Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products (ESPR), Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
- Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2023/1542/oj
- European Commission, Ecodesign for Sustainable Products Regulation policy pages: https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en
- European Commission, ESPR working plan 2025 to 2030: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187
- CEN-CENELEC Joint Technical Committee 24 (JTC 24), Digital Product Passport standardisation work programme: https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/digital-product-passport/
- GS1, Digital Link standard: https://www.gs1.org/standards/gs1-digital-link
- ISO/IEC 15459, Information technology, Automatic identification and data capture techniques, Unique identification: https://www.iso.org/standard/54779.html
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.