What Actually Goes Into a Digital Product Passport?

When people talk about the Digital Product Passport, the image is usually simple.

A QR code on a product. A scan. Some information on a screen.

But the real question is not the QR code. The real question is what sits behind it.

A Concept Defined, but Not Fully Filled

The Digital Product Passport (DPP) is introduced under the Ecodesign for Sustainable Products Regulation (EU 2024/1781).

The regulation defines the DPP as a structured digital record containing relevant product information to support sustainability, circularity, and compliance.

But it does not define a fixed dataset.

Instead, it sets principles:

• Data must be accurate, complete, and up to date
• It must be linked to a unique product identifier
• It must be accessible via a data carrier (for example, a QR code)
• It must use open, interoperable formats
• It may apply at model, batch, or item level

What goes into the passport is not defined once, but determined later for each product group.

From Concept to Structure: How Data Is Organized

To understand how this information might be structured, the CIRPASS project provides a useful reference.

CIRPASS describes the DPP as:

• A structured dataset
• Linked to a product through a unique identifier
• Accessible via digital resolution mechanisms
• Managed across distributed systems

Its architecture introduces several key elements:

• Product UID and URI transformation
• Registry and resolver layers
• Decentralized data repositories
• Validation mechanisms
• Structured data representation using JSON-LD

The architecture also introduces validation concepts such as SHACL, allowing data to be checked against predefined rules.

This shows that the passport is not just a collection of fields. It is a structured, validated, and interoperable dataset.

Deciding What Data Belongs: The JRC Methodology

A key development in 2026 came from the European Commission’s Joint Research Centre (JRC).

Instead of starting with predefined fields, the methodology proposes a structured way to decide what data should be included.

It suggests that DPP data should be selected based on:

• Policy objectives
• Use cases
• Data availability
• Feasibility
• Access rights

It also introduces categorization such as:

• Essential data
• Recommended data
• Optional data

This adds an important layer to the DPP discussion.

The passport is not only about structure. It is also about how data is selected and justified.

A Concrete Example: The Battery Passport

The most detailed example available today comes from the EU Battery Regulation (EU 2023/1542).

From 2027, certain batteries placed on the EU market must have a battery passport.

The regulation defines specific data categories, including:

• Material composition and chemistry
• Carbon footprint
• Recycled content
• Performance and durability metrics
• Responsible sourcing information
• Safety and compliance data

It also introduces a layered access model:

• Publicly accessible information
• Restricted data for authorities and operators
• Detailed lifecycle and performance data

The battery passport shows that a DPP is not a single flat dataset. It is a multi-layered structure with different audiences and levels of detail.

Multiple Layers, Not One Definition

Across these sources, a consistent pattern appears.

Different actors define different parts of the passport:

• The regulation defines the framework and principles
• Product-specific rules define required data categories
• The JRC defines how data should be selected
• CIRPASS defines how data is structured and validated
• Sector regulations like the battery passport show how it works in practice

Each layer contributes to the overall shape of the DPP.

A Structured but Evolving System

The Digital Product Passport is often described as a single concept.

In practice, it is a combination of:

• Legal requirements
• Data selection methodologies
• Structured data models
• Validation mechanisms
• Access control rules
• Product-specific implementations

The battery passport provides one of the first detailed examples.

Other product groups will follow with their own specifications.

Sources