The Digital Product Passport Standards Landscape

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, 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 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.

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 into Enterprise Systems & Data Architecture and Implementation.

Table of Contents

• Definition
• Why the DPP Standards Landscape Is Confusing
• The DPP Standards Landscape Model
• Law, Standards and Implementation Choices
• The EU Legal Framework
• What Is a Standardisation Request?
• The European Commission’s Role
• CEN and CENELEC
• DPP Standardisation and JTC 24
• International Standards: ISO and IEC
• Where GS1 Fits
• What DPP Standards Need to Solve
• Identification Standards
• Data Carriers
• Resolution and Discovery
• Event and Traceability Data
• Interoperability
• What Is Semantic Interoperability?
• Data Models, Schemas and Vocabularies
• APIs and Protocols
• Standards and Enterprise Architecture
• Standards and DPP Implementation
• Standards and Conformity Assessment
• Standard vs Harmonised Standard
• Are DPP Standards Mandatory?
• How to Read a DPP Standard or Specification
• Managing Standards Versions and Change
• Practical Example
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Articles
• Related Glossary Terms
• References
• About This Article

Definition

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.

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.

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.

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? explains that mechanism, and 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”.

What Is a Standardisation Request?

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.

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.

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:

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.

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?.
• 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?.
• EPCIS is not a Digital Product Passport. It is an event data standard. See What is EPCIS?.
• A QR code is not a Digital Product Passport. It is a data carrier symbology. See What is a Data Carrier? and 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? 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? works through the levels, and 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:

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?.

Resolution and Discovery

The landscape-level shape is short:

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 glossary entry gives the concise definition, and 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.

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 is the most widely used standard for representing such events, and What is EPCIS? explains it properly. 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.

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 for a given attribute.
• How your databases are designed.
• Who owns master data, or how stewardship is organised.
• What your 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?, ERP vs PIM vs PLM: What’s the Difference?, What Is a System of Record? and 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, with supplier readiness, validation, evidence and assurance covered in their own articles. This article does not recreate any 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. 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 and 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 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.

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.

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 and 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

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

Related Articles

• What is GS1?
• How Will Digital Product Passports Change Product Compliance?
• How Conformity Assessment Works for Digital Product Passports
• How Does a Digital Product Passport Work?
• QR Codes vs GS1 Digital Link: What’s the Difference?
• What is a GTIN?
• What is a Product Identifier?
• What is GS1 Digital Link?

Related Glossary Terms

• Digital Product Passport
• ESPR
• Delegated Act
• Harmonised Standard
• Presumption of Conformity
• Conformity Assessment
• Product Identifier
• GTIN
• GS1
• GS1 Digital Link
• Data Carrier
• QR Code
• Resolver
• EPCIS
• Product Traceability
• Product Data
• System of Record
• 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
• Regulation (EU) No 1025/2012 on European standardisation, Official Journal of the European Union: 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
• 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
• 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
• European Commission, harmonised standards policy pages: 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/
• CEN and CENELEC, European standardisation organisations and technical bodies: 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
• ISO, standards development and committee structure: https://www.iso.org/standards.html
• IEC, standards and committee structure: https://www.iec.ch/standards-development
• GS1, GS1 standards documentation: https://www.gs1.org/standards

About This Article

Related Docs

• Standards & Technology
• What is a Product Identifier?
• What is GS1?
• What is a Data Carrier?
• What is GS1 Digital Link?
• What is EPCIS?
• How Conformity Assessment Works for Digital Product Passports
• Who Is Legally Responsible for a Digital Product Passport?
• How Digital Product Passports Will Be Enforced
• Building an Enterprise Digital Product Passport Architecture
• How to Build a Digital Product Passport Implementation Roadmap