CEN and CENELEC Publish First EU Standards for the Digital Product Passport

The Starting Gun for Harmonized DPP Technology

On May 27, 2026, CEN and CENELEC published the first harmonized European standards for the Digital Product Passport (DPP): the standard series EN 18216:2026 through EN 18223:2026. This is not a routine event. Until now, there were political frameworks in place — most notably the Ecodesign Regulation ESPR and the Battery Regulation (EU) 2023/1542 — but no binding technical specification for how a DPP should actually be structured, addressed, and retrieved. These new standards close that gap.

On June 25, 2026, CEN and CENELEC held a public webinar to explain the standards and answer questions from industry. The response was substantial — a clear sign of the pressure manufacturers, importers, and software vendors are operating under.

What Standards EN 18216–18223 Cover

Unique Identifiers and Data Carriers

The core of the standard series spans three areas: unique product identifiers, data carriers (i.e., QR codes, RFID, DataMatrix, and similar technologies), and APIs for machine-readable data access. The standards are deliberately product-agnostic. They apply not only to batteries but lay the technical foundation for all future DPP obligations under the ESPR — from textiles and electronics to construction materials.

Specifically, the standard series prescribes how a product must be uniquely identified throughout its entire lifecycle. It builds on established standards: GS1 Digital Link is designated as the preferred format for linking a physical product to its digital record. This means a QR code printed on a product does not need to be a static URL, but rather a structured, machine-readable address through which resolver services can deliver various data points — depending on who is requesting and in what context.

API Interfaces and Interoperability

A central goal of the standards is interoperability: authorities, recycling operators, consumers, and suppliers should all be able to retrieve the same DPP through standardized interfaces, regardless of which platform hosts the passport. To achieve this, the standards define REST-based API profiles. Manufacturers and DPP platform providers must ensure their systems implement these interfaces correctly.

For developers, this means in practice: the API must support specific endpoints and response formats. A simplified example of a compliant DPP retrieval might look like this:

GET /dpp/v1/passport/{digitalLinkId}
Accept: application/json
Authorization: Bearer <token>

The response must deliver structured metadata about the product, including references to documents, certificates, and — for batteries — dynamic state data.

The Battery Regulation as a Pioneer: Static and Dynamic Data

The Battery Regulation (EU) 2023/1542, which entered into force in August 2023, is the first concrete use case for the DPP. It implicitly distinguishes between two categories of data:

Static data is fixed at the time of placing the product on the market: chemistry, manufacturer, rated capacity, and the carbon footprint of production. These values do not change and can be recorded once.

Dynamic data, on the other hand, must remain updatable throughout the entire lifecycle. This includes in particular the State of Health (SoH) and the State of Charge (SoC) — both metrics shift with every charge and discharge cycle. The regulation explicitly requires that these data points be kept up to date. This presents manufacturers and operators with a system architecture challenge: the DPP cannot be a static PDF; it must be connected to live data sources.

The new CEN/CENELEC standards address exactly this requirement by defining API profiles that support both read and write access — with appropriate authorization.

New Tools: Test Environment and Open-Source Validation

Alongside the publication of the standards, a number of practical developments have taken shape.

BatteryPass-Ready Test Environment

On June 24, 2026, the BatteryPass-Ready consortium launched a public test environment for the Digital Battery Passport. Manufacturers and software vendors can use it to validate their implementations against real test data before statutory deadlines kick in. The environment is co-operated by Fraunhofer IPK and is available without any registration barrier.

Digital Passport Assessment Workbench (DP-AWB)

In July 2026, researchers published the Digital Passport Assessment Workbench (DP-AWB) as an open-source tool. The tool computes deterministic assessment results directly from SHACL model specifications, enabling formal validation of DPP data structures. This is relevant for anyone who needs to ensure that their datasets are not only correct in content but also structurally compliant with the standards.

SHACL (Shapes Constraint Language) is a W3C standard for validating RDF graphs. In the DPP context, this means: if you model your product data as Linked Data, you can use the DP-AWB to automatically verify that all required fields are present and correctly typed — without manual checklists.

The Open Question: The EU-Wide DPP Registry

Standards and tools do not solve one problem: how do you find a DPP when all you have in front of you is a physical product? The European Commission is working on a central registry through which all DPPs will be registered and made discoverable. But the devil is in the details.

Orgalim — the European industry association for technology companies — has set out clear requirements: the registry must support high-volume, automated registration processes. When you consider that billions of products are placed on the EU market every year, the scale of the challenge becomes clear. A registry that requires manual entries or fails under peak load is unworkable for industrial use cases.

Orgalim also calls for the registry to be protected against operational outages — high availability is not a nice-to-have, it is a prerequisite. If a customs officer or a recycling company cannot retrieve a DPP because the registry is offline, the entire compliance chain breaks down.

The Commission has not yet published a binding go-live timeline for the registry. This remains one of the biggest unresolved gaps in the DPP ecosystem.

What Companies Should Do Now

The publication of standards EN 18216–18223 marks a turning point: the technical requirements are now defined, even if the registry is still missing. Companies that fall under the Battery Regulation or are preparing for future ESPR delegated acts should prioritize three steps:

Obtain and read the standards. EN 18216–18223 are available through national standards bodies (DIN in Germany). Reading the API specifications is mandatory for anyone developing or procuring their own DPP systems.
Review your data architecture. Can your systems deliver dynamic data points (SoH, SoC, repair history) via an API? If not, now is the right time to make an architecture decision — not six months before the statutory deadline.
Use the test environments. The BatteryPass-Ready environment and the DP-AWB are freely available. Testing your implementation early helps you avoid costly rework under time pressure.

The standards are published. The clock is running.