EN 18216 to 18223: The Six CEN Standards That Define a Compliant Digital Product Passport

For three years, every Digital Product Passport (DPP) discussion has bumped into the same question: what does a compliant DPP system actually look like? The ESPR regulation (EU 2024/1781) is the legal authority. CIRPASS-2 sketched the architecture. GS1 Digital Link gave us the URL syntax. But the actual normative technical standards — the ones a brand can point at and say "build to this" — were missing.

That gap has now closed. The CEN/CENELEC Joint Technical Committee 24 (JTC 24) has published six normative European Standards covering the technical architecture of a Digital Product Passport. Together they define how identifiers work, how data is carried, how the API behaves, how data is exchanged and archived, and how systems interoperate.

The six published standards are:

  • EN 18216 — Data exchange protocols
  • EN 18219 — Unique identifiers
  • EN 18220 — Data carriers
  • EN 18221 — Data storage and persistence
  • EN 18222 — APIs for product passport lifecycle and searchability
  • EN 18223 — System interoperability

Two more — EN 18239 (access rights and security) and EN 18246 (data authentication and integrity) — are still under preparation as prEN drafts and are referenced normatively by 18221, 18222, and 18223. They are expected next. Update, October 2026: both were approved by CEN on 17 August 2026 and are now published — see all eight DPP standards are published, only six are cited.

This article walks through what each of the six published standards actually requires, why brands should be aligning their DPP systems to them now, and how the standards interact with the ESPR delegated act timeline for textiles.

Why these standards matter for ESPR compliance

ESPR Article 9 requires Digital Product Passports for products placed on the EU market in the product groups covered by delegated acts. Articles 10 and 11 list the essential requirements: passports must be linked to a persistent unique identifier, machine-readable, accessible, secure, and interoperable.

Those articles do not, however, specify how to meet the requirements at the technical level. That is what these CEN standards do. The Annex ZA in each standard maps its clauses to the ESPR requirements it covers, and once the Commission cites a standard in the Official Journal, following it gives a presumption of conformity (ESPR Article 41) — meaning that a system aligned to EN 18216 is presumed to meet ESPR's data-exchange requirement, a system using EN 18219 identifiers is presumed to meet the uniqueness requirement, and so on. Update, October 2026: all six were cited on 15 July 2026 by Implementing Decision (EU) 2026/1736.

In practical terms: if you can't demonstrate alignment with these standards, your conformity assessment under ESPR becomes a custom argument case by case. If you can, it becomes a checkbox.

EN 18216 — Data exchange protocols

This is the transport-layer standard. It defines how a DPP resource is requested, transmitted, and rendered.

Section 4 — Transport: DPP data exchange must use HTTPS with TLS 1.2 minimum (TLS 1.3 strongly recommended) and HTTP/2 minimum, with HTTP/3 recommended. APIs should follow RESTful style. Older protocols (TLS 1.1, SSL) are prohibited.

Section 5 — Formats and content negotiation: JSON (per ISO/IEC 21778) must be supported as the syntactic interoperability baseline. XML, JSON-LD, and HTML may additionally be offered, and the format served is selected via HTTP content negotiation (per RFC 9110, the standard Accept header pattern).

