EN 18216 and the DPP standards stack, explained

Regulation is written in obligations. Implementations are written in schemas, identifiers and transport formats. The gap between the two is filled by harmonised standards — and for the Digital Product Passport that stack is now taking shape under CEN/CENELEC.

If you are scoping passport work this quarter, the standards are the part worth reading first. They are what your suppliers, your data carriers and your compliance auditor will all end up pointing at.

Which standards actually exist

Six Digital Product Passport standards from CEN/CLC/JTC 24 — EN 18216, 18219, 18220, 18221, 18222 and 18223 (2026) — were published in mid-2026 and presented on 25 June 2026. They were cited in the Official Journal by Commission Implementing Decision (EU) 2026/1736 of 14 July 2026 (CELEX 32026D1736). Two further standards, prEN 18239 (access-rights management and information-system security) and prEN 18246 (data authentication and integrity), are not yet published.

Worth saying plainly, because published ranges circulating elsewhere are wrong: EN 18217 and EN 18218 do not exist.

This is an absence rather than a Commission statement: presumption of conformity attaches only to the legislation a standard is cited under, and no such citation exists yet under Regulation (EU) 2023/1542.

What the standards actually pin down

A passport is not one artefact. It is four decisions that have to agree with each other:

1. The unique identifier. What identifies this specific battery, forever, independently of who owns it.
2. The data carrier. How that identifier gets onto a physical product and back off it — in practice, a QR code resolved through GS1 Digital Link.
3. The data model. Which fields exist, what they mean, and which are mandatory for your product category.
4. The access regime. Who sees which subset: the public, parties with a legitimate interest, and authorities.

Every one of those is a place two vendors can diverge, and every divergence is a passport that scans but does not resolve.

Why interoperability is the whole point

The value of the DPP framework is that a recycler in one member state can scan a cell built in another, five years later, and get a machine-readable answer. That only works if the identifier scheme, the carrier encoding and the field semantics are shared.

This is also the practical argument for not hand-rolling your own schema while you wait for every standard to be finalised. Map your bill of materials onto the published data model now, and the remaining work is a migration rather than a rewrite.

What to do with this

• Inventory your identifiers. If you cannot uniquely name every battery you ship today, that is the first gap to close.
• Decide where the data lives. Passport fields are assembled from ERP, lab results and supplier declarations. The join is usually the hard part, not the schema.
• Treat supplier data as a lead time. Recycled-content and due-diligence evidence comes from other companies' systems. Those requests take quarters, not sprints.

If you want the field-by-field view, the Annex XIII breakdown walks through each data category and who can see it.