For CTOs, IT directors and enterprise architects. CEN and CENELEC announced the first six standards from CEN-CLC/JTC 24 in 2026. Together they define cross-sector system building blocks; product-specific laws still define which data a passport must contain.
Regulatory status and timeline
The official CEN/CENELEC briefing confirms that the first six standards have been published. The standards support implementation of the ESPR technical framework, but using a standard does not by itself prove compliance with a product-specific delegated act or sectoral regulation.
The six published standards
- EN 18216:2026 — Digital product passport — Data exchange protocols
- EN 18219:2026 — Digital product passport — Unique identifiers
- EN 18220:2026 — Digital product passport — Data carriers
- EN 18221:2026 — Digital product passport — Data storage, archiving, and data persistence
- EN 18222:2026 — Digital product passport — Application Programming Interfaces (APIs) for the product passport lifecycle management and searchability
- EN 18223:2026 — Digital product passport — System interoperability
Read them as a system: a persistent identifier links the physical product through a carrier; protocols and APIs exchange and manage the record; storage rules keep it available; interoperability allows participants to move across systems without vendor lock-in.
Products and operators affected
Platform teams, manufacturers, data-space operators, identifier issuers and solution providers should use the standards to shape procurement requirements and architecture decisions. Product and compliance teams must pair that work with the applicable legal dataset and access rights.
Required data and preparation data
Required or anchored in adopted legislation: The ESPR requires interoperable, open, machine-readable passport systems with persistent identifiers, access controls and reliable data. Exact conformance claims depend on the legal measure, the standard's status and any citation in the Official Journal.
Recommended preparation while detailed rules develop: Create an identifier policy, carrier-selection criteria, API lifecycle, data-retention model, access matrix, audit trail and exit plan. Test how records remain resolvable when a supplier, host or platform changes.
A four-step readiness checklist
- Map each architectural component to the relevant EN 182xx standard and legal requirement.
- Define identifier granularity and carrier durability for real product lifecycles.
- Prototype create, update, resolve, search, archive and redirect operations through APIs.
- Run interoperability and supplier-exit tests, documenting evidence and unresolved assumptions.
Where DigiPP fits
DigiPP can provide a governed layer between product source systems and consumer or authority-facing passport experiences. Architecture teams should verify required standards, interfaces and assurance levels during solution design and procurement.
Official sources
Regulatory disclaimer. This article is general information, not legal advice. Requirements, guidance and implementation measures may change. Confirm the current legal text, product scope, operator role and transition rules for your products.