> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # What is a Digital Product Passport? > A practical, authoritative introduction to Digital Product Passports: what they are, why the EU is introducing them, what data they carry, who is affected, and how they work. ## Executive Summary A [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) (DPP) is a structured, machine readable set of [product data](/docs/knowledge-base/glossary/product-data) that is accessible through a [data carrier](/docs/knowledge-base/glossary/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)](/docs/knowledge-base/glossary/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](/docs/knowledge-base/glossary/delegated-act). 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](/docs/knowledge-base/glossary/data-governance) rather than early commitment to a specific field list. * 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. Framework TBF-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) * [The Four Layers of a Digital Product Passport](#the-four-layers-of-a-digital-product-passport) * [Why Digital Product Passports Are Being Introduced](#why-digital-product-passports-are-being-introduced) * [Regulatory Context](#regulatory-context) * [What Information a Digital Product Passport Contains](#what-information-a-digital-product-passport-contains) * [How a Digital Product Passport Works](#how-a-digital-product-passport-works) * [Who Will Be Affected](#who-will-be-affected) * [Digital Product Passport vs QR Code](#digital-product-passport-vs-qr-code) * [Digital Product Passport vs PDF](#digital-product-passport-vs-pdf) * [Why Organisations Get DPP Projects Wrong](#why-organisations-get-dpp-projects-wrong) * [Preparing for Digital Product Passports](#preparing-for-digital-product-passports) * [Frequently Asked Questions](#frequently-asked-questions) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) * [About This Article](#about-this-article) ## Definition 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](/docs/knowledge-base/glossary/overview) entry. 1. It is identified. Each passport is bound to a unique [product identifier](/docs/knowledge-base/glossary/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 Why the passport exists ESPR, delegated acts, product group legislation, enforcement Layer 2 Governance Who is accountable Ownership, data stewardship, approval, access rights, retention Layer 3 Information What the passport says Product, material, durability, repair and compliance data over the lifecycle Layer 4 Technology How it is reached Identifiers, data carriers, GS1 Digital Link, resolvers, APIs, interoperability ### 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](/docs/knowledge-base/glossary/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](/docs/knowledge-base/glossary/product-traceability) and [sustainability data](/docs/knowledge-base/glossary/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](/docs/knowledge-base/glossary/gs1-digital-link) URI, a [resolver](/docs/knowledge-base/glossary/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. #### 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](/docs/knowledge-base/glossary/circular-economy). The European Commission's position is that a large share of a product's [lifecycle](/docs/knowledge-base/glossary/product-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. | Failure | Consequence today | What a passport changes | | --------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Material composition opaque | Recyclers cannot sort or separate reliably, so material value is lost | Composition data travels with the product to end of life | | Repair data unavailable | Products are discarded when a spare part or procedure would have sufficed | Repairers can retrieve part references and instructions | | Claims unverifiable | Sustainability claims are hard to substantiate or to challenge | Claims are anchored to structured data that can be checked | | Fragmented compliance data | The same data is requested repeatedly in different formats | One structured record serves consumers, operators and surveillance authorities | There is also an enforcement dimension. ESPR gives [market surveillance](/docs/knowledge-base/glossary/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 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. #### 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. | Category | Typical content | Primary audience | | --------------------------- | --------------------------------------------------------------------------- | ------------------------------------ | | Product identification | Unique product identifier, model, batch or serial, manufacturer identifiers | All users | | Compliance and conformity | Declarations of conformity, applicable standards, certifications, test data | Authorities, importers, distributors | | Materials and substances | Material composition, recycled content, substances of concern | Recyclers, authorities | | Environmental performance | Durability, carbon or environmental footprint where required | Consumers, procurement teams | | Repair and maintenance | Spare part references, disassembly and repair instructions, availability | Repairers, consumers | | End of life | Collection, take back, recycling and disposal guidance | Recyclers, waste operators | | Supply chain and provenance | Facility identifiers, origin data where required by the product group | Authorities, 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. #### Identification Each product, batch or item receives a unique identifier. In practice this is most often a [GS1 identifier](/docs/knowledge-base/glossary/gs1) such as a GTIN, extended with batch or serial keys where item level granularity is required. #### 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. #### 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. #### 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](/docs/knowledge-base/glossary/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. | Aspect | QR code | Digital Product Passport | | --------------- | ----------------------------------- | ------------------------------------------------------- | | Nature | Encoding of a string, usually a URL | Structured data record plus identifier and access rules | | Content | Carries no product data itself | Carries the regulated data set | | Machine reading | Yields a URL | Yields structured, interoperable data | | Access control | None | Tiered by user group | | Persistence | Printed once | Must remain resolvable for a defined retention period | | Versioning | Not applicable | Version 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](/docs/knowledge-base/glossary/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. #### 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. #### 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. #### 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. #### 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. #### 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. #### 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. #### 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. #### 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 #### 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](/docs/knowledge-base/glossary/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. #### 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. #### 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 #### Is the Digital Product Passport already mandatory? 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. #### Which products will be covered? 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. #### What data will my product need to carry? 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. #### Does the passport have to use a QR code? 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. #### Who is legally responsible for the passport? The economic operator that places the product on the EU market. For imported goods that is normally the importer, not the non EU manufacturer. #### How long must a passport remain available? 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. #### Does a passport expose commercially sensitive data? 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. #### What should we do now if our product group has no 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. ## Related Articles * [Who Needs a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/who-needs-a-digital-product-passport) * [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) * [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work) * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts) * [What is the Ecodesign for Sustainable Products Regulation (ESPR)?](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr) * [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory) * [What Are the Benefits of a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-are-the-benefits-of-a-digital-product-passport) ## Related Glossary Terms The [glossary](/docs/knowledge-base/glossary/overview) holds the definition of record for the terms used above. * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [ESPR](/docs/knowledge-base/glossary/espr) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [GS1 Digital Link](/docs/knowledge-base/glossary/gs1-digital-link) * [Product Data](/docs/knowledge-base/glossary/product-data) ## 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](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](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * Regulation (EU) 2024/3110 laying down harmonised rules for the marketing of construction products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/3110/oj](https://eur-lex.europa.eu/eli/reg/2024/3110/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](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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187) * GS1, Digital Link standard: [https://www.gs1.org/standards/gs1-digital-link](https://www.gs1.org/standards/gs1-digital-link) * 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/](https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/digital-product-passport/) ## About This Article About This Article
Last Reviewed
2026-08-07
Next Scheduled Review
2027-08-07
Article Version
2.0
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 | Field | Value | | ------------- | -------------------------------------------------------------------------------------------------- | | Published | 2026-08-07 | | Last Reviewed | 2026-08-07 | | Reading Time | 12 min | | Difficulty | beginner | | Author | tieback | | Category | Digital Product Passports | | Tags | Digital Product Passport, DPP, ESPR, EU Product Compliance, Product Traceability, Circular Economy | ## Related Docs * [Digital Product Passports](/docs/knowledge-base/digital-product-passports/overview) * [Regulations](/docs/knowledge-base/regulations/overview)