Aller au contenu principal
Regulation

JRC145830 Methodology on Digital Product Passport — Arianee Decode

By Pierre-Nicolas Hurstel · CEO & Co-Founder
14 min

Context: an expected report, a status to understand correctly

On 19 March 2026, the Joint Research Centre — the European Commission's scientific service — published report JRC145830, entitled Methodology for defining data requirements for the Digital Product Passport under the ESPR framework. 121 pages, co-written by TNO, maki Consulting and the JRC, under Commission coordination.

Before diving into the content, a word on the text's status. This is not a legal act. It is a scientific methodology intended for the teams drafting preparatory studies under ESPR, integrated into the revised MEErP (Methodology for Ecodesign of Energy-related Products). Its function: to structure the drafting of categorical delegated acts that will define, product by product, what a Digital Product Passport (DPP) must contain. The report presents itself as a first-time design, modular and intended to evolve.

But its practical scope is considerable. It is the common grammar on which delegated acts will be built for the decade ahead, from textiles to electronics through batteries, steel and furniture. At Arianee, we have been supporting actors in durable goods, electrical and electronic equipment, batteries, and fashion and luxury in building their DPPs for eight years. Here is our operational decode.

Section 01 — A four-step, fourteen-substep methodology

The JRC structures its framework in four steps, themselves broken down into fourteen sub-steps. This level of detail is what makes the document operational.

Step A — Scope and context (A.1 to A.4)

Define the product scope, identify stakeholders and data roles, catalogue existing obligations under other EU laws, and assess the current state of data collection practices in the value chain.

Step B — Use cases and data requirements (B.1 to B.4)

Specify use cases (in the technical sense), validate them through consultation, catalogue the necessary data, then prioritise and classify them. This is where the 'essential / strongly recommended / voluntary' classification is built.

Step C — Design and development (C.1 to C.5)

Five critical sub-steps. C.1 and C.2 cover vocabulary selection or extension. C.3 sets granularity (model, batch or item). C.4 sets access rights. C.5 sets lifecycle data governance. The last three are, in our reading, the structural core of the report.

Step D — Validation

Internal verification and targeted stakeholder consultation on the proposed specification, distinct from the consultations conducted in B.2.

Section 02 — Three data tiers — and in reality a six-cell matrix

This is the most publicised element of the report. DPP data is classified into three tiersessential, strongly recommended, voluntary — based on a value-effort analysis and the reality of industrial practices.

But this synthesis conceals a finer reality. The report proposes a six-cell Data Needs Classification Matrix (A to F) that crosses ESPR status, perceived value, current collection state in the industry, value/effort balance and key barriers. Concretely, an 'essential' piece of data that is a widespread practice (cell A) does not pose the same implementation problem as 'essential' data without established practice (cell D, candidate for deferral or optional status).

Compliance teams are well-advised to use the six-cell matrix internally for their arbitration, and retain the triptych for external communication.

The contribution of this gradation: it changes how brands think about their roadmap. Rather than reasoning in binary compliant / non-compliant terms, one enters a progressive maturity logic — a mandatory core, a leadership zone for brands wanting to get ahead, and an innovation space to differentiate the product experience.

Section 03 — The second framework, little commented: five differentiated access tiers

This is, in our reading, the most structuring and least commented contribution of the report. Annex 8 introduces a five-tier access model, based on the Role-Based, Need-to-Know principle. It applies not to the entire DPP, but property by property — each data field can have its own access regime.

  • Tier 1 — Public / Consumer: Consumers, potential buyers, civil society. Accesses top-level scores (durability, repairability), primary material composition, usage instructions and compliance status.
  • Tier 2 — Professional operator: Independent repairers, refurbishers, remanufacturers. Accesses disassembly instructions, schematics, spare parts list, diagnostic codes.
  • Tier 3 — End-of-life operator: Recyclers, sorters, recovery facilities. Accesses detailed material composition, location and identity (CAS number) of substances of concern.
  • Tier 4 — Production / Supply network upstream: Processors, manufacturers, assemblers. Accesses the data needed to prepare their own DPP in the upstream direction towards the final product.
  • Tier 5 — Regulatory & Enforcement: Market surveillance authorities, customs, European Commission. Full access to technical documentation, test reports, certificates.

Tier 4 deserves particular attention. It introduces an essential notion — the 'stand-in DPP': a manufacturer can initially fill certain data fields with default values (for example a carbon footprint calculated on industry averages). When an upstream supplier is later able to provide their own verifiable data, they are authorised to take over and overwrite the default value. This requires a sophisticated identity and cryptographic rights architecture, capable of managing data ownership transfers across the supply chain.

For the Battery Regulation, already operational, the report describes an equivalent model with only four tiers (Box 3, p. 23). The five-tier ESPR model is more granular — it notably distinguishes repair operators (Tier 2) from recyclers (Tier 3) and the upstream supply chain (Tier 4).

Section 04 — Core DPP and Life-cycle Log: the governance architecture

Annex 9 introduces another fundamental framework, even less commented: the separation between Core DPP and Life-cycle Log.

Core DPP (Layer 1 — Immutable): Initial manufacturer data, declared at market launch — compliance, design specs, performance metrics. Editing rights extremely restricted (a safety recall, for example).

Life-cycle Log (Layer 2 — Append-only): Ledger linked to the Core DPP. All downstream events — repairs, software updates, refurbishment, ownership transfers, end of life — are recorded as timestamped entries signed cryptographically.

Four principles structure this framework:

  1. 01.Data segregation between Core DPP and Life-cycle Log.
  2. 02.Authenticated, role-based write permissions: the actor must be authenticated in their role to write.
  3. 03.Verifiability and attributability: each entry carries a traceable digital signature.
  4. 04.Event standardisation: a repair event is a structured, standardised object (type, date, component ID, repairer ID, warranty).

The report identifies seven trigger events: information correction, professional repair, software/firmware update, refurbishment and preparation for resale, component upgrade, ownership transfer, and end-of-life collection.

A DPP data point is not a file you edit: it is a signed registry you enrich in successive layers, with cryptographic traceability of authors.

For the first time, a Commission text explicitly describes the two-layer architecture — immutable Core DPP and signed Life-cycle Log — on which we have been building passports since 2018.

Section 05 — Granularity: model, batch, item — and the hybrid approach

Annex 7 details granularity choices. Three possible levels, explicitly permitted by ESPR:

  • Model-level: One DPP per model, shared by all units.
  • Batch-level: One DPP per production batch (useful when carbon footprint or raw materials vary by batch).
  • Item-level: One DPP per individual unit (mandatory for batteries, for example).

The report explicitly recommends hybrid approaches: static data at model level (composition, design), dynamic data at item level (repair history, health state). This flexibility is validated by JTC 24 standards and offers a pragmatic path for fashion and luxury brands hesitating between item-level (expensive at scale) and model-level (insufficient for post-purchase service). Multi-level referencing between identifiers allows navigation between levels.

Section 06 — The real timeline — and who goes first

Based on the ESPR Working Plan adopted in April 2025, here is the indicative timeline for delegated acts:

CategoryExpected delegated act
Iron and steel2026
Textile & leather2027
Furniture2027–2028
Consumer electronics2027–2028
Tyres · steel · aluminium · chemistry2028
Construction · toys · cosmetics · detergents2029–2030

Iron and steel is the pilot, not textiles. For fashion and luxury brands, this leaves approximately twelve to eighteen additional months before the textile delegated acts are finalised.

To watch in parallel:

  • JTC 24 technical standards (CEN-CENELEC), covering identifiers, data carriers, access rights, interoperability, data exchange and lifecycle APIs. Publication expected early 2026.
  • The EU central DPP registry, which the Commission must put in place before 19 July 2026 (Article 13 ESPR). Interoperable web portal planned (Article 14).
  • DPP regimes outside ESPR already active or imminent: Batteries Regulation (first rules early 2027), Construction Products Regulation, Toy Safety, Detergents, Packaging, Critical Raw Materials Act.

Section 07 — Five concrete implications for brands

  1. 01.DPP compliance becomes cross-functional. Step A.4 requires mapping who collects which data in the value chain. No possible delegation to a single team (IT, CSR or supply chain alone won't suffice).
  1. 01.Strongly recommended is a strategic signal. Brands that stop at the essentials will be compliant but indistinct. Strongly recommended data is what interests distributors, repairers and secondhand resellers.
  1. 01.Interoperability becomes non-negotiable. Shared vocabularies (with GS1 and Schema.org cited explicitly), granular access rights, the central EU registry and portability without vendor lock-in become market requirements.
  1. 01.DPP service provider status becomes a structural choice. Article 2 of the ESPR explicitly defines the notion of 'digital product passport service provider' — a natural or legal person authorised to operate a DPP on behalf of a manufacturer. Choosing a compliant and recognised provider becomes a long-term decision.
  1. 01.Identity and rights governance becomes critical. Five access tiers, rights per data property, a cryptographically signed Life-cycle Log, data ownership transfers across the supply chain — all this requires a robust identity infrastructure, not a simple product CMS.

Section 08 — What we take away at Arianee

Three elements of the report seem particularly structuring for the decade ahead.

First, the value-effort logic anchors the regulation in existing practices. The JRC avoids imposing a theoretical ideal on a value chain that could not sustain it, and explicitly recognises that granularity is the main cost driver.

Then, the five-tier access model transforms the DPP into a data governance infrastructure — not a simple descriptive file. This is consistent with what we have carried since our beginnings: a DPP is useful to the extent that it allows authorised actors to act with it, in strict respect of each party's confidentiality.

Finally, the Core DPP + Life-cycle Log architecture validates a pattern we have made our own from the start: a signed registry, an immutable layer, append-only logs verifiable by cryptographic signature. We welcome its formalisation by the JRC.

The report doesn't do everything. The JTC 24 technical standards are yet to be published, categorical field lists are yet to come, and the central EU registry is yet to be built. But it lays a coherent common foundation, and that is what brands needed to move from pilot to industrialisation.

Section 09 — What to do in the coming weeks

For teams steering a DPP project, four short-term actions:

  1. 01.Read JRC145830 in full, particularly Annexes 7, 8 and 9 — often neglected in public summaries even though they carry the most structuring elements.
  2. 02.Identify your 'essentials' and 'strongly recommended' now for your priority categories, based on known ESPR objectives and available preparatory studies.
  3. 03.Follow the publication of JTC 24 standards expected early 2026 — this is the technical piece that completes the JRC's semantic piece.
  4. 04.Engage the conversation with your supply chain on Tier 4 and 'stand-in DPPs': this is the most poorly anticipated subject and the most costly to address late.

For organisations that have not yet launched a DPP project: the JRC145830 methodology has just removed much of the uncertainty that justified a wait-and-see approach. Iron and steel leads the way in 2026, textiles follow in 2027, and the central EU registry arrives in July 2026. The moment to frame your strategy has come.

Back to blog

Take action

Discover how to implement your Digital Product Passport in compliance with European regulations.

Request a demo