At a glance
- Harmonised references were published through Decision (EU) 2026/1736 of 14 July 2026.
- The six cited areas are data-exchange protocols, unique identifiers, data carriers, data storage and persistence, APIs, and system interoperability.
- The other two published standards, EN 18239 and EN 18246, address access and security, and the trustworthiness of DPP data.
- 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.
Status checked on 30 October 2026
The two standards previously described as pending have now been published: EN 18239:2026 and EN 18246:2026. The Commission's harmonised-standards listing consulted for this update cites Decision (EU) 2026/1736, which contains six references. Publication by a standards body does not, by itself, establish citation in the Official Journal or a presumption of conformity. The Commission’s current timeline indicates November 2026 for the decision on the two remaining references; this is an indicative date, not confirmation that the act has been published.
Read what the remaining two DPP standards cover or check the Commission's current list of harmonised references.
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 DPP standards cited in Decision (EU) 2026/1736
| 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 are the remaining two DPP standards?
The phrase "remaining two DPP standards" refers to the two areas beyond the six references in Decision (EU) 2026/1736. UNI reports that CEN and CENELEC published these standards on 16 September 2026:
| Reference | Area | Question for a DPP project |
|---|---|---|
| EN 18239:2026 | Access, system security and confidential business information | How are access permissions defined, enforced and reviewed? |
| EN 18246:2026 | Authenticity, reliability and integrity of DPP data | How can information be checked and unauthorised changes detected? |
These project questions are a starting point for an implementation review, not a substitute for the standards' requirements. Obtain the applicable text from a national standardisation body and check the current legal references for your product.
Published standard or harmonised reference?
A standard can be available from a standards body before its reference is cited in the Official Journal. Under the ESPR, the presumption of conformity depends on that citation and applies only to the requirements covered. This guide therefore distinguishes the two September publications from the six references listed in Decision (EU) 2026/1736.
Source: UNI announcement of 24 September 2026.
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 software 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?
Three practical checks for a DPP software pilot
Bring a sample product, one supplier document and the roles involved. Use these checks to define the scope of NexusDpp Digital Product Passport software and the evidence required to accept the pilot.
1. Identifier and QR code
Scan the carrier and compare the identifier, model and approved version. Record the result and check what happens when a value is updated.
2. Access and history
Compare the public view with an authorised user’s view. Revoke one permission and review the record of who changed what and when.
3. Export and continuity
Request a documented export example and a data-recovery test. Define responsibilities, timing and migration conditions in the agreed scope.
For batteries, connect these checks to the Battery Passport data map and access-rights review. These proposed checks support project preparation; they are not a certification against the standards.
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
- European Commission: DPP implementation timelineIndicative November 2026 date for the decision on the remaining two references, checked on 30 October 2026.
- European Commission: harmonised DPP standardsCurrent listing consulted on 30 October 2026; check for subsequent citations and amendments.
- UNI: publication of EN 18239 and EN 18246Announcement dated 24 September 2026, describing publication on 16 September.
- 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.