We walked through DPP Registry verification. The Commission cannot print Polish characters

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

On 21 August 2026 we took organisation verification in the EU Digital Product Passport Registry as far as it goes without a qualified electronic seal. We enrolled the organisation, requested the sealed declaration, downloaded it, uploaded it deliberately without a countersignature, and were rejected. We are not a verified economic operator and this piece does not claim otherwise. It is a record of what each screen does, plus one defect that hits legal names across half of the Union.

What we did, and what we did not do

This goes first, because a walkthrough that quietly implies more than it did is worth nothing.

• We did: enrol an organisation, complete the three verification steps in the interface, obtain the declaration issued and sealed by the Commission, submit a file for validation and receive a rejection report.
• We did not: countersign the declaration with a qualified certificate. We do not hold one yet. So we never saw a successful verification and we cannot tell you what the success report contains beyond what the manual states.
• Environment: Acceptance, version 1.0.11, the same version we described when we went through the registry on 17 August. Nothing here is a production registration.

The organisation form works now. Passport registration still does not

Earlier attempts ended with a blunt message: System Error. The system is unable to process your request at this time. We reported it to the DPP helpdesk and the ticket stayed open for days. On 21 August the whole path was walkable end to end.

What has not changed is the part that matters commercially. The DPP Registration tab is still greyed out. That matches what the Commission manual said and what we published a week ago: the semantic catalogue for batteries is not defined, so no passport can be registered by anyone. The registry accepts organisations. It still does not accept passports.

Four identifier types for a company, six for a person

We had read the list in the manual. Now we have seen the dropdown: NTR for a national trade register, LEI, VAT, and Local definition as an escape hatch for national schemes.

Two things are worth naming. There is no GLN and no EORI, so at the level of identifying a company the registry does not know GS1 at all, which is one more reason to treat the claim that GS1 is required as a sales line rather than a legal fact. And the Commission follows its own rule: in the certificate it uses to seal the declaration, it identifies itself by LEI.

Switch the record to a natural person and the list changes completely. There you get TIN for a tax identification number, PNO for a personal or civil identity number, eID, IDC for a national identity card, PAS for a passport, and Local definition again. Six entries instead of four, and not one of them overlaps with the company list.

Most of those codes will look familiar to anyone who has opened an eIDAS certificate profile, because they are the identifier codes that qualified certificates themselves carry under ETSI EN 319 412-1. That is not decoration and it answers the question of which one to pick. Choose the identifier your qualified certificate will actually contain, because that is the value the registry compares against your record, and a mismatch there is one of the listed reasons for rejection. Ask your trust service provider what goes into the certificate before you buy it, not after.

One trap for readers in Poland, since the two sit next to each other on the same list. The tax identification number of a sole trader is the NIP. The personal number is the PESEL. They are different numbers under different codes, TIN and PNO, and only one of them will match your certificate.

The declaration says far less than people fear

Everyone we speak to imagines something close to a notarial act. The operative content of the document is two sentences. You declare that the listed data is correct at the date of signing, and that the organisation will only undertake actions in the registry it is legally authorised to perform. That is all. There is no statement about product compliance and no liability for passport content.

The footnote is more useful than the body. It defines who counts as an economic operator by reference to article 2(46) of regulation (EU) 2024/1781: the manufacturer, the authorised representative, the importer, the distributor, the dealer and the fulfilment service provider. If you sell into the EU under any of those roles, this document is eventually yours to sign.

The file arrives already sealed, and that will fool people

Open the downloaded PDF in Adobe Acrobat and a blue bar appears at the top saying the document is signed and all signatures are valid. It is easy to read that as a job done. It is not your signature. It is the seal the Commission applies when generating the file, which is why the step is called Request Sealed PDF Declaration.

You can confirm this yourself without any paid tool. Pull the signature block out of the PDF and read the certificate:

openssl pkcs7 -inform DER -in signature.der -print_certs -noout

The subject line comes back as the European Commission, DG for Internal Market, Industry, Entrepreneurship and SMEs, with the address of the DPP helpdesk and an organisation identifier in LEI form. The issuer is a qualified certificate authority in Portugal. The signature format is CAdES detached, which is the PAdES family the registry demands. One signature, and none of it is yours.

So the trap is real: a user sees a valid signature, uploads the file unchanged and is told the certificate is untrusted or revoked. More on that below.

Ordering matters, because requesting the declaration locks your data