That last requirement is the one most current DPP implementations fail. The same URL must return either rendered HTML (for a consumer scanning a QR code) or machine-readable JSON / JSON-LD (for a recycler's tool, marketplace integration, or verifier), depending on the Accept header sent by the client. One resource, multiple representations.

When HTML is returned, it must conform to EN 301549 (the EU accessibility standard). An HTML-only DPP page is not standards-compliant under EN 18216 even if everything else about it is correct.

EN 18219 — Unique identifiers

This is the identifier scheme standard, and the most prescriptive of the six.

Section 4.1 — global uniqueness: no reassignment, distinct from any other identifier, no coexistence with another ID for the same product instance.

Section 4.2 — persistence: the identifier must survive the operator's insolvency or liquidation. A note adds that the EU DPP Registry ensures a minimum level of preservation for identifiers; keeping the passport itself available is a separate ESPR duty, met through a back-up copy at a DPP service provider (ESPR Article 10(4)).

Section 4.3 — syntax: character set per ISO/IEC 646; URI form must follow RFC 3986; the identifier must be a URL or convertible to a URL.

Section 4.4 — granularity: each identifier must be unique at the smallest granularity it serves (model, batch, or item-level serial). Granularity must remain consistent once on market. If granularity changes — for example, a brand moving from batch-level to item-level DPPs — a new identifier must be issued and linked to the old one for traceability.

Section 4.6 — openness: the public DPP information must be reachable without registration, app download, or credentials. No vendor lock-in is permitted.

ID scheme 1 — Web-enabled structured path ID (the GS1 route): The dominant route in practice. It requires the identifier to conform to GS1 Digital Link URI Syntax v1.6.0:2022, apply GS1 Application Identifiers per ISO/IEC 15418, follow ISO/IEC 18975 structured-path resolution, and use a registered Issuing Agency Code under ISO/IEC 15459-2 (a real GS1 Global Company Prefix, not a placeholder).

A compliant GS1 Digital Link URL looks like: /01/{GTIN}/22/{CPV}/10/{batch}/21/{serial}. The path segments encode granularity automatically: /01/{GTIN} alone is model-level, adding /10/{batch} makes it batch-level, adding /21/{serial} makes it item-level.

Section 6 — Economic operator and facility identifiers: These must use one of ISO/IEC 6523 (LEI, GS1 GCP, PEPPOL), ISO/IEC 15418/15459, DID, or DOI schemes. Free-text manufacturer names in a DPP header are not compliant.

EN 18220 — Data carriers

This standard defines the physical or visual means by which the DPP identifier reaches a scanner or reader. In practice: QR codes, data matrix codes, RFID tags, NFC tags.

EN 18220 requires the carrier to encode the unique product identifier (per EN 18219) that gives access to the DPP, be readable by widely available smartphone cameras and standard industrial readers, and meet durability requirements appropriate to the product's lifecycle.

For most consumer-facing categories — textiles, footwear, furniture — a QR code encoding the GS1 Digital Link URL is the de facto carrier. EN 18220 confirms this is acceptable, but it sets durability and contrast requirements. Brands using paper hangtags need to ensure the carrier survives at least until the product is sold; brands using sewn-in labels need to ensure scannability over the product's expected lifetime.

EN 18221 — Data storage, archiving, and persistence

This is where most existing DPP implementations have the biggest gap.

Section 4.2 — archiving from first change: every change to a DPP must be archived from the moment of the change, and version history must be retained for the full DPP lifetime. The DPP is not a single mutable record; it is a versioned object with full history.

Sections 4.3 and 4.5 — backup DPP service provider: when a product is placed on the market, a back-up copy can be required to be made available through a service provider — the standard's wording is conditional, and whether it applies comes from the product's own rules. Where it does, the back-up holds the current version and all required historical versions, and general access to the passport at the back-up opens once the economic operator is no longer active on the market. That is what gives the identifier its required persistence (EN 18219 §4.2.2, which requires the identifier to survive insolvency, liquidation or cessation).

Duration is not a number in this standard. EN 18221 defines the digital product passport lifetime as the period during which the passport is required by regulation to be available, and every duration requirement points back at that — so the years come from the ESPR delegated act for the category, not from the standard. It does set an access-pattern requirement: the version as it stood at a given point in time must be retrievable by authenticated and authorised actors, so the archive is queryable rather than a write-only log.

A DPP system that stores only the latest state of each passport is not compliant. Brands need to design for versioned storage from day one — adding version history tables and version-aware read endpoints is much easier in a new system than retrofitting one that has been live for two years.

EN 18222 — APIs for product passport lifecycle and searchability

This is the API standard. It defines the minimum interface every DPP system must expose.

EN 18222 mandates three read methods that every compliant DPP system must expose as standardized endpoints:

  • ReadDPPById — fetch a DPP by its unique identifier (the full Digital Link URI or canonical ID).
  • ReadDPPByProductId — fetch the current DPP for a product identifier (typically the GTIN), returning the most recent passport.
  • ReadDPPIdsByProductIds — bulk lookup, given a list of product identifiers, return the corresponding DPP IDs. This is how marketplaces, customs authorities, and recyclers efficiently process catalogs.

The standard also defines lifecycle methods for creating, updating, archiving, and registering DPPs with the EU Registry. These must be authenticated and access-controlled (using EN 18239 once it is published).

Most DPP systems today expose only a generic CRUD interface over their own data model. EN 18222 requires that the three read methods exist as standardized endpoints — meaning a tool built against one EN 18222-compliant DPP system can query another with no code changes. That is the technical foundation of marketplace and recycler integration at EU scale.

EN 18223 — System interoperability

This is the schema standard. It defines the canonical structure of a DPP header — the metadata that wraps the product-specific content — so that different DPP systems can exchange and interpret each other's passports.

Per section 4.1.2.1, the DPP header must include:

  • granularity — model, batch, or item — explicitly declared
  • dppSchemaVersion — version of the schema in use
  • dppStatus — active, withdrawn, replaced, archived
  • lastUpdated — timestamp of the latest change
  • economicOperatorId — properly formatted per ISO/IEC 6523 (LEI or GS1 GCP), not free text
  • facilityId — same formatting requirement
  • dictionaryReference — per data element, a reference to the controlled vocabulary defining that element
  • contentSpecificationIds — references to the product-category content specifications (the ESPR delegated act schema, in textile DPPs)

EN 18223 is what makes interoperability real. Two DPP systems aligned to the same content specification and both producing EN 18223-conformant headers can exchange data with no custom integration work. A recycler can build one tool that processes textile DPPs from any brand.

What's still missing: EN 18239 and EN 18246

Two more standards in the family are still being finalized (update, October 2026: both are now published, but not yet cited in the Official Journal):

  • EN 18239 — Access rights and security. Defines how authentication, authorization, and role-based access work for DPP data. Different stakeholders (consumer, repair shop, recycler, customs authority, surveillance authority) need different levels of access to the same DPP.
  • EN 18246 — Data authentication and integrity. Defines how a DPP can be cryptographically verified as authentic and unmodified. Likely uses verifiable credentials or similar W3C work.

Both are referenced normatively by EN 18221, EN 18222, and EN 18223 — so the existing six standards have dependencies that aren't yet fully published. Brands building DPP infrastructure now should design with pluggable auth and integrity layers, ready to slot in EN 18239 and EN 18246 once finalized.

How this maps to the ESPR delegated act timeline

The ESPR framework regulation (EU 2024/1781) entered force on 18 July 2024. The Commission's Working Plan for ESPR (published April 2025) confirms the rolling delegated acts that define the product-group-specific requirements. For textiles, the delegated act is indicatively expected in 2027, with requirements applying at least 18 months after it enters into force — so not before mid-2028.

The CEN standards described here are horizontal — they define the system, not the textile-specific data fields. The textile data schema will come from the ESPR delegated act plus CIRPASS-2 sector work, and will plug into the EN 18223 header as the contentSpecificationIds reference.

This separation matters for planning. A brand can build to EN 18216 / 18219 / 18220 / 18221 / 18222 / 18223 today — the system layer is now fully specified for the published six. The textile fields layer will be added on top when the delegated act publishes, without redesigning the system.

What brands should do now

For brands that already have pilot DPPs running (using QR codes and Digital Link URLs), the practical near-term steps are:

  1. Audit your resolver against EN 18216 §5. Does the same URL return JSON or JSON-LD when called with Accept: application/json? If not, add content negotiation. This is usually the smallest fix on the list.
  2. Promote granularity, dppSchemaVersion, dppStatus, and lastUpdated into the DPP header. Per EN 18223 §4.1.2.1, these are mandatory.
  3. Replace any free-text manufacturer field with a properly formatted economicOperatorId. Per EN 18219 §6, this must be an LEI or GS1 GCP or equivalent. Free text fails conformity assessment.
  4. Plan archive design for EN 18221. If your DPP table only stores the latest state, add a versions table and version-aware read endpoints. This is much easier to add before you have hundreds of thousands of DPPs in production.
  5. Plan the three mandatory EN 18222 read methods. If your current API is a generic CRUD over a datasource model, front it with thin REST aliases that expose ReadDPPById, ReadDPPByProductId, and ReadDPPIdsByProductIds as standardized endpoints.

Where to obtain the standards

CEN does not sell standards directly. They are distributed through national standardization bodies. Common purchase routes for the EN 18216–18223 series:

  • SIS (sis.se) — the Swedish national body. Per-standard purchase or a SIS subscription. Useful if you want the full series in Swedish (SS EN) and English.
  • en-standard.eu — private shop, immediate PDF download.
  • DIN (Germany) / BSI (UK) — same EN standards, sometimes faster English versions.

Typical cost is €50-200 per standard. The full six-standard set runs €300-1,000 depending on the route. Status of the wider series can be tracked at standards.cencenelec.eu.

The bottom line

The publication of EN 18216, 18219, 18220, 18221, 18222, and 18223 closes the biggest technical ambiguity that has hung over DPP work for the last three years. Brands no longer have to guess what a compliant DPP system looks like — the specifications are now normative, purchasable, and — once cited in the Official Journal — give presumption of conformity under ESPR Article 41.

The window between now and ESPR textile enforcement (not before mid-2028) is the right time to audit existing pilots against the standards, close gaps in content negotiation, header attributes, archive design, and standardized read methods, and design with pluggable hooks for EN 18239 and EN 18246 once they finalize.

Brands that build to these standards now will have presumption-of-conformity at enforcement time. Brands that don't will have a custom argument to make in every conformity assessment.