DPP technical standards

Digital Product Passport Standards Are Here: What the CEN/CENELEC EN 1821x Series Means for Your Implementation

Last updated · July 20, 2026

For years, the Digital Product Passport existed as a policy commitment with no agreed technical rulebook. Manufacturers, DPP platform vendors, and compliance teams were building to educated guesses - reasonable ones, but guesses nonetheless. That changed on 27 May 2026.

On 27 May 2026, CEN and CENELEC published the first-ever set of European Standards for the EU Digital Product Passport, developed by joint technical committee CEN-CLC/JTC 24 "Digital Product Passport: Framework and System." The package is eight harmonised European Standards - the EN 1821x series - and together they define the common technical machinery that every DPP must use, regardless of product category.

This post maps what each standard does, explains why EN 18220 on data carriers is the one most product and packaging teams need to read first, and sets out a practical checklist for what to do now.

What Changed on 27 May 2026

The standards were developed in response to Standardisation Request M/604 from the European Commission and support Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation (ESPR). They were written by CEN/CLC Joint Technical Committee 24, organised into four working groups covering strategy, unique identifiers and data carriers, security, and interoperability.

The key shift is this: before 27 May 2026, teams designing DPP systems were working from draft standards, policy documents, and pilot-project outputs. Now there is a published, stable target. As one analysis put it, "the system layer is now stable, so you can prepare against a fixed target rather than a moving one."

Two standards in the package - FprEN 18239 on access rights and security, and EN 18246 on data authentication - were still in final approval at publication and are expected to be published in September 2026. The other six were published in full on 27 May.

National standardisation bodies have six months from 27 May 2026 to implement the standards at national level. The standards are not yet available for purchase through all bodies, but the technical content is fixed. Design decisions made now should align to the published EN text.

The Eight Standards: A Plain-Language Map

The eight standards are EN 18216, EN 18219, EN 18220, EN 18221, EN 18222, EN 18223, EN 18239, and EN 18246 - together defining how any Digital Product Passport is identified, carried on the product, exchanged between systems, structured, stored, access-controlled, and authenticated, independently of product type.

Here is what each one governs:

CEN/CENELEC JTC 24 — The Eight DPP Standards

Standard	Title	What it governs	Primary audience
EN 18216	Data exchange protocols	Secure data exchange protocols and formats so DPP data moves between systems in a structured, machine-readable, interoperable way	DPP platform developers, IT architects
EN 18219	Unique identifiers	Rules for product, operator, and facility identifiers — global uniqueness, persistence, and five permitted ID schemes including GS1 Digital Link URIs, W3C DIDs, and IEC 61406	Product managers, supply chain teams
EN 18220	Data carriers	Which physical/digital carriers (QR, DataMatrix, RFID/NFC) are permitted; symbology, encoding, print quality, durability, placement, and graphical recognition indicators	Packaging, labelling, and product design teams
EN 18221	Data storage, archiving & persistence	How passport data is stored and kept accessible across the product's full useful life, whether self-hosted or via a service provider	IT, data governance, DPP platform buyers
EN 18222	APIs for lifecycle management & searchability	Open REST interfaces for passport lifecycle management and interaction with the EU Central DPP Registry	DPP platform developers, system integrators
EN 18223	System interoperability	Cross-system interoperability framework so passports work across sectors, platforms, and supply chain actors	Platform architects, sector consortia
EN 18239	Access rights, security & confidentiality	Role-based access management separating public data from controlled data; IT security and data protection requirements (expected September 2026)	Compliance, legal, data governance teams
EN 18246	Data authentication, reliability & integrity	Tamper-evidence and provenance via electronically signed data constructs — W3C Verifiable Credentials, eIDAS EAA, ISO 22376 Visible Digital Seal, or ISO/IEC 20248 Digital Signature (expected September 2026)	Compliance, IT security, DPP platform vendors

The standards are deliberately product-agnostic. The same identifier scheme, the same QR code format, the same API, and the same signature mechanism work whether the product is a battery, a garment, a detergent, or a steel beam. That is the design intent: write the plumbing once, and let every ESPR delegated act and sectoral regulation reuse it.

