> 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. # The Digital Product Passport Standards Landscape > A map of the Digital Product Passport standards landscape: who makes EU law, who develops European standards, what a standardisation request is, what CEN, CENELEC, ETSI, ISO, IEC and GS1 each do, where the CEN and CENELEC JTC 24 Digital Product Passport standards fit, what the technical standardisation domains cover, and how legal effect differs between binding law, product-specific requirements, harmonised standards, other standards and implementation choices. ## Executive Summary Most confusion about Digital Product Passport technology is not technical. It is institutional. People are told, in the same meeting, that the passport is required by an EU regulation, that a European standard exists, that GS1 publishes the identifier, that a QR code is the passport, and that an ISO committee is also involved. All of those statements point at something real. None of them belong to the same category, and treating them as if they did produces programmes that buy technology to satisfy a legal duty it does not actually discharge. This article is the map. It does not reteach identifiers, carriers, resolution or event data; the other articles in this section already do that in depth. What it does is place each institution, each instrument and each technology in the landscape, and attach the right legal effect to each one. The essential shape is this. The European Union makes binding law. Under [Regulation (EU) 2024/1781](https://eur-lex.europa.eu/eli/reg/2024/1781/oj), the Ecodesign for Sustainable Products Regulation, the framework sets out passport obligations, and product-specific measures adopted under it make those obligations concrete for particular product groups. The European Commission is a regulator and a standardisation policy actor. It is not a standards body. When it wants technical standards to support legislation, it issues a standardisation request to the European standardisation organisations, which are CEN, CENELEC and ETSI. Those organisations develop European standards through their technical committees. For Digital Product Passports the principal European structure is the joint CEN and CENELEC technical committee JTC 24, whose subject is the passport framework and system. Standards developed under a standardisation request may become harmonised standards when the Commission cites their references in the Official Journal of the European Union. That citation is what gives a voluntary technical document conditional legal relevance, in the form of a presumption of conformity limited to the requirements the standard covers. Under [Commission Implementing Decision (EU) 2026/1736](https://eur-lex.europa.eu/eli/dec_impl/2026/1736/oj/eng) the references of six Digital Product Passport European standards have been cited in the Official Journal, covering data exchange protocols, unique identifiers, data carriers, data storage and persistence, application programming interfaces, and system interoperability. Alongside that European structure sit international standardisation, in ISO and IEC, and industry standards ecosystems, of which GS1 is the most widely used in product identification. Neither is the EU regulator. GS1 identification keys, GS1 Digital Link, EPCIS and QR symbologies are standards and specifications that a programme may choose, or that an applicable measure may require. They are not the passport, and they are not universally mandated by the framework regulation. This article introduces the DPP Standards Landscape Model, a tieback educational model that maps the landscape as five zones with a separate legal-effect rail running beside them, so that the difference between binding law and implementation preference stays visible on the same page. * The European Commission regulates and directs standardisation policy. It does not write technical standards. CEN, CENELEC and ETSI develop European standards. GS1 is an industry standards organisation, not a European standardisation organisation and not a regulator. - A standardisation request is the formal instrument by which the Commission asks the European standardisation organisations to develop standards supporting Union legislation. The request does not turn every resulting technical choice into law. - A European standard becomes a harmonised standard for a given legal act only through the process set out in Regulation (EU) No 1025/2012, including citation of its reference in the Official Journal. Not every European standard is harmonised, and a harmonised standard remains voluntary. - The joint CEN and CENELEC technical committee JTC 24 covers the Digital Product Passport framework and system, and its first series of standards is transverse and product agnostic rather than product specific. - Identification, data carriers, resolution, data exchange, data models, semantics, access rights, security and event data are separate problem domains. A solution in one does not solve another. - Interoperability has layers. Exchanging the same bytes is technical interoperability. Agreeing what those bytes mean is semantic interoperability, and it does not come free with a file format. - Using a standard does not prove legal compliance, and adopting a technology stack is not the same as implementing a passport programme. This is the tenth article in the Standards & Technology section, and the first one to read. It sits above the others: where they explain individual components in depth, this one explains how the components, the institutions and the legal instruments relate. It also acts as the bridge from [Regulations](/docs/knowledge-base/regulations/overview) into [Enterprise Systems & Data Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/overview) and [Implementation](/docs/knowledge-base/implementation/overview). > **Educational scope** > > This article provides general educational information about EU product regulation and European > standardisation. It does not determine which standards, specifications or technologies apply to > any particular organisation, product or market, and it is not legal advice. Standardisation work > and legal references change; verify current status against the primary sources listed at the end > before relying on any statement here. Framework TBF-041 The DPP Standards Landscape Model A landscape map of the Digital Product Passport standards environment, organised as five zones read against a separate legal effect rail. Zone one, the legal framework, holds Union legislation, the Ecodesign for Sustainable Products Regulation and the product specific measures adopted under it, and is the only source of binding obligation. Zone two, standardisation direction, holds the European Commission acting as regulator and standardisation policy actor, issuing standardisation requests under Regulation (EU) No 1025/2012 and citing references of harmonised standards in the Official Journal without drafting technical standards itself. Zone three, the standards ecosystem, places the European standardisation organisations CEN, CENELEC and ETSI, the joint CEN and CENELEC committee JTC 24 on the Digital Product Passport framework and system, the international bodies ISO and IEC including the joint committee ISO/IEC JTC 5, and industry standards organisations such as GS1 side by side as distinct mandates rather than tiers of a hierarchy. Zone four, technical standardisation domains, separates identification, data carriers, physical to digital linkage, resolution and discovery, data exchange, interoperability, data models and semantics, access rights, authentication and security, application programming interfaces and lifecycle persistence, and event and traceability data. Zone five, the implementation ecosystem, holds the standards, specifications, carriers, resolver services, enterprise systems and passport services an organisation actually deploys. Running beside all five zones is a legal effect rail with five bands: binding law, product specific requirement, harmonised standard where applicable carrying conditional legal relevance through presumption of conformity once cited, other standard or specification which is voluntary unless otherwise required, and implementation choice which carries no legal force of its own. The model exists to make it impossible to read every institution and technology in the landscape as sharing one legal status. It consumes the ESPR framework model TBF-005 and the delegated act lifecycle TBF-006 as the source of binding requirements without restating them, hands the presumption of conformity mechanism to the conformity assessment relationship model TBF-040 rather than duplicating it, defers legal responsibility to TBF-039 and enforcement to TBF-038, draws its enterprise boundary against the enterprise Digital Product Passport reference architecture TBF-030 by stating that a standard defines an exchange contract and not a system of record, and hands delivery sequencing to the implementation roadmap model TBF-031 and standards version monitoring to the operating model TBF-036 and programme governance model TBF-037. ## Table of Contents * [Definition](#definition) * [Why the DPP Standards Landscape Is Confusing](#why-the-dpp-standards-landscape-is-confusing) * [The DPP Standards Landscape Model](#the-dpp-standards-landscape-model) * [Law, Standards and Implementation Choices](#law-standards-and-implementation-choices) * [The EU Legal Framework](#the-eu-legal-framework) * [What Is a Standardisation Request?](#what-is-a-standardisation-request) * [The European Commission's Role](#the-european-commissions-role) * [CEN and CENELEC](#cen-and-cenelec) * [DPP Standardisation and JTC 24](#dpp-standardisation-and-jtc-24) * [International Standards: ISO and IEC](#international-standards-iso-and-iec) * [Where GS1 Fits](#where-gs1-fits) * [What DPP Standards Need to Solve](#what-dpp-standards-need-to-solve) * [Identification Standards](#identification-standards) * [Data Carriers](#data-carriers) * [Resolution and Discovery](#resolution-and-discovery) * [Event and Traceability Data](#event-and-traceability-data) * [Interoperability](#interoperability) * [What Is Semantic Interoperability?](#what-is-semantic-interoperability) * [Data Models, Schemas and Vocabularies](#data-models-schemas-and-vocabularies) * [APIs and Protocols](#apis-and-protocols) * [Standards and Enterprise Architecture](#standards-and-enterprise-architecture) * [Standards and DPP Implementation](#standards-and-dpp-implementation) * [Standards and Conformity Assessment](#standards-and-conformity-assessment) * [Standard vs Harmonised Standard](#standard-vs-harmonised-standard) * [Are DPP Standards Mandatory?](#are-dpp-standards-mandatory) * [How to Read a DPP Standard or Specification](#how-to-read-a-dpp-standard-or-specification) * [Managing Standards Versions and Change](#managing-standards-versions-and-change) * [Practical Example](#practical-example) * [Common Mistakes](#common-mistakes) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) * [About This Article](#about-this-article) ## Definition The set of institutions, instruments and technical documents that together determine how Digital Product Passport requirements are expressed and implemented: binding Union legislation and the product-specific measures adopted under it, European standardisation policy and standardisation requests, the European standardisation organisations and their technical committees, international standards bodies, industry standards organisations, and the technical standards and specifications covering identification, data carriers, resolution, data exchange, data models, semantics, access and security. The landscape is not a hierarchy of authority. Its parts carry different legal effects. Two features of that definition do the real work. First, the landscape contains **different kinds of thing**. A regulation is not a standard. A standard is not a specification profile. A specification profile is not a product decision. They travel together in project conversations and diverge sharply in legal effect. First-time readers often assume a chain of command: the Commission tells CEN what to write, CEN tells GS1 what to publish, and GS1 tells companies what to do. That is not how any part of it works. The relationships are real but they are of different kinds, and none of them is a management line. ## Why the DPP Standards Landscape Is Confusing Five specific things make this harder than it should be. **The vocabulary overlaps.** "Standard" is used for a European standard, an international standard, an industry specification, a company convention and a general expectation of good practice. The same word carries five meanings in one sentence. **Legal effect is invisible in the artefact.** A published European standard and a harmonised standard can look identical. The difference is not in the document. It is in whether the Commission has cited its reference in the Official Journal for a particular legal act, and what that act says about presumption of conformity. **Technology is more visible than institutions.** A QR code is something you can point at. A standardisation request is not. So conversations gravitate to the symbol on the label and skip the question of what the law actually requires. **Adoption is mistaken for obligation.** A very widely used identification scheme feels mandatory because everybody uses it. Ubiquity is not a legal source. **The landscape moves.** European Digital Product Passport standardisation is recent and still developing. Statements that were accurate eighteen months ago about what exists, and what has been cited, may no longer be accurate. That is a reason to check status, not a reason to assume nothing exists. > **Tip** > > When someone says "the standard requires it", ask three questions: which document, which version, > and which legal act makes that document relevant to your product. If any of the three cannot be > answered, the statement is a preference, not a requirement. ## The DPP Standards Landscape Model The DPP Standards Landscape Model is a tieback educational model. No EU instrument defines it. It maps the landscape as five zones, running from legal authority through standardisation direction and the standards ecosystem into technical domains and implementation, with a separate legal-effect rail alongside. The zones describe **who does what**. The rail describes **what force the output carries**. Keeping those two questions on separate axes is the point of the model, because the common failure is to read a technology as though it inherited the authority of the legislation it was mentioned near. tieback educational model The DPP Standards Landscape Model Five zones describing who does what, and one legal-effect rail describing what force each output carries. The zones are a map, not a chain of command. 1. Zone 1 Legal framework The only source of binding obligation. Union legislation, the Ecodesign for Sustainable Products Regulation as the passport framework, and the product-specific measures adopted under it that make obligations concrete for a product group. * EU legislation Regulations and directives adopted by the Union legislator. * ESPR framework Sets the passport framework and its general requirements. * Product-specific measures Delegated or implementing measures that state what applies to which products. 2. Zone 2 Standardisation direction The European Commission acts as regulator and standardisation policy actor. It issues standardisation requests and decides whether to cite references of harmonised standards. It does not draft technical standards. * Standardisation policy The framework in Regulation (EU) No 1025/2012. * Standardisation request A formal request to the European standardisation organisations to draft standards. * Official Journal citation The step that gives a standard conditional legal relevance for a given act. 3. Zone 3 Standards ecosystem Distinct bodies with distinct mandates, side by side. European, international and industry organisations are not tiers of one hierarchy, and none of them legislates. * CEN and CENELEC European standardisation organisations developing European standards. * JTC 24 Joint CEN and CENELEC committee on the Digital Product Passport framework and system. * ETSI The third European standardisation organisation, relevant where telecommunications standards are engaged. * ISO and IEC International standardisation, including the joint committee ISO/IEC JTC 5 on the Digital Product Passport. * Industry organisations Bodies such as GS1 that publish widely used standards and specifications without regulatory authority. 4. Zone 4 Technical standardisation domains The separable problems that passport standardisation addresses. Solving one does not solve another, and different documents may cover different domains. * Identification Unique identifiers and identifier schemes. * Data carriers Physical to digital linkage on the item, packaging or documentation. * Resolution and discovery Turning an identifier into the appropriate resource or service. * Data exchange Protocols for moving information between parties and systems. * Interoperability Technical and semantic compatibility between independent systems. * Data models and semantics Structures, fields, relationships, units and meanings. * Access, security and trust Access rights, confidentiality, authentication and data integrity. * APIs and lifecycle Programmatic access, searchability, storage, archiving and persistence. * Event and traceability data Records of what happened, when, where and in what business context. 5. Zone 5 Implementation ecosystem What an organisation actually deploys. Everything here is an implementation mechanism unless an applicable legal requirement makes a specific choice binding. * GS1 system Identification keys, GS1 Digital Link and EPCIS where chosen or applicable. * Carrier symbologies QR, DataMatrix, linear barcodes, RFID and NFC as selected for the product. * Resolver services Services that route a scanned identifier to appropriate destinations. * Enterprise systems The systems that master, govern and supply the underlying product data. * Passport services The assembly, publication and access surface presented to requesters. Legal-effect rail Read every item in the map against this rail. Items in the same zone can sit in different bands, and items in different zones can sit in the same band. * Binding law Obligatory. Union legislation applies whether or not any standard exists. * Product-specific requirement Obligatory for the products in scope. This is where general framework duties become concrete requirements. * Harmonised standard where applicable Voluntary, with conditional legal relevance. Where the applicable act provides and the reference is cited in the Official Journal, applying it can confer a presumption of conformity limited to the requirements covered. * Other standard or specification Voluntary unless otherwise required. Useful, sometimes commercially expected, but not a legal source in itself. * Implementation choice No legal force of its own. Architecture, vendor and configuration decisions that must still satisfy whatever the applicable requirements say. Reading the map Authority flows only from Zone 1. Zone 2 directs and recognises standardisation without drafting it. Zone 3 bodies coexist with different mandates rather than reporting to one another. Zones 4 and 5 acquire legal relevance only where Zone 1 or the citation mechanism in Zone 2 gives it to them. ## Law, Standards and Implementation Choices The single most useful distinction in this whole subject is between five categories that are routinely collapsed into one. **Binding EU law.** A regulation applies directly. It does not need a standard to exist in order to be binding, and no technical choice can waive it. **Product-specific legal requirement.** Framework law usually leaves the concrete requirements to product-specific measures. Until such a measure applies to your product group, the framework tells you the shape of the obligation, not its detail. **Harmonised standard where applicable.** A standard developed under a standardisation request whose reference has been cited in the Official Journal for a particular act. Voluntary to use, but with defined legal consequences if you do use it, limited to the requirements it covers. **Other standard or technical specification.** Everything else: European standards that are not harmonised for your act, international standards, industry specifications, consortium profiles. Voluntary unless something else requires them. **Implementation choice.** Your architecture, your vendors, your configuration, your internal conventions. No external legal effect at all, and yet where most programme effort is spent. #### Reading legal force off proximity A slide that shows the regulation, a European standard and a vendor product in the same row makes all three look equally obligatory. They are not. Legal force comes from the legal act, not from adjacency in a diagram. ## The EU Legal Framework The passport framework sits in Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation. As a regulation it is binding in its entirety and directly applicable. It establishes the concept of the Digital Product Passport, the general requirements around unique identification, data carriers and accessibility of information, and the mechanism by which product-specific requirements are adopted. What it does not do is tell a given manufacturer which identifier scheme, carrier symbology, data model or service architecture to use. Those become concrete through the product-specific measures adopted under the framework, and through any standards that the applicable act brings into play. [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts) explains that mechanism, and [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport) explains how scope is set. Other Union acts also carry passport-type obligations for their own sectors, and they have their own timelines, requirements and standardisation arrangements. The standardisation request described below covers ecodesign and battery contexts, which is a reminder that the landscape is plural: the answer to "what applies" always begins with "which act governs this product". > **Framework first, detail second** > > Reading the framework regulation tells you the kind of duty you will have. It rarely tells you the > specific technical answer. Programmes that wait for total certainty before starting usually > discover that the uncertain part was the last ten percent, and the data readiness work they > deferred was the first ninety. ## What Is a Standardisation Request? A formal instrument by which the European Commission asks one or more of the European standardisation organisations to draft a European standard or other European standardisation deliverable, within a stated deadline and to a stated scope, in support of Union policy or legislation. The mechanism is set out in Regulation (EU) No 1025/2012 on European standardisation. The organisation receiving the request decides whether to accept it. The mechanics matter, because they explain why standardisation output is neither arbitrary nor legislative. **Why the Commission issues one.** Union legislation is deliberately written in terms of requirements and outcomes rather than technical detail. Technical detail ages faster than law and is better produced by expert committees. When the Commission needs technical documents that support a legal act, it requests them rather than writing them. **What the request contains.** A scope, the requirements to be supported, the deliverables sought, and deadlines for their adoption. It is addressed to the European standardisation organisations, and it is issued as a Commission implementing decision. **How the organisations respond.** CEN, CENELEC and ETSI decide whether to accept the request. If accepted, the work is allocated to technical committees, and standards are drafted through the normal consensus process, including national participation and public enquiry. **What happens afterwards.** Standards produced under a request are candidates to become harmonised standards. The Commission assesses them and, where satisfied, cites their references in the Official Journal. That citation, not the request, is the step that produces legal effect. For Digital Product Passports, the relevant instrument is Commission Implementing Decision C(2024) 5423 of 31 July 2024, a standardisation request to CEN, CENELEC and ETSI concerning digital product passports in support of Union policy on ecodesign requirements for sustainable products and on batteries and waste batteries. It was amended by Commission Implementing Decision C(2025) 8024 of 28 November 2025 as regards the legal basis and the deadlines for adoption of the standards. In CEN and CENELEC communications this request is referred to as M/604. > **Tip** > > A standardisation request is a commissioning instrument, not a legislative one. It tells you that > standards are being developed and roughly what they will cover. It does not tell you that using > them is obligatory, and it does not pre-approve their content. ## The European Commission's Role The Commission appears at three separate points in the landscape, and conflating them is a common source of error. **As a regulator.** It proposes legislation and, where empowered by a framework act, adopts delegated and implementing acts that create binding product requirements. **As a standardisation policy actor.** It sets and operates European standardisation policy under Regulation (EU) No 1025/2012, issues standardisation requests, and works with the European standardisation organisations on the programme of work. **As the body that recognises harmonised standards.** It assesses standards produced under a request and publishes references in the Official Journal, which is what attaches conditional legal relevance to an otherwise voluntary document. What it does not do is draft technical standards. There is no Commission committee writing the clause that specifies an identifier syntax. That work happens in CEN, CENELEC and ETSI technical committees composed of national delegations and experts. #### The European Commission writes technical standards It does not. It requests them, assesses them and cites them. The technical drafting is done by the European standardisation organisations. Reversing this makes it impossible to understand why a standard can exist and still not be legally relevant to your product. ## CEN and CENELEC **CEN** is the European Committee for Standardisation. **CENELEC** is the European Committee for Electrotechnical Standardisation. Together with **ETSI**, the European Telecommunications Standards Institute, they are the European standardisation organisations recognised under Regulation (EU) No 1025/2012. They are private, membership-based organisations, not EU institutions. Four points about how they work are relevant to passport programmes. **Membership is national.** CEN and CENELEC members are national standardisation bodies. Experts participate through their national body, and national bodies vote. This is why a European standard carries weight across the single market: the national bodies adopt it as a national standard and withdraw conflicting national standards. **Work happens in technical committees.** A technical committee owns a subject area and produces deliverables within it. Joint technical committees are used where a subject spans both the CEN and the CENELEC domains, which is exactly the situation for the Digital Product Passport. **Output types differ.** A European standard is the most formal deliverable. Technical specifications and technical reports also exist, with different status, and they are not interchangeable with a full European standard. **They respond to requests, they do not receive orders.** A standardisation request is accepted or declined. Content remains the responsibility of the technical committee and its consensus process. The relationship with international standardisation runs through formal cooperation agreements, which is why European and international work is often aligned rather than duplicated, and why an international standard can sometimes be adopted as a European standard. ## DPP Standardisation and JTC 24 The principal European structure for Digital Product Passport standardisation is the joint CEN and CENELEC technical committee **CEN/CLC/JTC 24, "Digital Product Passport: Framework and System"**. Its secretariat is held by DIN, the German national standardisation body. It was created to respond to the Commission standardisation request described above. Two characteristics define its work. **It is horizontal, not product specific.** The committee's output is transverse and product agnostic: it addresses the passport framework and system, the mechanics common to any product group. Product-specific data requirements and test methods are a separate matter for product technical committees, under separate standardisation requests linked to the ecodesign working plan. **It is organised by technical domain.** The first series of European standards developed under the request covers eight subject areas: | Standard | Subject | Status | | -------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | EN 18216 | Data exchange protocols | Published European standard; reference cited in the Official Journal by Implementing Decision (EU) 2026/1736 | | EN 18219 | Unique identifiers | Published European standard; reference cited in the Official Journal by Implementing Decision (EU) 2026/1736 | | EN 18220 | Data carriers | Published European standard; reference cited in the Official Journal by Implementing Decision (EU) 2026/1736 | | EN 18221 | Data storage, archiving and data persistence | Published European standard; reference cited in the Official Journal by Implementing Decision (EU) 2026/1736 | | EN 18222 | Application programming interfaces for passport lifecycle management and searchability | Published European standard; reference cited in the Official Journal by Implementing Decision (EU) 2026/1736 | | EN 18223 | System interoperability | Published European standard; reference cited in the Official Journal by Implementing Decision (EU) 2026/1736 | | EN 18239 | Access rights management, information system security and business confidentiality | Reported by CEN and CENELEC as part of the first series; not among the references cited by Implementing Decision (EU) 2026/1736 | | EN 18246 | Data authentication, reliability and integrity | Reported by CEN and CENELEC as part of the first series; not among the references cited by Implementing Decision (EU) 2026/1736 | Read that table carefully, because it contains the whole lesson of this article in miniature. Six of these standards have had their references cited in the Official Journal, which is the step that can give rise to a presumption of conformity in relation to the requirements they cover. Two are reported as part of the same series without appearing in that citation decision. Same committee, same programme, different legal position at a given moment in time. > **Status changes** > > Citation decisions are amended over time, and further deliverables may follow. Treat the statuses > above as accurate at the review date of this article and verify current status against the > Commission harmonised standards pages and the Official Journal before relying on them. What the committee's work does not do is decide which products must have a passport, when, or with what content. Those are questions for the applicable legislation and its product-specific measures. ## International Standards: ISO and IEC ISO, the International Organization for Standardization, and IEC, the International Electrotechnical Commission, are the principal international standardisation bodies. They are not EU bodies and they do not produce EU law. Their relevance to Digital Product Passports is real but specific. **Underlying technologies are already internationally standardised.** Symbologies, character encodings, date and time representations, identifier syntaxes and security primitives typically originate in international standards, and European work references them rather than reinventing them. **There is now dedicated international work.** A joint ISO and IEC technical committee, ISO/IEC JTC 5, has been established for the Digital Product Passport, with its secretariat held by DIN. CEN and CENELEC treat it as the mirror committee for JTC 24, with the aim of global interoperability. **Alignment is a process, not an assumption.** European standardisation may reference, adopt, align with or build upon international standards, and it may also diverge where Union legislation requires something specific. European passport standardisation is not simply an implementation of an international standard, and an international standard is not automatically relevant to a Union legal requirement. ## Where GS1 Fits GS1 is an international, member-funded standards organisation for supply chain identification and data exchange. Its standards are extremely widely used, and there is a serious chance that your products already carry them. That ubiquity is exactly why its position needs to be stated precisely. * **GS1 is not an EU regulator.** It has no power to create legal obligations. * **GS1 is not a European standardisation organisation.** It is not CEN, CENELEC or ETSI, and it does not receive Commission standardisation requests in that capacity. * **A GTIN is not a Digital Product Passport.** It is an identification key. See [What is a GTIN?](/docs/knowledge-base/standards-and-technology/what-is-a-gtin). * **GS1 Digital Link is not a Digital Product Passport.** It is a way of expressing an identifier as a structured web address. See [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link). * **EPCIS is not a Digital Product Passport.** It is an event data standard. See [What is EPCIS?](/docs/knowledge-base/standards-and-technology/what-is-epcis). * **A QR code is not a Digital Product Passport.** It is a data carrier symbology. See [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) and [QR Codes vs GS1 Digital Link](/docs/knowledge-base/standards-and-technology/qr-codes-vs-gs1-digital-link). What GS1 does offer is a coherent, globally deployed set of capabilities for identification, carriers, resolution and event data, already embedded in retail, logistics and healthcare operations. For many organisations a GS1-based implementation is the pragmatic route to satisfying identification and carrier requirements, precisely because the trading partners, scanners and processes already exist. That is a strong practical argument. It is not a legal one. A capability being standards-based and useful does not make it mandated by the framework regulation, and the reverse also holds: choosing a different scheme does not by itself make an implementation non-compliant. [What is GS1?](/docs/knowledge-base/standards-and-technology/what-is-gs1) covers the organisation and its scope in depth. ## What DPP Standards Need to Solve Strip away the institutions and the standardisation programme is addressing a fairly clear list of separable problems. Reading the list is the fastest way to understand why there is a series of standards rather than one. * **Identifiers.** How a product, batch or item is uniquely and persistently identified. * **Data carriers.** How that identifier is physically present on the item, packaging or documentation. * **Physical to digital linkage.** How a physical encounter with an object becomes a digital request. * **Resolution and discovery.** How an identifier leads to the right resource or service, for the right requester. * **Data exchange.** How information moves between parties and systems reliably. * **Data structures and models.** What the information looks like structurally. * **Semantics.** What the values actually mean. * **Access rights.** Who is entitled to see which parts, and how that is enforced. * **Authentication, trust and security.** Whether the information is genuine, unaltered and appropriately protected, including business confidentiality. * **APIs and protocols.** How systems obtain and search information programmatically. * **Persistence and lifecycle accessibility.** How information remains available for as long as it is required to be. Two boundaries are worth holding on to. **Legislation** determines whether a passport is required, for which products, with what information, available to whom and for how long. **Standardisation** addresses how such requirements can be met technically in a consistent, interoperable way. The second serves the first. It does not replace it, and its scope is not identical to it. ## Identification Standards At landscape level, identification is where most projects start and where the most avoidable confusion is created, because five different things get called "the identifier". * **Product identity** is the concept: the thing being identified, at a chosen level of granularity. * **Identifier** is the concrete value assigned to that identity. * **Identifier scheme** is the system of rules under which values are assigned and remain unique. * **Serialisation** is identification at individual item level rather than model level. * **Batch or lot identification** sits between the two: a defined production grouping. * **Data carrier** is none of the above. It is how the identifier travels on the object. A passport requirement typically bites at a particular level of granularity, and that choice cascades into packaging, production and systems. Identifying at model level is cheap and often insufficient. Identifying at item level is powerful and expensive. [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier) works through the levels, and [What is a GTIN?](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) covers the most widely deployed key in detail. ## Data Carriers The carrier chain has five distinct links, and each one is a separate design decision with separate standards attached: ```text PRODUCT -> IDENTIFIER the value that denotes this product identity -> DATA CARRIER the symbol, tag or mark that conveys the identifier -> ACCESS / RESOLUTION turning the captured value into a request and a destination -> DIGITAL RESOURCE the passport information actually presented or returned ``` Collapsing any two of these produces a characteristic error. Collapsing identifier and carrier produces "the QR code is the identifier". Collapsing carrier and resource produces "the QR code is the passport". Collapsing resolution and resource produces a single hard-coded destination that cannot serve different audiences or survive a change of provider. Carrier selection is genuinely constrained by physics and process: substrate, size, durability, temperature, read distance, line speed and existing scanning estate. The relevant depth is in [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier). ## Resolution and Discovery The process of taking an identifier, or a web address expressing one, and returning the appropriate digital resource or service for the requester, rather than a single fixed page. The landscape-level shape is short: ```text IDENTIFIER or URI -> RESOLUTION -> ONE OR MORE DIGITAL RESOURCES OR SERVICES ``` The reason one identity may connect to several resources is that different requesters need different things from the same object. A consumer may need care and disposal information. A repairer may need spare parts and dismantling instructions. A recycler may need material composition. An authority may need compliance-related information. A trading partner may need structured data rather than a page. One scan, several legitimate destinations, governed by who is asking and what they are entitled to see. This is also why resolution is an architectural commitment rather than a URL. Whoever operates resolution controls availability, persistence and the ability to change destinations without reprinting labels. The [Resolver](/docs/knowledge-base/glossary/resolver) glossary entry gives the concise definition, and [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link) covers one widely used approach in depth. This article deliberately stops there. ## Event and Traceability Data Identity establishes **what** something is. Event data establishes **what happened to it**. ```text IDENTITY what this object is EVENT DATA what happened, when, where, and in what business context ``` Both matter, for different reasons. A passport carries descriptive and compliance-related information about a product. Many of the claims in that information, particularly about origin, composition and chain of custody, are ultimately supported by records of events across a supply chain. [EPCIS](/docs/knowledge-base/glossary/epcis) is the most widely used standard for representing such events, and [What is EPCIS?](/docs/knowledge-base/standards-and-technology/what-is-epcis) explains it properly. [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain) shows the flows end to end. Two boundaries are non-negotiable. EPCIS is not the passport: it is an event data standard, and a passport is an information availability obligation. And EPCIS is not universally required for passport implementation: whether event data is needed at all depends on what the applicable requirements ask you to state and support. ## Interoperability "Interoperability" is used so often in passport material that it has almost stopped meaning anything. It has layers, and naming them makes design conversations tractable. **Technical interoperability.** Systems can connect and exchange information: transport, protocols, encodings, formats. The bytes arrive intact. **Semantic interoperability.** Systems interpret the exchanged information with sufficiently consistent meaning: the same field name denotes the same concept, the same unit, the same measurement basis. **Identity interoperability.** The parties agree on what the identifiers denote, at what granularity, and under what assignment rules. Without it, two datasets about "the same product" may not be about the same thing. **Organisational interoperability.** Processes, responsibilities, timing and governance align well enough for the exchange to be useful: who updates what, when, and who is accountable for accuracy. The principle to keep is blunt: > Exchanging the same bytes does not necessarily mean understanding the same product information. Most passport interoperability failures are not transport failures. They are meaning failures that present as data quality problems six months later. ## What Is Semantic Interoperability? Semantic interoperability is the property that exchanged information is interpreted with sufficiently consistent meaning by all parties that rely on it. It is achieved through shared reference points rather than shared software. The main instruments are: * **Common definitions.** An agreed statement of what a concept means, independent of any system. * **Schemas.** Formal structures specifying fields, types, cardinality and relationships. * **Controlled vocabularies.** Constrained value lists, so that a category is chosen rather than typed. * **Units and measurement bases.** The unit, and the method or boundary the figure was produced under. * **Reference data.** Shared master lists of things such as materials, countries or classifications. * **Attribute semantics.** The precise meaning of a specific field, including what it excludes. #### Two values that look identical and are not Two suppliers each send a field called `recycledContent` with the value `30`. Supplier A means 30 percent by weight of the total product, post-consumer material only, verified against a mass balance calculation, excluding packaging. Supplier B means 30 percent by weight of the primary polymer component only, counting both pre-consumer and post-consumer material, including packaging. Both files parse. Both validate against a schema that requires a number. Both are loaded into the same column. The aggregate figure that results is meaningless, and nothing in the exchange mechanism reported a problem. That example is the whole argument for semantics. A format check confirms the value is a number. It cannot confirm the number is the same kind of number. This article introduces the topic deliberately and does not exhaust it. ## Data Models, Schemas and Vocabularies Standardisation in this domain may address structures, fields, relationships, formats and semantic definitions, because each of them is a place where two independent implementations can drift apart. * **Structures** define how information is organised into objects and hierarchies. * **Fields** define what individual pieces of information exist and what type they are. * **Relationships** define how objects connect: product to component, product to batch, batch to event. * **Formats** define serialisation and encoding. * **Semantic definitions** define what everything means. The enterprise boundary here is important enough to state as a rule: > A standard data model is not a shared database. A common exchange model says what crosses the boundary between organisations and how it is to be understood. It does not say how you store it internally, what your primary keys are, which system masters which attribute, or how your data model should be shaped. Organisations can retain entirely different internal architectures and still exchange consistently, provided they can map to the common semantics at the boundary. That mapping is real work, and it is where most integration effort actually goes. ## APIs and Protocols An application programming interface is an access mechanism. It defines how a system can request information and what it will receive. Protocols define how those requests travel. Both are necessary in any implementation that serves machines as well as people, and standardisation work covers them for exactly that reason, including passport lifecycle management and searchability. What an API does **not** do is worth listing, because API delivery is often treated as programme completion: * It does not establish product identity. * It does not create semantic meaning. * It does not improve data quality. * It does not establish legal compliance. * It does not confer authority on the data it returns. An API returns whatever the underlying systems hold, faster and more reliably than a spreadsheet did. If the underlying data is wrong, an API is a more efficient way of distributing the error. Technology selection at this level, including transport styles and query languages, is an implementation choice and is not the subject of this article. ## Standards and Enterprise Architecture The temptation, once a data standard is adopted, is to reshape the enterprise around it. That is usually a mistake, and the boundary is clean: > A standard can define an exchange contract. It does not determine your system of record. Specifically, a standard does not decide: * Which system is the [system of record](/docs/knowledge-base/glossary/system-of-record) for a given attribute. * How your databases are designed. * Who owns master data, or how stewardship is organised. * What your [data governance](/docs/knowledge-base/glossary/data-governance) model looks like. * What your enterprise architecture should be. * What your operating model should be. Those are enterprise decisions that would exist even if no passport requirement existed, and they are covered in [What Is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data), [ERP vs PIM vs PLM: What's the Difference?](/docs/knowledge-base/enterprise-systems-and-data-architecture/erp-vs-pim-vs-plm), [What Is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record) and [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture). ## Standards and DPP Implementation Selecting standards is one decision inside a much larger delivery problem. Having chosen an identifier scheme, a carrier, a resolution approach and a data model, an organisation still has to: * Establish which requirements apply to which products. * Locate the source data and determine whether it exists at all. * Put governance and ownership around the attributes that matter. * Bring suppliers to the point where they can provide what is needed. * Validate the data against the applicable rules. * Assemble and retain the supporting evidence. * Integrate the systems that produce and consume the information. * Test and assure the result. * Deploy, operate and maintain it as products, suppliers and requirements change. That work is sequenced in [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap), with supplier readiness, validation, evidence and assurance covered in their own articles. This article does not recreate any of it. #### Decide standards early, but do not confuse the decision with the delivery Standards selection is a small, high-leverage decision that should be made early because it constrains packaging and integration. It typically accounts for a tiny fraction of programme effort. The data, the suppliers and the governance account for most of it. ## Standards and Conformity Assessment Standards intersect with conformity assessment in a specific and limited way, explained fully in [How Conformity Assessment Works for Digital Product Passports](/docs/knowledge-base/regulations/how-conformity-assessment-works-for-digital-product-passports). The short version, stated here only to complete the map: * Conformity assessment determines or demonstrates whether specified requirements have been fulfilled. * Standards are one input into that. Applying a harmonised standard can, where the applicable legislation provides and the reference has been cited, give rise to a presumption of conformity limited to the requirements the standard covers. * Presumption of conformity is not proof of conformity for everything, and it does not extend beyond the requirements covered. * Using a standard that is not harmonised for your act produces no presumption at all, however technically sound it is. For the legal instruments and roles that sit around this, see [How Digital Product Passports Will Be Enforced](/docs/knowledge-base/regulations/how-digital-product-passports-will-be-enforced) and [Who Is Legally Responsible for a Digital Product Passport?](/docs/knowledge-base/regulations/who-is-legally-responsible-for-a-digital-product-passport). Standards do not determine who is legally responsible, and they do not limit what an authority may do. ## Standard vs Harmonised Standard These two terms are not synonyms, and the difference is procedural rather than technical. A **European standard** is a standard adopted by CEN, CENELEC or ETSI. It exists, it is technically authoritative, and it is voluntary. A **[harmonised standard](/docs/knowledge-base/glossary/harmonised-standard)** is a European standard adopted on the basis of a Commission standardisation request, for the purpose of applying Union harmonisation legislation. Where the Commission is satisfied that the standard meets the requirements it is intended to cover, it publishes the reference in the Official Journal. From the date of that publication, applying the standard can confer a presumption of conformity with the corresponding requirements of the relevant legal act. Three consequences follow: 1. **Not every European standard is harmonised.** Harmonisation is act-specific and requires the citation step. 2. **A harmonised standard is still voluntary.** You may demonstrate conformity another way. You simply do not get the presumption. 3. **The presumption is bounded.** It extends only to the requirements the standard covers, and only for the act in question. #### Treating harmonised as mandatory Harmonised standards remain voluntary. What changes is the evidential position of an organisation that applies them. Reading "harmonised" as "compulsory" leads organisations to believe they have no choice, and, worse, to believe that applying the standard settles more than it does. ## Are DPP Standards Mandatory? The honest answer is: **it depends on the applicable legal framework and the specific requirement**. Anything more definitive, stated generally, is wrong. The framework regulation creates duties around unique identification, data carriers and accessible information. What satisfies those duties for a given product group is determined by the applicable product-specific measure and by any standards that measure or the framework brings into play. Taking the specific questions people actually ask, answered at framework level and as at the review date of this article: **Does ESPR require GS1?** No. It does not universally mandate any single standards organisation's system. **Does ESPR require a GTIN?** No. It requires unique identification, not one particular key. **Does ESPR require GS1 Digital Link?** No. It does not universally mandate that syntax. **Does ESPR require EPCIS?** No. Event data standards are not a universal framework requirement. **Does ESPR require QR codes?** No. It requires a data carrier. QR is a very common choice, and it may be specified in a particular context, but "data carrier" and "QR code" are not the same requirement. What can change this picture is a product-specific measure that names or effectively requires a particular approach for a particular product group, or a harmonised standard whose application you choose in order to obtain a presumption of conformity. This article does not speculate about the content of future measures. Check the measure that applies to your product. ## How to Read a DPP Standard or Specification When a standard or specification lands on your desk, run it through this checklist before it becomes an architectural commitment. This is implementation guidance, not legal advice. 1. **Who published it?** A European standardisation organisation, an international body, an industry organisation, a consortium or a vendor. This determines its institutional weight, not its technical quality. 2. **What problem does it solve?** Map it onto the technical domains above. Many disagreements are really two people comparing documents that solve different problems. 3. **What version is current?** Note the version and the date, and whether amendments exist. 4. **Is it final or under development?** A draft is not a standard. Building to a draft is a deliberate risk decision, not a neutral one. 5. **Does applicable legislation reference it?** Directly, or through a citation of its reference. 6. **Is it harmonised where relevant?** For which legal act, and from what date. 7. **Which requirements does it address?** Specifically which, because presumptions and claims are bounded by coverage. 8. **Is its use mandatory, presumptive, optional or simply useful?** These are four different answers and they lead to four different decisions. 9. **What other standards does it depend on?** Normative references pull in obligations you may not have noticed. 10. **Which enterprise systems must implement or map to it?** Name them. If nobody can, the adoption decision is not real yet. 11. **Who owns version monitoring?** A named role, not a team in the abstract. 12. **What happens when it changes?** The impact path, from document change to reprinted labels or republished data. > **Tip** > > Questions 5 to 8 are the ones that get skipped, and they are the ones that determine whether the > adoption has any legal significance at all. ## Managing Standards Versions and Change Standards are living documents, and passport standardisation is unusually active. Treating a standard as a fixed input is a reliable way to accumulate silent debt. **Drafts are not final standards.** Content changes between draft and publication, sometimes materially. Implementing early is legitimate; implementing early while recording it as done is not. **Versions matter.** "We comply with the standard" is incomplete without a version. Two systems on different versions of the same document can be incompatible. **Dependencies matter.** Normative references mean a change in one document can change the behaviour required by another. **Implementation profiles change.** Sector or partner profiles that constrain a general standard have their own release cycles and are often the thing that actually changes. **Legal references change.** A citation in the Official Journal can be added, amended or withdrawn, and that changes the legal position of a document you are already using without changing the document itself. **Someone has to watch.** Standards monitoring is an operational responsibility with a named owner, an inventory of the documents in use, a review cadence and a defined impact path into change control. Where that responsibility lives is a governance question, covered in [How to Operate a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme) and [How to Govern a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme). ## Practical Example A hypothetical manufacturer of a household appliance falls within scope of a product-specific measure requiring a Digital Product Passport. Follow one product through the landscape, labelling each stage by legal effect. **1. Legal requirement.** The applicable measure requires a passport, specifies the information categories, states who must be able to access what, and sets availability obligations. *Required by law.* **2. Relevant standardisation outputs.** The manufacturer reviews the European standards developed for the passport framework and system, checks which references have been cited in the Official Journal for the applicable act, and decides which to apply. *Harmonised standard where applicable; otherwise voluntary.* **3. Identification.** A unique identifier is required. The manufacturer already assigns GTINs and decides to use a GS1 key with batch-level identification, because production and packaging already support it. *Unique identification: required by law. GTIN and batch granularity: implementation choice, unless the applicable measure specifies otherwise.* **4. Data carrier.** A data carrier is required. The manufacturer selects a QR symbol on the rating plate for durability, plus the same content on packaging. *Carrier: required by law. QR on the rating plate: implementation choice, within any constraints the measure sets.* **5. Resolution and discovery.** Scanning yields a web address expressing the identifier, which resolves to different destinations for consumers, repairers, recyclers and authorities. *Accessibility: required by law. GS1 Digital Link syntax and the resolver operator: standard-supported implementation choices.* **6. Data model and semantics.** Required attributes are mapped from internal systems into the exchange structure, with units, controlled values and definitions agreed with suppliers. *Information content: required by law. Structure and encoding: standard-defined where a standard is applied. Internal mapping: implementation choice.* **7. Event and traceability data.** Some claims about material origin need supporting records, so the manufacturer captures supply chain events for a subset of components. *Substantiating claims: driven by the legal requirement. EPCIS as the mechanism: standard-supported implementation choice.* **8. Enterprise integration.** Attributes are sourced from product master data, engineering and compliance systems, with ownership assigned per attribute and validation before publication. *Entirely implementation choice, and unavoidable regardless of standards selected.* **9. DPP service.** The passport is assembled, published, access-controlled, monitored and kept available for the required period, with republication on change. *Availability and access: required by law. Service architecture: implementation choice.* None of the specific technologies in this walkthrough is universally required. A different manufacturer, in a different sector, with a different applicable measure, could make different choices at stages 3 to 9 and be equally correct. ## Common Mistakes #### CEN writes EU legislation CEN and CENELEC develop standards. Union legislation is adopted by the Union legislator, and delegated and implementing acts by the Commission under powers conferred by a framework act. Standards bodies have no legislative power. #### The European Commission writes technical standards The Commission issues standardisation requests and cites references of harmonised standards. The drafting is done in the technical committees of the European standardisation organisations. #### GS1 is the EU DPP standards body GS1 is an industry standards organisation whose standards are very widely used. It is not a European standardisation organisation and it has no regulatory authority in the Union. #### Every European standard is harmonised Harmonisation is act-specific and depends on the standard being developed under a standardisation request and having its reference cited in the Official Journal. Most European standards are not harmonised for any given act. #### Every harmonised standard is mandatory Harmonised standards remain voluntary. Applying one can confer a presumption of conformity for the requirements it covers; declining to apply one means demonstrating conformity another way. #### ESPR mandates GS1 The framework regulation does not universally mandate any single standards organisation's system. What applies to a specific product group is determined by the applicable product-specific measure. #### The GTIN is the DPP A GTIN is an identification key. It identifies a trade item. It carries no passport information and satisfies no information obligation by itself. #### GS1 Digital Link is the DPP It is a way of expressing an identifier as a structured web address. It is a syntax for identity, not a body of passport information. #### A QR code is the DPP A QR code is a data carrier symbology. It conveys whatever is encoded in it. Printing one creates no passport, and scanning one proves nothing about the information behind it. #### EPCIS stores the DPP EPCIS represents events: what happened, when, where and in what business context. Passport information is largely descriptive and compliance-related. Event data may support passport claims without being the passport. #### An API automatically creates interoperability An API creates access. Interoperability additionally requires agreement about identity, structure and meaning. Two systems can call each other perfectly and still disagree about what the data means. #### JSON means systems are semantically interoperable A serialisation format guarantees parsing, not understanding. Identical field names with different definitions, units or measurement bases produce clean files and wrong answers. #### A standard determines the enterprise system of record A standard can define an exchange contract at the boundary. Which internal system masters an attribute, and who owns it, is an enterprise decision that the standard does not make for you. #### Using a standard proves legal compliance Compliance is with legal requirements, not with standards. Applying a harmonised standard can produce a bounded presumption of conformity where the applicable legislation provides for it. Nothing else about standards adoption is a compliance claim. #### A draft standard can be treated as final Draft content changes. Building against a draft is a valid risk decision when taken deliberately, with the version recorded and a plan for realignment. Recording it as a finished implementation is not. ## Frequently Asked Questions **What standards apply to Digital Product Passports?**\ At European level, the standards developed for the passport framework and system by the joint CEN and CENELEC committee JTC 24, covering data exchange protocols, unique identifiers, data carriers, data storage and persistence, application programming interfaces, system interoperability, access rights and security, and data authentication and integrity. Around those sit international standards and widely used industry standards such as the GS1 system. Which ones apply to your product depends on the applicable legislation and the choices you make. **Who creates Digital Product Passport standards?**\ European standards are developed by CEN, CENELEC and ETSI through their technical committees. International standards are developed by ISO and IEC. Industry standards are developed by organisations such as GS1. Legislation is made by the Union legislator and the Commission, not by any of them. **What is CEN/CENELEC JTC 24?**\ The joint CEN and CENELEC technical committee for the Digital Product Passport framework and system, with its secretariat held by DIN. It was created to respond to the Commission standardisation request on digital product passports, and its output is transverse and product agnostic rather than specific to one product group. **Does the European Commission create DPP standards?**\ No. It issues standardisation requests asking the European standardisation organisations to develop them, assesses the results and cites references of harmonised standards in the Official Journal. **What is a standardisation request?**\ A formal instrument, adopted as a Commission implementing decision under Regulation (EU) No 1025/2012, asking one or more European standardisation organisations to draft standards supporting Union policy or legislation, with a defined scope and deadlines. The organisation may accept or decline it. **What is the difference between a regulation and a standard?**\ A regulation is binding law adopted through the Union legislative process. A standard is a technical document adopted by a standardisation body and is voluntary in itself. A standard can acquire conditional legal relevance, but it never becomes legislation. **What is the difference between a European standard and a harmonised standard?**\ A European standard is any standard adopted by CEN, CENELEC or ETSI. A harmonised standard is a European standard developed on the basis of a Commission standardisation request for the purpose of applying Union harmonisation legislation, whose reference the Commission has cited in the Official Journal, allowing a presumption of conformity limited to the requirements it covers. **Are DPP standards mandatory?**\ It depends on the applicable legal framework and requirement. Standards are voluntary in themselves. An applicable measure may make a specific technical approach binding for a product group, and a harmonised standard may be the practical route to a presumption of conformity, but neither makes every standard mandatory. **Does ESPR require GS1?**\ No. The framework regulation does not universally mandate the GS1 system. What applies to a specific product group is determined by the applicable product-specific measure. **Does ESPR require GTIN?**\ No. It requires unique product identification. The GTIN is one widely used identification key, not a universal legal requirement. **Does ESPR require GS1 Digital Link?**\ No. It does not universally mandate that syntax. It is a common implementation choice for expressing an identifier as a web address. **Does ESPR require EPCIS?**\ No. Event data standards are not a universal framework requirement. Event data may nonetheless be how an organisation substantiates particular claims. **Does a DPP require a QR code?**\ A data carrier is required. QR is the most common choice and may be specified in a particular context, but the general requirement is for a carrier, not for one symbology. **What role does GS1 play?**\ It publishes and maintains widely deployed standards for identification, data capture and data exchange, and operates the identification key allocation system through its member organisations. It is not a regulator and not a European standardisation organisation. **What role does EPCIS play?**\ It provides a standard way to record and share events: what happened to an object, when, where and in what business context. It supports traceability claims. It is not the passport. **What is a DPP resolver?**\ A service that takes an identifier, or a web address expressing one, and returns the appropriate digital resource or service for the requester, allowing one product identity to lead to different destinations for different audiences. **What is DPP interoperability?**\ The ability of independently developed systems to exchange passport-related information and use it correctly. It has technical, semantic, identity and organisational layers, and delivering only the technical layer is the common failure. **What is semantic interoperability?**\ The property that exchanged information is interpreted with sufficiently consistent meaning by all parties, achieved through common definitions, schemas, controlled vocabularies, units, reference data and clear attribute semantics. **Can different DPP systems interoperate?**\ Yes, provided they agree on identity, structure and meaning at the exchange boundary. That agreement is what standards are for. Identical software is not required. **Do companies need the same DPP technology?**\ No. Common exchange semantics matter; common internal systems do not. Insisting that supply chain partners adopt one platform is a commercial position, not a technical necessity. **How should organisations monitor changing DPP standards?**\ Maintain an inventory of every standard, specification and profile in use with its version, assign a named owner for monitoring, subscribe to the publication channels of the relevant bodies and the Official Journal, review on a defined cadence, and route any change through normal impact assessment and change control. ## Key Takeaways * The landscape has five zones: legal framework, standardisation direction, standards ecosystem, technical standardisation domains and implementation ecosystem. Only the first creates obligation. * Legal effect runs on a separate rail from institutional role. Binding law, product-specific requirement, harmonised standard where applicable, other standard or specification, and implementation choice are five different positions, not one spectrum of seriousness. - The European Commission requests and recognises standards; CEN, CENELEC and ETSI develop them; ISO and IEC standardise internationally; GS1 publishes widely used industry standards. None of these is interchangeable with another. - The joint CEN and CENELEC committee JTC 24 covers the passport framework and system, horizontally and product agnostically, and several of its standards have had their references cited in the Official Journal while others in the same series have not. - Nothing in the framework regulation universally mandates GS1, the GTIN, GS1 Digital Link, EPCIS or QR codes. Product-specific measures, not general assumptions, decide what applies. - Interoperability is layered, and semantic interoperability is the layer that fails quietly. Identical field names with different definitions produce clean exchanges and wrong conclusions. - A standard defines an exchange contract, not a system of record, a database design or an operating model. Standards selection is a small part of a passport programme. - Standards change. Version inventory, named ownership and a defined impact path are operational necessities, not documentation hygiene. ## Related Articles * [What is GS1?](/docs/knowledge-base/standards-and-technology/what-is-gs1) * [How Will Digital Product Passports Change Product Compliance?](/docs/knowledge-base/standards-and-technology/how-will-digital-product-passports-change-product-compliance) * [How Conformity Assessment Works for Digital Product Passports](/docs/knowledge-base/regulations/how-conformity-assessment-works-for-digital-product-passports) * [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work) * [QR Codes vs GS1 Digital Link: What's the Difference?](/docs/knowledge-base/standards-and-technology/qr-codes-vs-gs1-digital-link) * [What is a GTIN?](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) * [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier) * [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link) ## Related Glossary Terms * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [ESPR](/docs/knowledge-base/glossary/espr) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) * [Harmonised Standard](/docs/knowledge-base/glossary/harmonised-standard) * [Presumption of Conformity](/docs/knowledge-base/glossary/presumption-of-conformity) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [GTIN](/docs/knowledge-base/glossary/gtin) * [GS1](/docs/knowledge-base/glossary/gs1) * [GS1 Digital Link](/docs/knowledge-base/glossary/gs1-digital-link) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [QR Code](/docs/knowledge-base/glossary/qr-code) * [Resolver](/docs/knowledge-base/glossary/resolver) * [EPCIS](/docs/knowledge-base/glossary/epcis) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Product Data](/docs/knowledge-base/glossary/product-data) * [System of Record](/docs/knowledge-base/glossary/system-of-record) * [Data Governance](/docs/knowledge-base/glossary/data-governance) ## References * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, 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) No 1025/2012 on European standardisation, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2012/1025/oj](https://eur-lex.europa.eu/eli/reg/2012/1025/oj) * Commission Implementing Decision (EU) 2026/1736 of 14 July 2026 on harmonised standards for digital product passports drafted in support of Regulation (EU) 2024/1781: [https://eur-lex.europa.eu/eli/dec\_impl/2026/1736/oj/eng](https://eur-lex.europa.eu/eli/dec_impl/2026/1736/oj/eng) * Commission Implementing Decision C(2024) 5423 of 31 July 2024 on a standardisation request to CEN, CENELEC and ETSI as regards digital product passports, as amended by Commission Implementing Decision C(2025) 8024 of 28 November 2025 (referenced in the recitals of Implementing Decision (EU) 2026/1736): [https://eur-lex.europa.eu/eli/dec\_impl/2026/1736/oj/eng](https://eur-lex.europa.eu/eli/dec_impl/2026/1736/oj/eng) * European Commission, harmonised standards for the digital product passport: [https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/digital-product-passport-dpp\_en](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/digital-product-passport-dpp_en) * European Commission, harmonised standards policy pages: [https://single-market-economy.ec.europa.eu/single-market/european-standards/harmonised-standards\_en](https://single-market-economy.ec.europa.eu/single-market/european-standards/harmonised-standards_en) * CEN and CENELEC, "Digital Product Passport, the cornerstone for the implementation of sustainability and circularity on the European Single Market", 15 July 2026: [https://www.cencenelec.eu/news-events/news/2026/en-in-the-spotlight/2026-07-15-dpp/](https://www.cencenelec.eu/news-events/news/2026/en-in-the-spotlight/2026-07-15-dpp/) * CEN and CENELEC, European standardisation organisations and technical bodies: [https://www.cencenelec.eu/about-cen-cenelec/](https://www.cencenelec.eu/about-cen-cenelec/) * DIN and DKE, announcement of the joint ISO and IEC committee ISO/IEC JTC 5 on the Digital Product Passport, 20 April 2026: [https://www.vde.com/en/press/press-releases/din-dke-jtc-5-product-passport](https://www.vde.com/en/press/press-releases/din-dke-jtc-5-product-passport) * ISO, standards development and committee structure: [https://www.iso.org/standards.html](https://www.iso.org/standards.html) * IEC, standards and committee structure: [https://www.iec.ch/standards-development](https://www.iec.ch/standards-development) * GS1, GS1 standards documentation: [https://www.gs1.org/standards](https://www.gs1.org/standards) ## About This Article About This Article
Last Reviewed
2026-08-09
Next Scheduled Review
2027-08-09
Article Version
1.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. ## Related Docs * [Standards & Technology](/docs/knowledge-base/standards-and-technology/overview) * [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier) * [What is GS1?](/docs/knowledge-base/standards-and-technology/what-is-gs1) * [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) * [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link) * [What is EPCIS?](/docs/knowledge-base/standards-and-technology/what-is-epcis) * [How Conformity Assessment Works for Digital Product Passports](/docs/knowledge-base/regulations/how-conformity-assessment-works-for-digital-product-passports) * [Who Is Legally Responsible for a Digital Product Passport?](/docs/knowledge-base/regulations/who-is-legally-responsible-for-a-digital-product-passport) * [How Digital Product Passports Will Be Enforced](/docs/knowledge-base/regulations/how-digital-product-passports-will-be-enforced) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) * [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap)