JRC145830 Methodology on the Digital Product Passport. A complete decode for brands.
On 19 March 2026, the Joint Research Centre published JRC145830 — 121 pages that lay out the common grammar for European Digital Product Passports for the decade ahead. Our reading, at operational level.
On 19 March 2026, the Joint Research Centre — the European Commission's scientific service — published a document awaited for months: 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 the Ecodesign for Sustainable Products Regulation (ESPR), integrated into the revised MEErP (Methodology for Ecodesign of Energy-related Products). Its function: to structure the drafting of the 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. So we read this report with a very operational eye: what changes concretely for product, supply chain, compliance and marketing teams? Here is our decode.
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.
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.
Use cases and data requirements (B.1 to B.4)
Specify the use cases(in the technical sense of the term, not as user stories), validate them through consultation, catalogue the necessary data, then prioritise and classify them. This is where the famous "essential / strongly recommended / voluntary" classification is built.
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.
Validation
Internal verification and targeted stakeholder consultation on the proposed specification, distinct from the consultations conducted in B.2.
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 tiers — essential, 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 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).
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.
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.
- Tier1
Public / Consumer
Consumers, potential buyers, civil society. Accesses top-level scores (durability, repairability), primary material composition, usage instructions and compliance status.
- Tier2
Professional operator
Independent repairers, refurbishers, remanufacturers. Accesses disassembly instructions, schematics, spare parts list, diagnostic codes.
- Tier3
End-of-life operator
Recyclers, sorters, recovery facilities. Accesses detailed material composition, location and identity (CAS number) of substances of concern.
- Tier4
Production / Supply network upstream
Processors, manufacturers, assemblers. Accesses the data needed to prepare their own DPP in the upstream direction towards the final product.
- Tier5
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).
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.
Layer 1 · Immutable
Core DPP
Initial manufacturer data, declared when the product is placed on the market — compliance, design specs, performance metrics. Extremely restricted editing rights (a safety recall, for example).
Layer 2 · Append-only
Life-cycle Log
Ledger linked to the Core DPP. All downstream events — repairs, software updates, refurbishment, ownership transfers, end of life — are recorded as timestamped, cryptographically signed entries.
Four principles structure this framework:
- 01
Data segregation: between Core DPP and Life-cycle Log.
- 02
Authenticated, role-based write permissions: the actor must be authenticated in their role to write.
- 03
Verifiability and attributability: each entry carries a traceable digital signature.
- 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.
This is where the JRC explicitly validates an architecture pattern that is not natural for traditional databases. 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.
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 the 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.
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:
| Category | Expected delegated act |
|---|---|
| Iron and steel | 2026 — ESPR pilot |
| Textile & leather | 2027 |
| Furniture | 2027–2028 |
| Consumer electronics | 2027–2028 |
| Tyres · steel · aluminium · chemistry | 2028 |
| Construction · toys · cosmetics · detergents | 2029–2030 |
To watch in parallel:
- •The 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.
Five concrete implications for brands
- 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).
- 02
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.
- 03
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.
- 04
DPP service provider status becomes a structural choice.
Article 2 of the ESPR explicitly defines the notion of a '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.
- 05
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.
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.
What to do in the coming weeks
For teams steering a DPP project, four short-term actions:
- Read JRC145830 in full, particularly Annexes 7, 8 and 9 — often neglected in public summaries even though they carry the most structuring elements.
- Identify your "essentials" and "strongly recommended" now for your priority categories, based on known ESPR objectives and available preparatory studies.
- Follow the publication of the JTC 24 standards expected early 2026 — this is the technical piece that completes the JRC's semantic piece.
- Engage the conversation with your supply chainon 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.
Discuss the impact of the JRC145830 methodology for your product category.
Arianee is the Digital Product Passport infrastructure chosen by actors in durable goods, electrical and electronic equipment, batteries, and fashion and luxury around the world. Our open-source, interoperable and compliant-by-design protocol supports brands from regulatory compliance to augmented product activation.
- JRC145830 — Methodology for defining data requirements for the Digital Product Passport under the ESPR framework · full report, 121 pages · published 19 March 2026.
- ESPR Working Plan · April 2025 · indicative timeline for priority categories.
- CEN/CENELEC JTC 24 · Standardisation Request M/604 (Commission Implementing Decision C(2024)5423).