Who can view and edit your DPP data

Introduction: The Same QR Code, Different Responses

When imagining a Digital Product Passport (DPP), one might naturally picture a public webpage accessible by scanning a QR code on a product label. This is only partially true. In reality, the passport functions as a multi-layered data repository: while some parts may be open to everyone, other information is restricted to specific stakeholders within the supply chain—with only a select few authorized to input or update that data.

Determining who sees what and who can modify what is, therefore, one of the most critical design decisions when implementing a DPP. An access matrix that is too open risks exposing trade secrets, while one that is too restrictive renders the passport useless for those involved in repair, recycling, or regulatory oversight.

In this article, we explore the five defined user profiles, the European regulatory framework, and practical criteria for designing access permissions for your passport.

---

The Regulatory Principle: Differentiated Access Based on Stakeholder Type

The governing framework is Regulation (EU) 2024/1781 establishing a framework for setting ecodesign requirements for sustainable products (ESPR). Rather than establishing a fixed, universal definition of what constitutes public data, the Regulation sets out core principles applicable to all passports:

• Free access based on access rights. Consumers, economic operators, and other relevant stakeholders must be able to consult the passport at no cost, within the scope of the access rights granted to their specific category (Art. 10).
• Reading and writing are distinct rights. The authority to input, modify, or update information within the passport is restricted according to the access rights defined in the relevant delegated acts (Art. 10).
• Specific rules are established via delegated acts. For each product group, the delegated act adopted pursuant to Art. ... 4 specifies what data goes into the passport, who can access it, and who can update it.

In other words: The ESPR provides the framework, while the sector-specific delegated act fills in the permissions table. Until the delegated act for your product group is published, it is advisable to design a flexible permissions system—one capable of shifting a field from "public" to "restricted" (or vice versa) without requiring a rewrite of the underlying architecture.

---

The Five Access Profiles

A practical starting point is to map out the passport’s intended users. We identify five such profiles:

Profile	Who they are	What they need (examples)	Typical access type
Consumers	Those who purchase and use the product	Composition, instructions for use, recycling guidelines	Access to public data
B2B Clients and Partners	Professional clients and supply chain partners	Technical data for integrating a component into their own product	Access to restricted data
Repairers and Maintenance Technicians	Technicians who repair or maintain the product	Disassembly diagrams, spare parts codes, diagnostic information	Access to restricted data; potential to log interventions
Recyclers and End-of-Life Managers	Those who handle the product at the end of its life	Materials present, hazardous substances and their location, disassembly instructions	Access to restricted data; potential to update the product's status
Market Surveillance Authorities and Customs	Market oversight bodies and customs authorities	Declaration of conformity, technical documentation	Broad access for inspection and control purposes

1. Consumers: The Public Tier

This is the layer visible to anyone who scans the data carrier. It must be understandable and useful: product composition, instructions for proper use, guidance on waste sorting and recycling, and environmental information as required by the delegated act.

The most common mistake is to treat this level either as a marketing showcase or, conversely, as an unreadable technical data dump. Consumers need a small amount of well-presented information—typically accessed via a smartphone in a matter of seconds.

2. B2B customers and partners: technical data for the supply chain

Within industrial value chains, a component’s passport serves as a data source for the finished product’s passport. A manufacturer integrating your component requires technical specifications, material data, or environmental footprint details—information that would not be appropriate for public disclosure.

This scenario raises an important question: how can access be granted exclusively to authorized partners, and how can it be revoked when the business relationship changes? This necessitates robust identification and credential management mechanisms, rather than a simple hidden link.

3. Repairers and maintenance providers: the right to repair via the DPP

The passport is one of the tools through which Europe supports the circular economy and the right to repair. Professional repairers require disassembly instructions, spare parts lists, and diagnostic information—valuable data that many manufacturers have, until now, guarded jealously.

If your products require maintenance, consider two aspects:

• repairers must be able to access repair information;
• depending on the sector, they may also need to record the interventions performed, shifting their role from mere readers to parties who can write data into the passport.

This second point alters the architecture: it is necessary to define who is authorized to write data, which fields they may modify, and how each change is tracked.

4. Recyclers and end-of-life managers: knowing what’s inside

For those handling a product at the end of its life, the key question is: what materials does it contain, and where are they located? Recyclers need precise information regarding hazardous or concerning substances and their location within the product, as well as instructions for safe disassembly.

While such data improves recycling quality and operator safety, it may also reveal design details; for this reason, it is generally classified as restricted information.

5. Market surveillance authorities and customs: the level of oversight

Market surveillance authorities and customs agencies use the passport to verify compliance—checking declarations of conformity, technical documentation, and any relevant test reports. This level typically grants the broadest access.

