Your digital product passport starts in your product data

You have product data in several places. Item numbers sit in the business system, material details in spreadsheets and product copy in the PIM. When someone asks you to show where a material comes from, the work often starts with finding out which version applies.

At the same time, a repairer needs the right spare parts information, and authorities may need to check product details. A digital product passport therefore makes data governance an operational issue. The QR code is the easy part.

From product data to market requirements

For a product owner, a certification round can expose a familiar problem: the attributes exist, but no one can quickly say who owns them or when they were last checked. Material data may sit with a supplier, product dimensions in the PIM and manufacturing details in the business system. A QR code doesn’t resolve that disagreement.

The EU’s Ecodesign for Sustainable Products Regulation, ESPR (EU) 2024/1781, entered into force on 18 July 2024 and is the legal basis for digital product passports on the European market. For Swedish manufacturers and importers, this means product information needs to be managed and shared across the value chain, from design and manufacturing to repair and recycling.

This is infrastructure for traceability and the circular economy. The product passport should follow the product through its life cycle, and the information can be used by several parties, including authorities. That makes responsibility for data, changes and sources part of the work on the product.

Preparation should therefore start with the data flow. Find out where the attributes are, who can approve them and how you can show that the information is current. If those questions are left until the end, you risk publishing a passport whose content can’t be trusted.

What ESPR actually requires of you

ESPR doesn’t introduce product passports for all goods at once. The requirements apply to product groups for which the European Commission adopts specific delegated acts. Each act sets out the requirements for the product group concerned, so you need to follow developments for your particular products.

When a delegated act requires a product passport, the product may only be placed on the market or put into service if the passport exists and the information is correct, complete and up to date. Responsibility normally lies with the manufacturer when the product is made in the EU, and with the importer when it is made outside the EU. Someone in your organisation needs to be able to stand behind the information, even when it comes from a supplier.

The EU’s DPP registry became operational on 20 July 2026, and for iron and steel the first product-specific requirements under ESPR are expected to be adopted in the fourth quarter of 2026. Once a delegated act has been adopted, economic operators will get a transition period of at least 18 months. For certain batteries, including batteries for electric vehicles, light means of transport and industrial batteries, the product passport becomes mandatory on 18 February 2027 through the EU Batteries Regulation, which is separate legislation alongside ESPR, according to the European Commission’s information on the digital product passport.

Carry out an internal review for each relevant product group. Decide who monitors delegated acts, which products may be covered and which information you can already verify. That review gives you a useful starting point even before the specific requirement has been decided.

Product identity and data carriers in practice

A product passport needs to be linked to the right product over time. Product identity therefore has to be stable and clearly related to the information that different systems and parties use. If item numbers or attributes change without control, a working QR code can lead to information that doesn’t match the product.

The Swedish Agency for Economic and Regional Growth describes the product passport as a structured, searchable set of information, accessible via a unique product identity and linked from a data carrier such as a QR code. The information should follow open standards and be machine-readable, according to the agency’s report on traceability and digital product passports.

Start by separating identity, attributes and data carrier. The identity points to the product. The attributes describe it. The data carrier makes it possible to find the information. The QR code can lead to the passport, but it shouldn’t be the only place where you store the product’s key or its history.

PDF files and free text can be useful as a readable complement, but they work less well when systems need to search, compare and check data. Define attributes with clear formats and rules. Also decide how changes are recorded, so that an update to a material value doesn’t overwrite the information needed to understand earlier product versions.

A stable internal product key gives the flow its context. It makes it possible to connect the website, product passport and business system without confusing a presentation address with the product’s identity.

How PIM and the business system support the data handover

A PIM can gather and govern product attributes such as material content, origin, technical properties and repairability. The business system often contributes item references, batch details and information about manufacturing or stock. The systems have different roles. Neither of them automatically knows who should approve all the data a product passport needs.

A common misjudgement is to treat the PIM as a complete source of truth. A PIM can structure and publish data, but quality depends on the sources, rules and workflows you have built. Likewise, the business system is good at its operational data, but it doesn’t replace a model for things like material properties or repair.

