The CEN/CENELEC DPP Standards: EN 18216, EN 18219–18223 and the Wider Framework

The DPP standards have moved beyond the draft stage

As of November 2026, it is no longer accurate to describe the first generation of European Digital Product Passport standards as forthcoming. CEN/CENELEC identifies eight standards developed by CEN-CLC/JTC 24, "Digital Product Passport — Framework and System." Six received harmonised references through Commission Implementing Decision (EU) 2026/1736, published on 15 July 2026. 1

That does not mean every product sold in Europe already needs a DPP. Regulation (EU) 2024/1781 — the ESPR — establishes the framework. Product-specific measures determine information requirements, granularity, access rights and application dates. The standards address how passport systems identify products, exchange information and remain interoperable. 3

The practical distinction is between the passport's technical infrastructure and the regulated product information carried through it. A technically interoperable passport can still contain inaccurate information; correct data behind a proprietary interface may still fail the technical requirements.

What M/604 requested

M/604 is the Commission's standardisation request supporting the DPP's horizontal technical infrastructure — Implementing Decision C(2024) 5423, amended by C(2025) 8024 — covering harmonised standards for ESPR Articles 10 and 11. 1

A standardisation request is not itself a standard or a product obligation. CEN/CENELEC describes the resulting framework as transverse and product-agnostic, designed to connect existing systems rather than force every industry onto one platform. Interoperability — not a vendor, blockchain or database — is the central implementation issue. 2

What each standard covers

Standard	Published scope	Implementation question
EN 18216:2026	Data exchange protocols	How do systems communicate passport information?
EN 18219:2026	Unique identifiers	How are products and entities identified consistently?
EN 18220:2026	Data carriers	How does a physical product provide access to its passport?
EN 18221:2026	Storage, archiving and persistence	How does information remain available over the required period?
EN 18222:2026	APIs for lifecycle management and searchability	How do applications manage and discover passports?
EN 18223:2026	System interoperability	How do independently built systems work together?
EN 18239	Access rights, security and business confidentiality	Who may access or change information, and how is it protected?
EN 18246	Authentication, reliability and integrity	How can an item's origin and integrity be assessed?

The six harmonised references published in July 2026 cover EN 18216 and EN 18219–18223.

EN 18216: data exchange protocols

The communication layer matters when a manufacturer, service provider, repairer and authority all use different software. Ask suppliers which protocol requirements they implement and to demonstrate exchange with an independent system — "we have an API" is not conformance evidence.

EN 18219: unique identifiers

Identification must survive changes of hosting, ownership and software. Separate product identity from the address where information currently lives, and distinguish model, batch and item identification as the legal measure requires.

EN 18220: data carriers

Test readability after printing, packaging, transport, installation and wear — and verify the carrier resolves to the correct passport, not a generic marketing page.

EN 18221: persistence and archiving

Persistence is organisational as well as technical: contracts, identifier governance, backups and migration all matter. Demonstrate restoration from backup and migration to a replacement provider.

EN 18222 and EN 18223: lifecycle services and interoperability

Test creation, retrieval, update, discovery and lifecycle transitions. Include semantic consistency: transferring a number is useless if the receiver misreads its unit, boundary or product reference.

EN 18239 and EN 18246: security and trust

Both are in the first eight-standard framework, but the July 2026 decision covered the other six. Check later Official Journal publications before assuming harmonised status. Access control, authentication and integrity are related but distinct — none proves an environmental claim was correct.

Harmonised references: what they establish

ESPR Article 41(2) gives a presumption of conformity for DPPs complying with cited harmonised standards — but only for the Article 10 and 11 requirements those standards cover.

Publication is not citation. A European Standard can exist without an Official Journal reference.
Citation is not unlimited approval. The legal effect concerns the requirements covered.
Conformity is not self-proving. You need evidence your implementation follows the clauses.

Treat a vendor "EU-compliant" badge with scrutiny: ask for standard, edition, clauses, scope, test evidence and exclusions.

ISO/IEC JTC 5 and international alignment

CEN/CENELEC identifies ISO/IEC JTC 5, "Digital Product Passport," as the international counterpart and anticipates collaboration. Future international deliverables remain expected. Support globally usable identifiers and open interfaces, while keeping an explicit mapping to the European requirements.

How to use the standards in a real project

Start with a legal requirements matrix

Identify product, regulation, delegated acts, dates and required content — then map technical requirements to standards. Separate product data, identity and carriers, access and update permissions, availability, registry interactions and evidence.

Build a conformance evidence pack

For each clause record the system component, owner, verification method and evidence location: interface specs, test logs, restoration exercises, access-control tests.

Procure portability explicitly

Require structured export, identifier continuity, documented interfaces, migration assistance and termination arrangements. Establish who controls domains, resolvers and keys.

Test failure, not just success

Include an unavailable host, a withdrawn credential, a damaged carrier, a wrong identifier and a replacement provider. The real question: can the right actor obtain trustworthy, correctly interpreted information throughout the lifecycle?

Sources

Last reviewed 2 November 2026. Guidance only — not legal advice. View as Markdown