The EU Digital Product Passport Registry Is Live. Here's What Brands Need to Do Next

Last updated: September 24, 2026

For years, the Digital Product Passport was easy to treat as a future requirement: important, inevitable, but still represented mostly by regulatory text, architecture diagrams, and deadlines on a roadmap. That changed this summer. The European Commission's Digital Product Passport Registry is now live.

The launch does not mean every product suddenly needs a passport. Product-specific obligations still arrive according to the relevant EU legislation, starting with certain batteries on 18 February 2027. But the infrastructure that will receive and index those passports is no longer theoretical. Brands can enrol. Teams can test the workflow. Engineers can inspect the integration path. Compliance leaders can finally replace assumptions with an operating model.

That makes this an unusually useful moment. There is enough infrastructure to start testing, but still time to fix the difficult parts before enforcement: unclear ownership, inconsistent identifiers, scattered product data, brittle vendor integrations, and QR codes that lead to experiences designed only for auditors.

Here is what actually launched, what the Registry does, and what a sensible brand should do next.

What Changed in July 2026

Three events turned the DPP from a framework into working infrastructure.

On 14 July, the Commission adopted Implementing Decision (EU) 2026/1736, publishing references to the first six harmonised DPP standards. They cover data exchange protocols, unique identifiers, data carriers, data storage and persistence, APIs, and system interoperability.

On 16 July, the Commission adopted Implementing Regulation (EU) 2026/1778, which defines the practical arrangements for the Registry: verification, access management, registration, storage, technical architecture, logging, and proof of registration.

On 20 July, the Commission opened the production Registry and a separate testing environment.

This sequence matters because it answers questions that were previously left at the level of principle. We now know that registration can happen through a secure user interface or an API. We know the Registry issues a unique registration identifier. We know economic operators can generate proof of registration. And we know the system is built around verified organisations and role-based access rather than anonymous uploads.

The policy is becoming a workflow.

The Registry Is Not the Digital Product Passport

This is the distinction most likely to cause expensive architecture mistakes.

The Registry is an index, not a giant EU database containing every manual, carbon calculation, repair instruction, material declaration, and product photograph.

The Commission describes the model as decentralised. The full passport remains hosted by the economic operator or a DPP service provider. The Registry stores the information needed to identify, register, validate, and supervise that passport.

In practical terms, a consumer may scan a QR code and open a branded product experience containing instructions, repair information, warranty options, and relevant sustainability data. A customs authority can use the registered identifiers to verify that a required passport exists. A repairer may see information appropriate to their role. Those interactions depend on the same product identity, but they are not all served from one public EU webpage.

That is good architecture. It allows the EU to create a common compliance layer without forcing every product experience into a single government interface.

What the Registry Stores

The exact registration data varies with the legislation governing a product category. At a minimum, the Registry architecture is designed around:

• Unique product, operator, and—where required—facility identifiers
• Registration information and timestamps
• The product's commodity code where relevant to customs
• A reference to the DPP service provider where applicable
• A unique and persistent registration identifier generated by the Registry
• Evidence supporting proof of registration
• Logs needed for security, accountability, and supervision

The complete passport can contain far more: composition, carbon footprint, substances of concern, performance, durability, repair, disassembly, and end-of-life information. That richer data remains in the decentralised passport system.

The distinction is not merely technical. It affects procurement. A provider promising to "upload your whole passport to the EU database" is describing the system badly. A credible architecture should explain which information goes to the Registry, which information stays in the passport, who controls the hosting, and how the data remains available if the provider changes.

Who Is Responsible for Registration?

The legal responsibility follows the economic operator placing the product on the EU market or putting it into service under the applicable legislation.

For an EU manufacturer, that may be straightforward. For a product made outside the EU, responsibility may sit with an importer or another designated operator. Marketplaces and distributors also have obligations in parts of the DPP framework, particularly around ensuring passport access when products are sold at a distance.

The operational mistake is to treat this as an IT-owned task because an API is involved. Registration sits at the intersection of legal responsibility, product data, supply chain operations, and technical delivery. A sensible ownership model usually includes:

• Compliance or legal, accountable for scope and regulatory interpretation
• Product operations, accountable for product records and release processes
• Supply chain or sustainability, accountable for upstream evidence
• Engineering or data, accountable for identifiers, APIs, validation, and reliability
• Customer experience, accountable for what people see when they scan the product

If nobody can answer who is allowed to register a passport, who can correct it, and who owns it when a product or business changes hands, the organisation is not ready—regardless of how polished its QR code looks.

How Registration Works

The Commission now provides both a production Registry and a testing environment. The detailed screens and verification steps may evolve, but the operating sequence is clear.

1. Enrol and verify the organisation

Registry access begins with an EU Login and organisation enrolment. The verification model is designed to establish that the person and organisation acting in the Registry are who they claim to be.

