The EU DPP Registry is live. What does your business still need to do?

The EU DPP Registry does not replace your Digital Product Passport, your product data or the system that keeps either of them working. It indexes registrations. The difficult work still sits before, around and after that registration.

What the EU Registry now does

The Commission's Registry gives the DPP system a common official index.

Under Commission Implementing Regulation (EU) 2026/1778, a verified economic operator can register a DPP through the secure user interface or the API. The Registry performs specified automated checks, creates a persistent registration identifier after successful verification and can produce proof of registration.

The same implementing regulation also establishes the semantic repository. That repository is intended to be the authoritative machine-readable source for DPP data models, semantic definitions and vocabularies across product groups.

Those are substantial pieces of infrastructure.

They still begin quite late in the business journey.

That distinction matters because a perfectly formed submission can still contain a bad product fact.

A composition value can be in the right field, using the right vocabulary, and still be wrong.

The Registry validates the parts the law tells it to validate. The economic operator remains responsible for the accuracy and completeness of the information submitted and for keeping Registry information up to date.

For the exact registration process, including the distinction between a Unique Product Identifier and the Registry-generated registration identifier, use how to register a DPP in the EU Registry. This page deliberately does not reproduce that workflow.

The API removes a handoff. It does not remove the work.

The existence of an API is useful, particularly for businesses with more than a handful of products.

It means a DPP system can eventually submit and manage registration data programmatically rather than making somebody re-key the same information into a government interface.

But an API call is the end of a preparation chain, not the beginning of one.

Before a useful registration request can be sent, somebody or some system still has to answer questions such as:

1. Which product rule applies? The Registry does not decide whether your product is in scope. The applicable Union law does. See DPP requirements by product category.

1. What level does the passport belong at? Model, batch and item are not interchangeable. See how many passports a range needs.

1. Which product identifier should be used? A GTIN, a Unique Product Identifier, a data carrier and a Registry registration identifier do different jobs. See barcodes and product identifiers.

1. What are the actual values? The semantic repository can define a field. It cannot tell you whether your supplier's declaration, your ERP value or your test report contains the value you should publish. See which system should own each product fact.

1. What supports the value? A DPP is more useful when a claim can be followed back to evidence rather than merely repeated. See how we know, and what a blank means.

1. Where will the DPP live? The Registry is not the complete DPP host. The product identifier needs to resolve to the DPP data you host yourself or through a provider. See where passport data lives.

1. What happens when the product changes? Product data, evidence and registration information all need lifecycle rules. See when to overwrite, version or create a new product.

That is why the API helps DPP software rather than making it redundant.

It gives software a defined official destination.

There are three different systems in the picture

For a business, the cleanest way to understand the architecture is to separate the record, the address and the registration.

1. The product record

This is the actual product information.

It can include identity, composition, origin, repair information, environmental information, conformity information and whatever else the applicable product rule requires.

The difficult part is not drawing a page around those fields. It is deciding which value belongs in each field, where it came from and what should happen when the sources disagree.

That is the product-data and evidence layer.

2. The persistent address and resolution layer

The physical product needs to connect to the digital information through a data carrier and persistent unique product identifier as the applicable rules specify.

That requires somewhere stable for the identifier to resolve.

A merchant's ecommerce URL is not necessarily a good long-term product identity. Product pages move. Ecommerce platforms change. Domains are migrated. Products are renamed.

A passport architecture therefore benefits from separating the persistent product address from whichever storefront happens to exist today.

If you want the protocol-level view, read what actually happens when somebody scans the code.

3. The EU registration layer

The Registry is the official EU-level index and registration record.

It connects the registered DPP to the verified economic operator and the identifiers and metadata the applicable law requires.

It does not collapse the other two layers into itself.

That is the architecture in one line:

product record → persistent identifier and resolver → decentralised DPP → EU registration

The arrows matter because each handoff has a different failure mode.

Where `dppcode.org` fits in the ActivateDigital architecture

In our architecture, dppcode.org has a deliberately narrow job.

It is the address and resolution layer behind passports published through ActivateDigital.

