We logged in to the EU DPP Registry. You still cannot register a passport in it.

By Łukasz Głuch · 19 August 2026 · DPPera

We logged in to the European Commission Digital Product Passport Registry on 17 August 2026 and walked as far through it as it currently goes. This is what is actually there. Most of what follows is not in any vendor blog post, because it comes from the system and from the official user guide rather than from second-hand reporting. Version seen: 1.0.11.

The registry accepts organisations. It does not accept passports.

This is the headline, and it is stated by the Commission itself in the DPP Registry User Guide for Economic Operators (v1.01, 28 July 2026):

Successful registration of DPPs for batteries is not currently available, as the semantic catalogue for this product group has not yet been defined. Currently, it is not possible to successfully register DPPs.

Batteries are the only product group offered. Item level is the only granularity offered. The semantic catalogue that would let the system validate a submission does not exist yet. So today the registry is an enrolment system with a registration feature switched off.

That is not a scandal. The registry went live on 20 July against a legal deadline, and building the index before the content is the right order. But it does change what you should be doing this quarter: there is nothing to gain by rushing to register, and quite a lot to gain by being ready to.

What enrolment actually demands

Enrolment is the process that turns your company into a verified economic operator. It has seven steps, and the interesting part is step four, which happens outside the registry entirely.

1. You submit your organisation details.
2. You give the name and email of your legal representative.
3. The system generates a PDF declaration sealed by the European Commission.
4. Your legal representative signs or seals that PDF offline, using a qualified electronic signature or seal from a qualified trust service provider.
5. You upload the countersigned file.
6. You submit it for verification.
7. You watch the outcome in the activity dashboard.

The practical consequence is easy to miss: the qualified credential is used to sign a document, not to log in. You authenticate to the registry with an ordinary EU Login account. The eIDAS-grade credential is applied to a file on your own machine. If you were expecting to integrate with a signature provider, you were preparing for the wrong thing. What you actually need is a file upload and a way to track application states.

The details that will get applications rejected

The guide lists the rejection reasons in full, and they cluster into three groups.

• Exactly two signatures are expected in the file: the Commission institutional seal and your countersignature. Not one, not three.
• The only permitted change to the downloaded PDF is adding your signature. Any other modification invalidates the Commission seal and the application is rejected.
• The certificate attributes must match the form. For a legal person the certificate must carry organizationName, countryName and organizationIdentifier matching what you typed. For a natural person it is givenName, surname, countryName and serialNumber. A trading name in the form and a registered name in the certificate is a rejection.
• The signature format must be PAdES Baseline B, T, LT or LTA. Other containers are not accepted under the PDF-based procedure.

Read that list again as a buyer. Every one of those failure modes lands on a person in your company who has never heard of PAdES profiles. If a DPP supplier tells you they will handle enrolment, ask them to describe those four checks. It is a fast way to find out whether they have ever seen the system.

The test environment will not let you rehearse

There is an acceptance environment at a separate address, and it is genuinely useful for seeing the screens. It is not useful for rehearsing the hard part, because chapter 8 of the guide says the quiet part out loud:

The verification process used in the Test environment is the same as in Production. To create an organisation in Test, you must successfully verify it there using valid organisation data and the required signatures/seals.

So you cannot practise enrolment with dummy data and a self-signed PDF. Without a real qualified seal you can walk to step three, download the declaration, read what your legal representative is being asked to attest to, and stop. That is still worth doing, because the declaration is a document your legal team will want to see before anyone signs anything.

Three components the regulation requires that are not there yet

Implementing Regulation (EU) 2026/1778 lists what the registry consists of. Three of those components are absent from the current build, and the gap matters commercially rather than technically.

