The Digital Product Passport Registry Is Live: What Registration Actually Requires Before 2027

On 20 July 2026, the European Commission switched on the piece of DPP infrastructure that turns the Digital Product Passport from a per-product data file into an enforceable system: the Digital Product Passport Registry. Every DPP-obligated product now needs an entry there, and the Commission has set a hard expectation that registration is complete before 2027.

If your team has spent the last year building the passport itself - the data model, the carrier, the supplier data pipeline - the Registry is the part that's easy to underweight. It's not optional infrastructure. It's the record regulators, customs officials, and market surveillance authorities will actually query.

What the Registry is, in practical terms

The DPP Registry is a central EU database that indexes the unique identifier of every registered product passport and links it to the economic operator responsible for it - the manufacturer, importer, or authorised representative who placed the product on the market. Where the passport itself lives with the product (accessible via the data carrier on the packaging or the item), the Registry is the lookup layer that sits above it: a way for a customs official at the border, a market surveillance authority doing a spot check, or another authority anywhere in the EU to confirm that a given product's passport actually exists, is active, and is tied to a real, accountable operator.

That distinction matters because it's where most first-time registrants get tripped up. Registering a product doesn't mean uploading your compliance data to the Commission. It means creating a discoverable, authoritative pointer between the unique identifier already encoded in your data carrier and the operator who stands behind it.

Who has to register, and what "before 2027" means

The obligation follows the same product scope as the DPP requirement generally: any product category brought under a delegated act needs a Registry entry before it's placed on the EU market. Because the Registry itself only opened on 20 July 2026, the Commission's guidance treats registration completion "before 2027" as the near-term compliance marker for economic operators whose products already carry DPP obligations or are about to.

In practice, that puts pressure on the same early movers already living under ESPR timelines: battery producers under the Battery Regulation's DPP track, and any manufacturer whose product category has a 2026-effective delegated act. If your product doesn't yet have a DPP obligation, you have more runway - but the Registry's launch is also the moment to stop treating registration as a future problem and start building the internal process now, before the delegated act for your category lands and the clock starts for real.

What registration actually asks for

Registry entries are built from data your team should already have if the passport itself is built correctly:

• The DPP's unique product identifier, structured to the format your data carrier encodes
• The identity and role of the economic operator (manufacturer, importer, or authorised representative) responsible for the product
• A reference to where the live passport data resides - the actual data carrier and its access point
• Product category and, where applicable, the relevant delegated act reference

The technical shape of the data carrier itself - the QR code or NFC tag physically on the product - is now governed by Implementing Decision (EU) 2026/1736, published 15 July 2026, which lists the harmonised standards for DPPs, including EN 18220:2026 covering data carriers specifically. That standard is what the Registry expects your unique identifier and access point to conform to - get the data carrier spec wrong and the Registry entry won't resolve cleanly even if the paperwork is technically filed.

Where early movers are getting it wrong

A few patterns are already showing up in how compliance teams are approaching registration:

Registering too late in the product lifecycle. Registry entries need to exist before the product is placed on the market, not retrofitted after launch. Teams that treat the Registry as a post-launch administrative task are creating a compliance gap the moment the product ships.

Identifier mismatches between the carrier and the Registry record. If the unique identifier printed into the QR code doesn't exactly match what's filed in the Registry, a scan resolves to nothing - which looks identical to non-compliance during a spot check, regardless of intent.

No single owner of the registration process. DPP programmes tend to be split across product, sustainability, and compliance teams. Registration is a discrete, recurring operational task - new SKU, new registration - and without a named owner it falls through the cracks between departments that each assume someone else is handling it.

A practical checklist before year-end

1. Confirm which of your product categories currently carry, or will shortly carry, a DPP obligation under a delegated act.
2. Audit your data carrier implementation against EN 18220:2026 before you file anything - fixing the carrier after registration means re-registering.
3. Assign a single internal owner for Registry filings, with a defined process for new product launches going forward, not just a one-time backlog clearance.
4. Build identifier consistency checks into your product data pipeline so the carrier and the Registry record are generated from the same source of truth, not entered twice by hand.
5. Treat registration as a launch-gate requirement, alongside CE marking and technical documentation, not a follow-up task.

The Registry is the part of the DPP system that makes the whole framework enforceable rather than aspirational. Products with a passport nobody can look up aren't meaningfully compliant - they just look compliant until the first spot check.