Do this before a deadline is close. Identity and authority checks are exactly the kind of administrative dependency that becomes painful when thousands of products are waiting behind it.

2. Establish roles and responsibility

Decide who can register passports, manage organisation information, work with service providers, and maintain records. Document the approval path internally rather than allowing access to accumulate informally.

3. Register through the interface or API

The secure interface gives teams a way to understand the process and handle lower-volume workflows. The API is the realistic route for brands with large catalogues, frequent launches, or item-level passport requirements.

The right choice depends on volume and product law. Registering 40 long-lived industrial models is different from registering high-volume batteries at item level.

4. Receive the registration identifier

After successful submission, the Registry generates a unique registration identifier. The response is returned through the interface or API, depending on how the registration was submitted.

5. Retain proof and maintain the record

Economic operators can generate proof of registration for passports under their responsibility. Registration is not the end of the lifecycle: relevant organisation and passport data must remain current, and the rules support transferring registered passports when responsibility moves to another verified actor.

The Six Standards That Now Matter

The first harmonised standards are not a content checklist for a specific product category. They are the connective tissue that lets different passport systems work together.

Conformity with applicable harmonised standards can create a presumption of conformity with the ESPR requirements those standards cover. For buyers evaluating DPP software, "standards-ready" should therefore mean more than a slide in a sales deck. Ask which standards are implemented, which are still being mapped, and how conformance will be demonstrated.

What Brands Should Test Now

The Registry being available does not mean every company should immediately push production records into it. It does mean there is little justification for waiting to test.

Start with one representative product family and answer these questions:

1. Can we identify the responsible economic operator? Confirm the legal entity, not merely the consumer-facing brand.
2. Are our identifiers stable? Map product, operator, and facility identifiers across ERP, PIM, PLM, and supplier systems.
3. At what level will passports exist? Product-specific law will determine whether registration happens at model, batch, or item level. Model the highest plausible volume.
4. Can we produce the required commodity code? This matters where customs verification applies.
5. Where does the complete passport live? Document the URL, hosting owner, availability expectations, and backup plan.
6. Can our systems use the API reliably? Test validation errors, retries, rate handling, logging, and reconciliation—not only the happy path.
7. Can we change providers without breaking every QR code? The ESPR is explicitly designed around open, interoperable formats without vendor lock-in.
8. Does the scan experience serve humans too? Compliance data may satisfy the law, but a product page can also help a customer install, maintain, repair, register, or buy compatible parts.

The most valuable output from a pilot is not a screenshot of a successful registration. It is a list of the data and ownership failures uncovered along the way.

Four Mistakes to Avoid

Treating the Registry as a hosting platform

The Registry does not replace the passport experience or the infrastructure behind it. You still need reliable, persistent access to the complete product information.

Waiting for every delegated act before preparing

Final product-specific data requirements matter. But identifier governance, supplier data collection, system integration, and QR production take time regardless of the final field list.

Building a compliance-only dead end

A QR code may be mandatory, but a hostile consumer experience is not. The same scan can give regulators structured evidence and give customers useful guidance—without mixing access-controlled compliance records with public content.

Assuming “live” means “mandatory for everything”

The Registry is operational. DPP obligations remain phased. Certain EV, light means of transport, and industrial batteries are first on 18 February 2027. The Commission's current indicative timeline places adoption of the iron and steel delegated act in Q4 2026, construction and service-provider measures in 2027, and textile, aluminium and tyre acts later in 2027. Always check the legislation applying to the actual product.

A Practical 90-Day Plan

Days 1–30: establish ownership. Name the accountable economic operator, assign an internal DPP lead, identify affected product categories, and create access to the testing environment.

Days 31–60: run a real data pilot. Select products that reflect the complexity of the catalogue. Map identifiers, trace source systems, test passport hosting, and document missing supplier data.

Days 61–90: test the operating model. Register test passports, compare interface and API workflows, define exception handling, verify scan persistence, and establish how legal, product, and engineering teams approve a product before market release.

Do not measure readiness by how many fields exist in a spreadsheet. Measure it by whether the organisation can repeatedly create, validate, register, publish, update, and preserve a passport as part of normal product operations.

The Registry Changes the Conversation

The most important change is psychological. Digital Product Passports are no longer an abstract future database. The Registry exists, the first standards exist, and the first mandatory deadline is close enough to fit inside a product planning cycle.

That does not call for panic. It calls for a test.

Brands that start now can discover their data gaps while those gaps are still fixable. They can choose architecture before urgency removes their leverage. And they can design a product scan that does more than prove compliance: one that helps the customer use, maintain, repair, and stay connected to the product they already own.

That is the larger opportunity inside the regulation. The Registry makes the passport verifiable. The experience around it can make the passport valuable.

This article is for general informational purposes and does not constitute legal advice. Product-specific obligations depend on the applicable EU legislation and delegated acts. Consult the official European Commission materials and qualified legal counsel for your products.