The EU's Digital Product Passport registry is live — publish to it, not just your own site

Article 13 of the ESPR creates the registry itself: by 19 July 2026 the Commission had to set up a digital registry storing, at a minimum, the unique identifiers, plus the commodity code for products intended to be placed under the customs procedure 'release for free circulation'. Two neighbouring articles complete the picture — Article 14 requires a public web portal for searching and comparing passport data, and Article 15 makes customs controls depend on the registry.

The registry is deliberately thin. It is not a database of your bill of materials, your emissions figures, or your supplier attestations — those stay in the data carrier and the system behind it. Article 13 also states expressly that it stores the unique identifiers for batteries referred to in Article 77(3) of the Battery Regulation, and that delegated acts under Article 4 may specify further data to be stored.

The mechanics matter more than the concept. Under Article 13(4) the economic operator placing the product on the market or putting it into service uploads the identifiers; under Article 13(5) the registry then returns a unique registration identifier, and the regulation is blunt that this communication is not proof of compliance. Article 15 closes the loop: anyone placing a covered product under release for free circulation must provide that unique registration identifier to customs.

Most passport pilots we see are built as a web page: a QR code resolving to a product URL on the manufacturer's own domain, rendered from a CMS. That satisfies the visible half of the obligation and fails the invisible half. With a registry in place, the compliance event is not "the page is live" but "the identifier is registered, and the registered identifier resolves to the passport we intended".

That reframes the build in three ways. Registration becomes a step in your product-release process, with its own owner and failure mode. Identifiers become master data you cannot casually regenerate — a re-issued identifier orphans a registered passport. And your pipeline needs to push, not just serve: an API call into a Commission system, with retries, error handling, and evidence you can show an inspector months later.

• Treat the unique product identifier and unique operator identifier as master data with an owner, not as a URL slug.
• Add registry publication as a gate in the product-release checklist, alongside labelling sign-off.
• Store the unique registration identifier the registry returns under Article 13(5) — customs will ask for it under Article 15, and an inspector will ask when it was obtained.
• Plan for outages and rejections: a failed registration is a product you cannot lawfully place, not a background job to retry silently.

Manufacturers own the identifier scheme and the publication pipeline. The decision to make now is which identifier standard carries your products, because migrating identifiers after registration is expensive and visible to authorities.

Importers are the most exposed. If a non-EU manufacturer registers nothing, or registers an identifier that resolves to a passport in the wrong language or with missing fields, the importer placing the product on the market carries the finding. That means registry status has to be a condition in the purchase order and verified before shipment, not discovered at the border when a customs check resolves an identifier that does not exist.

Certifiers and notified bodies increasingly work from the registry outwards: resolve the identifier, read the passport, then ask for the evidence behind a declared value. A passport that is live on your own site but absent from the registry looks, from their side, like a product without a passport.

• Manufacturers: choose the identifier standard, own the registration step, keep the response log.
• Importers: make registry publication a pre-shipment condition and verify resolution yourself.
• Certifiers and authorities: expect checks to start from the registry identifier rather than from your website.

The battery passport under the Battery Regulation applies from 18 February 2027, and it is a per-battery passport with a defined data set and a public subset — the closest thing to a production run of the whole model. Whatever breaks there (identifier collisions, supplier data arriving after the product ships, resolution failures in the field) is what will break across every ESPR product group afterwards.

The practical consequence is that battery-facing teams should build the registry publication path now and treat it as the reference implementation for later product groups. For teams with no batteries in scope, the same architecture still applies: read our ESPR hub for the delegated-act sequence, and build the identifier and publication capability before your group's act sets a date you cannot move.