• The API. Article 3(b) requires an API for registering passports and retrieving information, and Article 8(6) says registration happens through the user interface or through the API. The user guide documents only two methods: an online form and a file upload of XML or JSON, up to one hundred passports per file. No machine interface is documented. If your integration plan assumes server-to-server registration, you are planning against something that is legally required but not yet published.
• The list of verified service providers. Article 3(f) makes a list of verified DPP service providers a component of the registry, and the recitals call it a reference list. It is not visible anywhere in the current interface. Note what the regulation does not say: it never states that the list is public or searchable.
• Acting on behalf of a client. Article 19(4) allows a verified operator to authorise a third party to perform registration activities in its name, provided that third party is itself verified under Article 5, with the operator remaining fully responsible. There is no such path in the interface. Today, the operator registers its own passports.

If you are a manufacturer, the third point is the one to note. Whatever your supplier promises about handling registration for you, the current system expects you to hold the EU Login account and your legal representative to hold the qualified seal. That is a task for your organisation, not one you can fully outsource today.

The fifty-character rule

One number in the guide will shape your architecture more than anything else in this article. The unique product identifier you register is a URL, it must use https, and its maximum length is fifty characters. Validation also rejects excessive redirects and any downgrade to a less secure protocol.

Do the arithmetic on your own domain before you design anything. A GS1 Digital Link path carrying a product code, a variant, a batch and a serial number will not fit inside fifty characters on any realistic domain. A short opaque path will, with room to spare.

Update, 17 August 2026. We put this to the Commission helpdesk. The answer: the fifty-character limit reflects the current version of the registry, the Commission acknowledges it may not accommodate all identifier formats permitted by the JTC 24 standards including certain GS1 Digital Link implementations, and the allowed length will be increased in the next version. So treat fifty as today constraint rather than a permanent design rule. The two rules below survive the change regardless, because neither has anything to do with length.

Two rules follow, and they are cheap to adopt now and expensive to retrofit later:

• The address you register must answer directly. No redirect from a www host, no redirect from a secondary domain, no protocol hop. If your passport URLs currently travel through a redirect, that is a compliance problem waiting to surface at validation time.
• The data carrier must encode the address you registered. The registry treats the identifier as the link between the physical product and its passport. A QR code pointing at a different URL than the one in the registry is a label that an inspector cannot verify.

What the Commission helpdesk told us

We asked the DPP helpdesk five questions on 17 August 2026. The answers are worth more than the screens, because they are dates.

• The API has a target: the fourth quarter of 2026. API-based registration is planned for a future release, currently scheduled for Q4 2026, and will enable system-to-system integration and registration of large numbers of items. Technical specifications will come with the API documentation. Nobody can integrate before that.
• There is no process for becoming a DPP service provider yet. No list is in place, and no formal recognition procedure exists. The requirements and criteria will be set out in a delegated act expected around the second quarter of 2027, with registry functionality rolled out in parallel.
• And here is the detail with real consequences. The first passports are the battery ones, from February 2027, under the Batteries Regulation. The helpdesk points out that unlike the Ecodesign Regulation, the Batteries Regulation does not have DPP service providers as an actor at all. So for the first product group to go live, the role that the ecodesign framework creates simply does not exist in the governing law.
• The enrolment error we hit is a known server-side issue, confirmed by their engineering team, with nothing required from our side.
• On identifiers: national trade register, VAT, LEI and local definition are all accepted, but you must ensure the identifier you choose is one that can also be carried in your qualified signature or seal, so that the registry entry and the certificate match.

Put the first three together and the sequencing becomes clear. Machine integration arrives about a year before the service-provider framework does, and the first mandatory passports arrive in between. If you make batteries, you should plan to hold your own registry identity in February 2027, because there is no recognised intermediary role in your regulation to hide behind.

What to do with the next three months

Nothing here creates urgency about registering. It creates urgency about being ready, which is a different and cheaper kind of work.

• Collect your organisation data in the registry format now: registered legal name as it appears in the register, registered address, country of registration, and an identifier - the national trade register number is the preferred one, with LEI and VAT accepted as alternatives.
• Find out who your legal representative is for this purpose and whether they already hold a qualified signature or seal. If they do not, get a quotation. This is the long pole.
• Fix your URL scheme to fit in fifty characters and answer without redirects.
• Do not buy anything on the promise of registry integration. The API is required by law and not yet documented. Anyone selling it today is selling a plan.

FAQ