Deep Dive: EN 18220 and the Data Carrier

EN 18220 is the standard most product, packaging, and labelling teams will encounter first, because it governs the physical object that connects a product to its passport.

What EN 18220 specifies

EN 18220 covers the full lifecycle of a data carrier - from how it is produced to how it is read in the field. Specifically, it defines requirements for:

Symbology and format - standardised characteristics for 1D/2D barcodes (including QR Code and Data Matrix), RFID, and NFC carriers
Error-correction codes and encoding - data content, syntax, and character sets, with interoperability to GS1 Digital Link URIs and other permitted identifier schemes
Print and production quality - minimum quality thresholds to ensure reliable scanning across the product's life
Durability - the carrier must remain readable for the product's full useful life, not just at point of sale
Graphical recognition indicators - visual signage so a DPP data carrier is recognisable to operators and automated systems
Placement - guidance on where to put the carrier on the product, packaging, or accompanying documentation
Machine readability - performance requirements for barcode readers, NFC, HF RFID, and UHF RFID technologies
Quality checking - verification procedures after production
Link to the digital representation - how the physical carrier resolves to the passport in the EU Central DPP Registry

QR vs RFID: what the standard says

EN 18220 does not mandate a single carrier technology. It permits 2D symbols (QR Code, Data Matrix) and RFID (HF, NFC, and UHF/RAIN), with rules on placement, marking, and quality for each.

One requirement is clear: EN 18220 requires at least one data carrier that is free to use and readable with an ordinary smartphone - in practice, a QR code that resolves to the passport in a normal web browser. RFID can be added for operational efficiency (automated scanning at goods receipt, recycling facilities, or repair centres), but it cannot be the only access route.

QR codes and GS1 DataMatrix are explicitly addressed; RFID implementations - including those based on the RAIN standard - are also covered. The data carrier encodes the unique identifier that resolves against the EU Central DPP Registry; it does not store the passport data itself.

What makes a carrier non-compliant

The most common failure modes will be durability and encoding. A QR code printed on a label that fades after two years does not meet the standard if the product has a ten-year useful life. An RFID tag that encodes a proprietary URL format rather than a standards-compliant identifier will not resolve correctly. Placement matters too: a carrier hidden under a removable label or inside packaging that is discarded at point of sale fails the accessibility requirement.