Link each attribute to a source system and a responsible role. Add validation rules before publishing, such as mandatory fields and permitted formats. If supplier data needs to be reviewed before use, the approval should be visible in the workflow. A stable ID should also follow the product through the integrations.

A QR link can work even when the information behind it is contradictory. That happens when the same field exists in several systems and no one knows which version applies. A clear product data model helps you work out what the PIM can handle and where responsibility needs to sit outside the system. See also how a PIM system organises product information.

Access, APIs and standards

A digital product passport should be built as an information layer with controlled access. Consumers may need basic product information, while a repairer needs instructions and an authority may need to check information for supervision. If everyone sees the same data, you risk exposing confidential information. If access control is built late, changing both the information model and the integrations becomes costly.

[Image: Illustration showing the DPP (digital product passport) as an API-based information layer for different stakeholders such as consumers and authorities.]

The Swedish standard SS-EN 18239 covers access rights, information system security, data protection and protection of confidential business information. It applies to product groups covered by DPP requirements under ESPR, while the specific rights are set in each delegated act, according to SIS information on SS-EN 18239.

SIS also describes a standardisation basis covering unique identifiers, data carriers, data exchange protocols, long-term storage, APIs, interoperability, access control and data authentication. That gives a clear technical direction: create interfaces that make information available in a controlled and understandable way.

Document who may see each data point and on what terms. Link fields to source, owner and validity. Version numbers and verification mechanisms can help you detect accidental changes or tampering. A QR code can open the right view, but trust requires that you can also explain where the information comes from and how it has been checked.

Who owns which data point

The EU registry is intended to work as an index of product passports, while the information itself is handled in a decentralised way, according to the Swedish Environmental Protection Agency’s FAQ. Responsibility for the data doesn’t disappear when a passport is published. The company needs to be able to show where the information is, who approved it and how changes are handled.

In practice, a supplier may provide material data, a product owner approve the product’s properties and the PIM manage the approved attributes. The business system can continue to own item and manufacturing references. The product passport compiles the information according to the rules for access and publishing. This division of responsibility should be documented per data point, since a single owner for the whole passport is often too vague.

A spreadsheet cell with a material value is not the same as a verified value with a source and an approval.

Assign an owner to each data domain and decide what happens when the source changes. That work ties in with systematic management of product data. Without that governance, the product passport becomes one more place where uncertain data is shown, with a QR code in front of it.

Five steps to prepare

Start with the product groups. Map which products may be covered and who follows the delegated acts. At the same time, build a picture of where product data sits, including supplier files and manual registers.

Then choose the product identity and model the attributes. Decide which fields belong to the product, which may vary between manufacturing versions and which require documentation from an external party. Make the model clear enough for those who own the information to maintain it.

Build the validation in the PIM and link each field to a source. Require approval when information doesn’t come from a controlled system. Product owners and data owners need to set aside time for this. If the organisation lacks owners for master data, sort that out before you automate publishing.

Next, connect the systems and decide which data should be passed on through standardised APIs. Test how a change travels all the way from the source to the product passport. A well-designed integration with the business system also needs to handle errors, changes and traceability. The SIS standard on access and security is relevant when you design permissions and information protection.

Finish with ongoing management. Someone has to check that integrations work and that changes don’t make the product information outdated. If you can’t staff that task internally, management needs a clear owner and an agreed way of working.

Questions to ask your supplier

Ask the supplier to show how an attribute from a supplier source gets approved, versioned and published in the product passport. The answer reveals whether the solution handles responsibility and history.

Also ask how access differs between consumers, resellers, service partners and authorities. Ask for a concrete example of how incorrect or outdated information is stopped before publishing. Clear answers show whether the supplier has thought through both the information model and ongoing management.

Glanser can carry out a 72-hour analysis of functionality and integrations, with a functional specification, a prototype and a cost picture. You set aside two hours for a meeting and receive the material free of charge within 72 hours, and the material is yours.