At a glance
- Harmonised references were published through Decision (EU) 2026/1736 of 14 July 2026.
- The six areas are data-exchange protocols, unique identifiers, data carriers, data storage and persistence, APIs, and system interoperability.
- Conformity with the harmonised parts can support a presumption of conformity with the ESPR requirements covered by those standards.
- The technical standards themselves are obtained through national standardisation bodies; the Decision publishes references, not the complete text.
Why standards are central to the DPP
A Digital Product Passport must remain usable outside the software that created it. A product may change owner, move across countries, be inspected by an authority, repaired, resold or recycled. Without shared rules for identity, access, exchange and persistence, each platform would become a closed island.
The ESPR therefore requires an open and interoperable system. Standards translate that principle into testable technical requirements and reduce dependency on proprietary formats. Publication of harmonised references also connects technical design to the requirements of Articles 10 and 11 of the ESPR that the standards cover.
The six standards referenced in 2026
| Reference | Area | Operational impact |
|---|---|---|
| EN 18216:2026 | Data exchange protocols | How systems communicate and exchange DPP information consistently. |
| EN 18219:2026 | Unique identifiers | Identity for products, operators and other elements connected to the passport. |
| EN 18220:2026 | Data carriers | The carrier that connects the physical product to its DPP. |
| EN 18221:2026 | Storage, archiving and persistence | Availability, retention and continuity of information over time. |
| EN 18222:2026 | APIs, lifecycle management and searchability | Interfaces for creating, updating, managing and finding passports. |
| EN 18223:2026 | System interoperability | Principles allowing different DPP services and components to work together. |
The Commission stated that eight standards were developed in the broader programme and that six were already available through national standardisation organisations when the Registry launched. Decision 2026/1736 contains the harmonised references to the six standards listed above.
What the standards do not define
These standards are not a universal list of mandatory fields for every product. They cannot, on their own, determine which fibre percentage a textile passport must show, which durability metric applies to furniture, or which values must be published for a particular battery.
Those details come from product legislation, ESPR delegated acts or other sector-specific regulations. A compliant design therefore needs two layers:
- infrastructure layer: identifiers, carriers, protocols, storage, APIs and interoperability;
- product layer: datasets, units, methods, authorised users, granularity, retention and application date.
Be careful with generic field checklists
A field list found online is not evidence of compliance. Each field should be connected to the applicable legal basis, method, data source and product version.
Translating the standards into business architecture
1. Govern identifiers
The business needs to know who assigns an identifier, what level it represents and how it maps to ERP, product master data, batches and variants. A printed code without identity governance is not enough.
2. Separate the carrier from the data address
The physical carrier should remain readable and resolve to a stable address. A controlled resolution layer can allow infrastructure changes without replacing the carrier where the applicable rules and technical design permit it.
3. Design APIs and versions
APIs are not only for publishing a page. They need to support creation, update, status, search, authentication, errors and audit trails. Every change should be linked to a version and accountable actor.
4. Ensure persistence and portability
Passport availability must be assessed against product life and legal requirements. Backups, export, provider continuity and migration are governance requirements, not optional IT features.
5. Prepare Registry integration
The DPP service must extract approved identifiers and metadata, submit them through the interface or API, retain the response and reconcile errors. Registration should be part of the approval workflow rather than a disconnected manual task.
Questions to ask a DPP provider
- Which standards and versions are currently supported?
- Can the customer export and retain control of identifiers?
- Does the carrier resolve through a stable, manageable address?
- Are documented APIs available for creation, updates, search and registration?
- How are history, evidence and logs retained?
- Can data and passports be exported in interoperable formats?
- What continuity arrangements apply if the provider changes?
- Can public, restricted, authority and recycler access be separated?
The NexusDPP approach
NexusDPP separates the architecture into identity, data collection, workflow, validation, access control, publication, lifecycle and connector modules. This makes it possible to update one technical component without losing the data structure or approval history.
A pilot starts with real identifiers and a real dataset. This tests the carrier, lookup, APIs, permissions and registration before the model is extended to larger catalogues.
Official sources
- Commission Implementing Decision (EU) 2026/1736References to harmonised standards for Digital Product Passports.
- European Commission — DPP Registry launchThe announcement also summarises the standards and implementation resources available.
- Regulation (EU) 2024/1781 — ESPRDPP system, interoperability and presumption-of-conformity framework.
This page summarises the standards’ scope and does not reproduce protected standards text. Implementation requires consultation of the official version obtained through the relevant standardisation body.