The intention is that a product code can point to a stable dppcode.org address, and that address can resolve to the relevant passport information. That gives the passport an identity layer that can remain stable even if the merchant later changes its Shopify theme, product URL, ecommerce platform or public website.

It is not:

• the EU DPP Registry
• an EU website
• a legal requirement
• a substitute for the economic operator
• proof that the passport is compliant
• proof that the resolver conforms to a particular standard.

The last point is intentional. A domain name is not a conformance claim. The existing annotated textile passport explains the distinction between a resolver, the record it serves and the evidence behind that record.

So the division of labour is simple:

dppcode.org does not compete with the Registry. They solve different problems.

Where ActivateDigital fits

Nothing in the DPP framework says a business has to buy ActivateDigital, or any other DPP platform.

A business can build and operate these layers itself.

The practical question is whether it wants to build the ingestion, product-data model, evidence handling, identifier logic, publication layer, resolver, updates and Registry integration around its existing commercial systems.

That is the gap ActivateDigital is designed to close.

The starting point is deliberately earlier than the Registry.

A business can begin with a product code, spreadsheet, PDF, image or ecommerce catalogue. ActivateDigital turns the information it can establish into a structured product record, keeps the unresolved parts visible and prepares that record for the places it needs to go.

For a Shopify business, the Shopify catalogue already contains some useful passport inputs but not the whole answer. The same principle applies to spreadsheets, supplier specifications and product files. The input does not need to look like a DPP before the work starts.

The end-state is also broader than a single passport page:

input → structure → evidence → gaps → product identity → publish → resolve → register → maintain

The Registry gives the final part of that chain an official interface.

It does not remove the earlier parts.

If you want to see what that looks like on a real input, Activate one product. The current product is built around a set of attributes anticipating ESPR for textiles. That is a readiness model, not a claim that the final textile delegated act has fixed those attributes as the legal list.

What the semantic repository changes

The semantic repository is one of the most useful parts of the new Registry architecture for software.

It means DPP systems do not have to invent their own meanings for every field forever.

Article 12 of Regulation (EU) 2026/1778 requires the Commission to maintain an authoritative machine-readable source for the data models, semantic definitions and vocabularies applicable across DPP product groups, with publicly documented APIs and free access.

That creates a better long-term pattern:

Commission definition → product-specific data model → local product data mapping → validation → DPP

For a business, that does not mean the Commission fills the field.

It means there is a more authoritative target for what the field is supposed to mean.

The mapping problem remains yours.

If your catalogue says Material: cotton, a supplier document says 98% cotton, 2% elastane and a product variant uses a different composition, a semantic definition cannot decide which commercial assertion is true. It can tell your system how the chosen fact must be expressed once that decision has been made.

That distinction is worked through in what the EU's published definitions ask of your product data.

Registration does not move responsibility to Brussels

This is the boundary a business should keep fixed.

Under Article 19 of Regulation (EU) 2026/1778, the verified economic operator is responsible for the accuracy and completeness of the information it submits and for keeping Registry information accurate, complete and up to date.

A third party may perform Registry actions on behalf of an operator where the legal conditions allow it.

That does not transfer the underlying responsibility.

Software can therefore:

• prepare the data
• check formats
• map fields
• find missing information
• preserve evidence
• manage identifiers
• publish the passport
• submit through an available Registry route
• store the returned registration information
• route failures back to the right owner.

It cannot make the economic operator disappear.

That is a useful product-design rule as well as a legal one: the system should make responsibility easier to exercise, not pretend it has been outsourced.

For the provider boundary, read who is allowed to hold your passport data and what they may do with it.

Does a small business still need a platform?

Not necessarily.

If you have one product, clean source data, a clear legal regime and the capability to host, resolve, back up, register and maintain the passport yourself, a software platform is not a legal prerequisite.

The case changes with scale.

Ten products can become hundreds of variants. One supplier spreadsheet becomes twelve. Values change at different levels. Certificates expire. A registration fails. A retailer asks for the same fact in a different structure. The product page moves but the code is already printed.

At that point, the value of a DPP system is not that it has a nicer form than the Commission.

It is that the same governed product record can be reused across the whole lifecycle.

For a smaller team, Digital Product Passport readiness for small businesses is the better starting point than buying software against an unconfirmed checklist.

