What are the EN 182xx standards?

The EN 182xx family is the set of European harmonised standards developed by CEN-CENELEC Joint Technical Committee 24 (JTC 24) that define the technical operation of the EU Digital Product Passport: data exchange protocols, unique identifiers, data carriers, storage and persistence, APIs and searchability, interoperability, access rights/security, and authentication/integrity. Six were cited in the Official Journal via Implementing Decision (EU) 2026/1736.

Are the EN 182xx standards mandatory?

They are voluntary in the sense that no law forces you to apply a harmonised standard — but they are effectively the default technical route. Compliance with a cited harmonised standard creates a presumption of conformity with the corresponding legal requirements, meaning you are assumed compliant on the covered points. Building a DPP system a different way is permitted, but you then bear the burden of proving equivalence yourself.

What is the difference between EN 18219 and EN 18220?

EN 18219 covers unique identifiers — the identifiers themselves (UPI for products, UOI for operators, UFI for facilities), their structure, assignment and resolution. EN 18220 covers data carriers — the physical means of carrying the identifier on the product: QR codes, Data Matrix, NFC, RFID, their selection criteria, robustness and application. Identifiers are the "what"; carriers are the "where it physically sits."

Do the EN 182xx standards apply to the battery passport too?

The battery passport under the Battery Regulation was specified separately but is designed to interoperate with the general DPP system the EN 182xx standards define. The Commission has stated the battery passport will integrate into the broader framework — and the architectural principles (identifier, carrier, decentralised data, registry, tiered access) are shared. Implementation detail for batteries follows the battery-specific provisions plus the common technical layer.

Where can I get the EN 182xx standards?

Through the national standards bodies that publish them — BSI, DIN, AFNOR, SIS and the other CEN-CENELEC members — or via the CEN-CENELEC webstore. They are copyrighted paid documents like other EN standards. The Commission Implementing Decision (EU) 2026/1736 lists the cited references; the standards themselves must be purchased from a national standards body.

CEN-CENELEC JTC 24Cited in the OJ

The EN 182xx Standards Explained: The EU DPP Technical Rulebook

The ESPR says a passport must exist; the EN 182xx standards say how it works. Eight standards, what each one actually specifies, and why their citation in the Official Journal matters enormously for your build.

In 30 seconds

•Who: written by CEN-CENELEC JTC 24 for the DPP system
•What: identifiers, carriers, exchange, storage, APIs, interoperability, security
•Status: 6 cited in the OJ (2026/1736) → presumption of conformity; 2 in finalisation
•Why it matters: building to them is the lowest-risk technical route to compliance

Why these standards matter more than the regulation text

The ESPR tells you that covered products need a DPP and roughly what it is. It does not tell you how to structure identifiers, which carrier to put on the product, how data moves between your systems and the value chain, or who can see what. That is the engineering problem — and it is exactly what the EN 182xx family solves.

CEN-CENELEC Joint Technical Committee 24 wrote these standards specifically for the DPP, under a Commission mandate. They turn the ESPR's legal skeleton into an implementable technical system — the difference between reading a law and building a compliant product.

The standards family at a glance

The EN 182xx standards family — data exchange, unique identifiers, data carriers, storage and persistence, APIs, interoperability, access/security and integrity. — The EN 182xx family — six cited standards plus two in finalisation, each covering a distinct layer of the DPP stack.

Standard	Title	OJ status
EN 18216:2026	Data exchange protocols	Cited
EN 18219:2026	Unique identifiers	Cited
EN 18220:2026	Data carriers	Cited
EN 18221:2026	Data storage, archiving and persistence	Cited
EN 18222:2026	APIs for lifecycle management and searchability	Cited
EN 18223:2026	System interoperability	Cited
prEN 18239	Access rights, security and confidentiality	In finalisation
prEN 18246	Authentication, reliability and integrity	In finalisation

Mapping each standard to the ESPR articles it implements

The standards are not abstract — each one operationalises a specific set of legal requirements. Reading them against the ESPR articles shows exactly what each is for:

Standard	ESPR provision it serves	In plain terms
EN 18216	Art. 9–10 (data exchange)	How passport data is formatted and moved between systems
EN 18219	Art. 11 (unique identifiers)	How products, operators and facilities are identified
EN 18220	Art. 11 (data carriers)	QR, Data Matrix, NFC — the physical tag rules
EN 18221	Art. 12 (storage/persistence)	How passports are stored and kept available for the retention period
EN 18222	Art. 9 (lifecycle/search)	The APIs to create, read, update and find passports
EN 18223	Art. 9 (interoperability)	How systems across vendors interoperate on the same passport data
prEN 18239	Art. 9 (access rights)	Who can see which slice of the record — the access tiers
prEN 18246	Art. 10 (integrity/authenticity)	Proving a passport is genuine and untampered