The passport also connects to the EU registry of digital product passports, as provided for under Art. 13 ESPR, which stores product identifiers and allows customs authorities to verify the existence of a passport at the time of import.

---

Reading is not writing: who updates the passport

A comprehensive access matrix must distinguish between at least three types of actions:

1. Reading — consulting data relevant to one’s specific access level.
2. Entry and modification — creating or correcting data.
3. Lifecycle updates — adding events that occur after the product has been placed on the market (e.g., repairs, changes of ownership, remanufacturing, or end-of-life status).

In general, the economic operator who places the product on the market is responsible for the passport data and retains write access to the fields within their scope of responsibility. Other entities in the supply chain—such as DPP service providers, authorized representatives, repairers, refurbishers, remanufacturers, and recyclers—may only intervene within the limits established by the delegated act.

A typical scenario involves a transfer of responsibility: when a product is remanufactured and reintroduced to the market, or when the provider hosting the passport changes, access rights must be transferred in a controlled manner.

---

A concrete example: the battery passport

Regulation (EU) 2023/1542 concerning batteries is the first to mandate a digital passport, providing a very concrete example of tiered access.

• Who is affected? As of February 18, 2027, a passport is required for batteries for light means of transport (LMT), industrial batteries with a capacity exceeding 2 kWh, and electric vehicle batteries (Art. 77).
• Three levels of access. Art. Article 77, paragraph 2, distinguishes between information accessible to the public, information restricted to notified bodies, market surveillance authorities, and the Commission, and information accessible to persons with a legitimate interest.
• Field-by-field assignment. Annex XIII assigns each data point to its respective access level: for instance, detailed composition, disassembly instructions, and dynamic data—such as the battery’s state of health—are not public.
• Defining "legitimate interest." This typically includes repairers, refurbishers, second-life operators, and recyclers. Article 77, paragraph 9, tasks the Commission with defining—via an implementing act—who falls into this category and what they are permitted to do with the data; the deadline for this was August 18, 2026. Before designing access permissions, it is advisable to check the publication status of this act.
• Who has write access. Similarly, the rights to input, modify, or update information are restricted in accordance with Annex XIII and the aforementioned implementing act (Article 78).

The battery model serves as an excellent preview of how other product groups will be handled under the ESPR: a single passport, multiple access levels, and circumscribed write permissions.

---

Technical Standards: prEN 18239

From a technical perspective, European standardization efforts (CEN/CENELEC JTC 24) are defining how to implement these principles in practice. The draft standard prEN 18239 addresses access rights management, information system security, and commercial confidentiality for the Digital Product Passport (DPP).

Key topics covered include:

• Definition of roles (economic operators, primary and back-up DPP service providers, repairers, recyclers, and authorities);
• Procedures for the transfer of responsibilities and rights between economic operators—for instance, when there is a change in ownership or service provider;
• Exchange of information regarding access rights among operators, back-up systems, and the European Commission’s registry.

Monitoring the development of this standard is highly beneficial when selecting service providers and system architectures that are already aligned with what will become the definitive industry standard.

---

How to Design an Access Matrix: An Operational Checklist

1. Identify the actual users. Within your supply chain, who will truly need to consult the product passport? Not every product involves repairers or B2B partners.
2. Classify every data field. For each piece of data, specify the access level (public, B2B, repair, end-of-life, or authorities) and determine who has the authorization to write or input that data. A field-by-field table is the most effective tool for this.
3. Start with the delegated act (if applicable). In cases where the classification is already mandated by regulation—such as in Annex XIII for batteries—there is no room for discretion.
4. Safeguard sensitive commercial information. Distinguish between data that is genuinely necessary for repair, recycling, or regulatory compliance, and information that would merely expose your proprietary know-how. 5. Provide for the identification and verification of entities. A restricted access level requires authentication, credential management, and the ability to revoke access.
5. Track every change. Record who wrote what and when; this is essential for accountability, auditing, and regulatory oversight.
6. Plan for the transfer of rights. Processes such as product regeneration, changes in ownership, or switching DPP providers must ensure that a passport does not become "orphaned."
7. Remain flexible. Delegated acts will be introduced for different product groups at different times; a configurable system avoids costly redesigns.

---

Conclusion

The Digital Product Passport is a multi-faceted tool: it communicates simply with consumers, technically with partners, operationally with repairers and recyclers, and formally with authorities. Designing access levels effectively ensures that the passport is useful for those who use it and secure for those who publish it.

The golden rule is simple: every data field must have an intended recipient and a party responsible for it. Once this is established, the rest is a matter of implementation.