What should a business do now?

The answer depends on the product.

The Registry being live is not the same thing as every product already needing a DPP.

Product-specific Union law decides whether a DPP applies, which information it contains, the level at which it exists and when the obligation begins.

So the useful sequence is:

If your product does not yet have a live DPP obligation

Prepare the parts that survive regulatory change.

• clean product identity
• know which system owns each important fact
• retain the evidence behind material claims
• separate model, variant, batch and item facts
• avoid printing an identifier architecture you cannot maintain
• test your ability to publish and resolve a product record
• watch the product-specific delegated act rather than a generic DPP countdown.

Use what to do now, and what to refuse to do now for that decision.

If your product is approaching a live DPP obligation

Add the operational pieces.

• verify the responsible organisation
• rehearse the Registry workflow
• map your data to the applicable semantic model
• define registration, failure and update states
• make the required service-provider backup available
• test what happens when the Registry rejects a record
• store the identifiers and registration evidence returned by the Registry.

Use the Registry test environment guide for the current test route and how to enrol your organisation before registration.

If you are a textile business

Do not confuse a live Registry with a live textile DPP obligation.

The final textile-specific DPP requirements still depend on the applicable delegated act. Prepare the reusable product-data and identity layers now, but do not label an anticipatory field set as the final legal textile passport.

The current position is maintained on Textile Digital Product Passport Requirements.

Direct questions

Does the EU DPP Registry host my complete Digital Product Passport?

No. The Commission describes the Registry as an indexing service. The DPP itself follows a decentralised model and the detailed product information remains with the relevant economic operator or its provider.

Does the Registry API mean I no longer need DPP software?

No. The API provides a route into the Registry. It does not collect your product data, establish which values are true, publish the complete passport or keep the rest of the lifecycle working.

Do I legally have to use DPP software?

No general rule requires you to buy a particular DPP platform. A business can operate the required layers itself if it meets the applicable requirements.

Can a software provider register a passport for me?

The implementing regulation allows for third-party Registry actions where the relevant Union law provides for them and the actor meets the required verification conditions. The economic operator remains responsible for the accuracy and completeness of the submitted information.

Does successful Registry registration prove the product complies?

No. Registry registration and substantive product compliance are different things. Proof of registration proves the registration event, not every underlying product claim.

Is dppcode.org the EU Registry?

No. It is part of the ActivateDigital passport architecture. The official EU Registry is operated by the European Commission.

Does dppcode.org replace the Registry?

No. dppcode.org is intended to provide the persistent address and resolution layer for ActivateDigital passports. The EU Registry provides the official registration/index layer. A product subject to a Registry obligation still needs the required Registry registration.

What would change this page

Recheck this page when any of the following changes:

• the Commission changes the Registry's architecture or what the Registry stores
• stable production API documentation materially changes the integration model
• the semantic repository exposes new product-group models or API behaviour
• the delegated act on DPP service providers changes hosting or backup assumptions
• a product-specific delegated act changes what a DPP must contain or where it must exist
• ActivateDigital changes the role of dppcode.org in its published passport architecture.

Operational UI details, current batch limits and current Registry product-group availability belong on the dedicated Registry workflow pages rather than here.

Try it on one product

The easiest way to understand the gap between raw product information and a reusable product record is to see the transformation.

Activate one product →

Start with a product code, spreadsheet, PDF, image or catalogue input. See what can be structured, what still needs evidence and what remains unresolved before you decide what to deploy.

Primary and official sources

• European Commission, The DPP Registry

  View official source

• Commission Implementing Regulation (EU) 2026/1778 of 16 July 2026 Relevant here: Articles 8, 9, 11, 12 and 19.

  View official source

• Regulation (EU) 2024/1781, Ecodesign for Sustainable Products Regulation Relevant here: Articles 10, 11 and 13.

  View official source

• European Commission, DPP Registry User Guide for Economic Operators, v1.02, last published 24 August 2026

  View official source

• European Commission, Digital Product Passport programme and roadmap Last verified: 3 September 2026. This page is practical guidance, not personalised legal advice.

  View official source

https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en

Last verified: 3 September 2026. This page is practical guidance, not personalised legal advice.