What each standard actually specifies

EN 18216 — Data exchange protocols

How DPP data moves between systems: the transport and protocol layer so that a passport created by one system can be consumed by another — the plumbing that makes cross-company exchange possible at all.

EN 18219 — Unique identifiers

The identifier system: the unique product identifier (UPI) at model, batch or unit level, the unique operator identifier (UOI) and the unique facility identifier (UFI) — their structure, assignment, and how they resolve to data. In practice built on GS1 keys.

EN 18220 — Data carriers

The physical binding: QR, Data Matrix, NFC and RFID carriers — selection criteria, robustness, application and quality requirements so the identifier survives the product's actual environment and lifetime.

EN 18221 — Storage, archiving and persistence

The obligation to keep passport data available and intact for its required life — including who may host it (economic operators and DPP service providers), backup, migration and long-term preservation requirements.

EN 18222 — APIs for lifecycle management and searchability

The operations layer: APIs to create, update, transfer and revoke passports across the lifecycle, and the search/discovery interface that lets authorised actors find and retrieve them.

EN 18223 — System interoperability

Cross-system compatibility: how DPP systems from different providers, in different Member States and value chains, interoperate — the standard that prevents passport lock-in to a single vendor's stack.

prEN 18239 — Access rights, security, confidentiality

The tiered-access model: who may read or write which data elements — the standard that keeps commercially sensitive passport data protected while public data stays open.

prEN 18246 — Authentication, reliability, integrity

Trust: how passport data is authenticated and protected against tampering — the integrity layer that makes a passport something authorities can rely on rather than merely read.

Presumption of conformity — the mechanism that makes these matter

Presumption of conformity

Under the EU's New Legislative Framework, when a harmonised standard is cited in the Official Journal, a product or system built to that standard is presumed to conform with the corresponding legal requirements.

This is why the citation of EN 18216–18223 in Implementing Decision (EU) 2026/1736 is a bigger deal than it looks. Until standards are cited, "compliance" is your own interpretation of the law. Once cited, building to the standard is the default safe harbour: you are presumed to meet the covered requirements unless proven otherwise.

The alternatives are all worse: interpret the regulation yourself and carry the equivalence argument; wait for market practice to settle; or hire counsel to certify a bespoke approach. For most organisations, tracking the cited standards is simply the lowest-risk engineering posture available.

How an EN standard is born — and why citation matters

The EN 182xx standards followed the European standardisation pipeline. The European Commission issued a standardisation request to CEN-CENELEC asking for standards to support the ESPR's DPP provisions. JTC 24 — the joint technical committee created for product passports — then drafted each standard through national-member consensus.

The lifecycle of each document moved through distinct stages:

Working draft → prEN — a "proposed European Standard" open for public enquiry. prEN 18239 and 18246 are currently at this stage — published for comment, not yet final.
Formal vote → EN — national standardisation bodies vote; on approval the prEN becomes an EN and is published identically by every member body (BS EN, DIN EN, NF EN…).
OJ citation — the decisive step. When the Commission cites the standard in the Official Journal (as Implementing Decision (EU) 2026/1736 did for the six EN 182xx), the standard becomes a harmonised standard — and conformity with it confers the legal presumption of conformity.

This is why the citation event matters more than the publication event. A standard can exist for months before it is cited — only citation activates its legal effect under the ESPR.

How they relate to GS1, eudpp and ISO

The EN 182xx family does not reinvent everything — it orchestrates existing building blocks. Identifiers and carriers build on GS1: GTIN, GLN, GS1 Digital Link, QR/Data Matrix symbologies. The data model draws on the CIRPASS-2 eudpp reference ontology, exchanged as JSON-LD and validated with JSON Schema and SHACL. And at the international layer, ISO/TC 154's ISO 25534 is in development to align DPP concepts globally — so the EU system can interwork with future regimes elsewhere.

GS1 Digital Link for DPP

The identifier layer most EN 18219/18220 implementations will actually use.

The complete DPP guide

Back to the pillar: how all the pieces fit together.

How to read a harmonised standard efficiently

A practical sequence for engineers: (1) read the scope and normative references first — they define exactly what is covered; (2) map the normative requirements ("shall" clauses) to your system components; (3) treat informative annexes as guidance, not obligation; (4) track which standard covers which legal requirement — the presumption attaches to specific mappings, not blanket compliance.

For the DPP specifically: start with EN 18219 (identifiers) and EN 18220 (carriers) — they anchor everything else — then move to the data-plane standards (18216/18222) and finally the trust and access layer (18239/18246 when finalised).

Frequently asked questions

Implement to the standard, not around it

The CDPI Implementer certification is built around these standards — identifiers, carriers, data model, APIs, access control — with interactive labs on identifier resolution and the data model.

Explore CDPI