Before generating the file the system warns that proceeding will lock the application data for editing. It means the sequence most people would follow is backwards. You do not fill the form roughly and tidy it later. You get the organisation record exactly right first, matching the entry in your national business register field by field, and only then request the declaration.

Our own record went in with a sloppy address, two street lines and a locality in the region field, and it locked that way. There is a Restart path, so nothing is fatal, but on production this will cost people a working day.

The rejection report is a checklist, not a diagnosis

We uploaded the declaration without a countersignature on purpose, to see what the validator says. It rejected the file, correctly. Then it listed seven issues, of which exactly one was true.

The true one: the document did not contain the required number of signatures, because exactly two are expected, the institutional seal of the Commission and the countersignature of the organisation. We had one of two.

The other six described a seal that did not exist. The report stated that the certificate used for the signature of the organisation is not trusted, has been revoked or could not be verified. It stated that the seal does not meet the qualified electronic seal level. It stated that the signature does not conform to PAdES Baseline B, T, LT or LTA. There was no organisation certificate in the file at all, so none of those statements described anything.

This is not a small usability complaint. A company that uploads the wrong file will be told its certificate is revoked, and will go and phone its trust service provider about a problem it does not have. We fell into it ourselves for a few minutes. When a vendor tells you it will handle verification for you, this report is the thing they need to be able to read for you.

The Commission cannot print Polish characters

This is the finding with the longest reach, and it is not cosmetic.

The legal name we entered was rendered in the generated PDF with hash marks in place of letters. Where the name contains the letter l with stroke, the document prints a hash. The town of Elk prints as a hash. In the same document, the Polish letter o with acute renders correctly.

That pattern points at one cause. The font used by the PDF generator covers Latin-1 but not Latin Extended-A. The o with acute sits in Latin-1 and survives. The characters that do not survive are the ones in Latin Extended-A, which in Polish means a, c, e, l, n, s, z with their diacritics, and beyond Polish the letters used in Czech, Slovak, Hungarian, Romanian, Croatian, Lithuanian and Latvian legal names.

The web interface stores and displays the name correctly, so the defect is confined to the generation of the PDF. Which is precisely the worst place for it, because that PDF is the document a legal representative signs with a qualified certificate, under a sentence declaring that the information in it is correct. As it stands, an operator from a large part of the Union is asked to attest to a legal name that is not its legal name and does not match its own certificate.

We reported this to the DPP helpdesk on 21 August 2026 with the file and the analysis, and asked two questions: whether a fix is planned before production opens to economic operators, and whether the difference between the name in the document and the name in the signing certificate affects the check on matching organisation details. We will publish the answer when it arrives.

What we could not check, and will not pretend we did

• Whether verification actually passes. Without a qualified certificate we never submitted a valid file. Everything about the success path still comes from the manual, not from us.
• Whether the natural person route is lighter. The declaration we received is titled for legal persons, and the error text says legal persons must use a qualified seal. The manual describes a separate certificate profile for natural persons based on given name, surname and serial number, which suggests a personal qualified signature is enough there. We have not walked that path and we are not going to state it as fact.
• Whether the organisation type can be changed once a declaration has been requested. We tried to switch the record from legal person to natural person. Saving fails with the same generic system error, and the browser console shows the call to the verification restart endpoint never completing. So the lock placed on your data is harder to undo than the Restart button suggests.

The last point deserves a note, because it also explains something we could not explain at first. The Activity Dashboard reports no requests found, although our verification was rejected by the Commission at a recorded timestamp on the same day. The console gives the reason. The interface is served from one host and asks for the task list on another, and the response carries no cross origin header, so the browser refuses it. The panel is not empty. It is blocked. A browser reports this as a cross origin failure whatever the server actually returned, so the underlying cause may be different, but either way it is not something a user can do anything about.

What to take away if you will have to do this

• Fix the organisation data before you request anything. Name and address exactly as in your business register, because requesting the declaration locks the record and because the certificate attributes are compared against it.
• Countersign as an incremental update, never as a re-export. Adding a signature is the only permitted change to the downloaded file. Any tool that rewrites the PDF, including print to PDF and compression, destroys the seal of the Commission and the file comes back rejected.
• Read the rejection report as a menu, not a verdict. Find the one line that describes something that actually exists in your file before you act on any of the others.
• If your legal name carries diacritics, check the PDF before signing. Until the font is fixed, look at what the document says your company is called, and keep a copy of it. You are signing that page.

FAQ