If your product already carries a GS1 Digital Link QR code for retail scanning, you are closer to EN 18220 compliance than you might think. The main gaps to check are durability (does the carrier survive the product's full useful life?), encoding (does the URL resolve to a DPP-compliant endpoint?), and graphical recognition (is the carrier visually identifiable as a DPP carrier?).

Horizontal Standards vs. Product-Specific Delegated Acts: Why Both Matter

The EN 1821x standards are "horizontal" or "system" standards. They are product-agnostic infrastructure. They do not tell a textile manufacturer what fibre composition data to include, or a steel producer what carbon intensity figures to report. That is the job of the product-specific delegated acts.

The relationship works like this:

Delegated acts (e.g., for textiles, iron and steel, aluminium) set what data a passport must hold - the specific fields, thresholds, and disclosure requirements for that product category.
The JTC 24 standards set how the passport works technically - the identifier, the carrier, the API, the access control, the authentication.

Both are required for a compliant DPP. A passport that holds all the right textile data but uses a non-compliant carrier or a proprietary API is not a compliant DPP. Equally, a technically perfect passport with no data is worthless.

This two-layer architecture has a practical implication for timing: the horizontal standards are now fixed, but most delegated acts are still being developed. That means teams can - and should - build the technical infrastructure now, against a stable specification, without waiting for their sector's delegated act to finalise the data fields.

The Timeline: From 27 May 2026 to Mandatory

19 July 2026 is the full-application date of ESPR and the go-live date of the EU Central DPP Registry. That is the infrastructure switch-on: the registry is live, the standards are published, and the framework is operational. But no product-specific DPP is mandatory on that date - the obligations come through delegated acts, each on its own timeline.

The current picture:

18 February 2027 - The EU Battery Passport becomes mandatory under Regulation (EU) 2023/1542 for EV, industrial, and light-transport batteries exceeding 2 kWh. This is the first hard DPP deadline and the only one currently confirmed by statute.
Iron and steel - Delegated act targeted for 2026, compliance around 2028.
Textiles, tyres, aluminium - Delegated acts targeted for 2027, compliance around 2029.
Furniture, electronics - Delegated acts in the 2027-2028 window, compliance around 2029-2030.
Detergents - Mandatory from 23 September 2029 under a separate regulation.

Delegated acts typically provide 18 to 36 months between publication and the compliance deadline. That transition window sounds generous until you account for the time needed to collect supplier data, integrate with a DPP platform, configure the data carrier, and test registry resolution.

The Interoperability Dimension: OPC Foundation Liaison

One development that has received less attention than the standards publication itself: in early 2026, CEN and CENELEC signed a Liaison Agreement with the OPC Foundation to strengthen DPP interoperability with industrial data models.

The cooperation focuses on aligning data modelling technologies and fostering interoperable, system-agnostic, and open-source DPP solutions that scale from embedded devices to cloud and enterprise environments. In practical terms, this means OPC UA's semantic modelling capabilities - widely used in manufacturing automation - will be aligned with the JTC 24 API and data models, making it easier to pull shop-floor production data directly into a DPP without bespoke integration work.

The European Commission's standardisation request is explicit: the DPP must be system-agnostic and vendor-independent. The OPC Foundation liaison is one mechanism for making that real in industrial environments.

What to Do Now: A Practical Checklist

The standards are published. The registry goes live on 19 July 2026. Your delegated act may still be 12-24 months away. Here is how to use the window productively:

For manufacturers and economic operators:

Identify your delegated act timeline. Use the planner above to map your product category to its expected compliance date. Work backwards from that date to set internal milestones.
Audit your current data carriers. If you already use QR codes or RFID tags, check them against EN 18220: Are they durable enough? Do they encode a standards-compliant identifier? Are they placed accessibly? Do they carry a graphical recognition indicator?
Choose your identifier scheme. EN 18219 codifies five permitted product-identifier schemes. If you already use GS1 GTINs, a GS1 Digital Link URI is the natural path. If you operate in a sector with established IEC 61406 or W3C DID infrastructure, those are also permitted. The choice affects your carrier encoding and your registry interaction.
Decide on your data hosting model. EN 18221 governs data storage and persistence. You can self-host or use a DPP service provider - but the data must remain accessible for the product's full useful life, and the API must conform to EN 18222.
Map your supplier data gaps. The horizontal standards define the infrastructure; your delegated act will define the data fields. Most of those fields - material composition, substances of concern, recycled content, carbon footprint - come from your supply chain. Start structured data collection now, before the delegated act locks the specific requirements.
Check your DPP platform vendor's standards alignment. Ask specifically about EN 18216 (data exchange protocols) and EN 18223 (system interoperability). A vendor that cannot demonstrate alignment to the published EN text is a compliance risk.

For DPP platform vendors and system integrators:

Validate your API against EN 18222 and your interoperability layer against EN 18223.
Review your access control model against the FprEN 18239 draft (expected September 2026) and ensure your authentication approach is compatible with EN 18246's permitted signature mechanisms (W3C Verifiable Credentials, eIDAS EAA, ISO 22376, or ISO/IEC 20248).
Confirm your identifier resolution chain works end-to-end against the EU Central DPP Registry.

The Bottom Line

The DPP is no longer a policy concept waiting for a technical specification. The specification exists. Eight harmonised European Standards define how every passport is identified, carried, exchanged, stored, secured, and authenticated - across every product category, every sector, every supply chain.

The practical implication is straightforward: teams that design to the published EN 1821x standards now will not need to retrofit their systems when their delegated act lands. Teams that wait will find themselves building under time pressure, against a specification they could have read today.

The horizontal layer is fixed. The product-specific layer is coming. The window to prepare is open - but it is not unlimited.

For a deeper look at what data goes inside a DPP once the infrastructure is in place, see our guide to what a Digital Product Passport actually contains. For the registry infrastructure that the EN 18222 API connects to, see our explainer on the EU Central DPP Registry.