What registry submission will actually look like

For most of the past year, every honest answer about the EU's Digital Product Passport registry has ended the same way: details pending. The registry is established by Article 13 of the ESPR (Regulation (EU) 2024/1781), battery passports must be registered in it, and beyond that, operators have been asked to prepare for a system nobody had seen.

That changed in late May. The European Commission published a draft implementing regulation specifying the registry — the document that turns "there will be a registry" into an actual description of how submission works. It is a draft: the public consultation closed on 27 May 2026, and it has not been adopted or published in the Official Journal. But it is the first official account of the mechanics, and for anyone responsible for battery passports before 18 February 2027, it is worth understanding in plain terms.

What the draft specifies

Three things stand out for operators.

Submission is machine-to-machine. The draft describes a RESTful API as the route for lodging passport identifiers with the registry. There is no indication of a manual portal being the primary path at volume. In practice this means passports reach the registry through software — either your own systems or a provider's — speaking the registry's interface.

Operator identity is verified by eIDAS qualified electronic seal. The party submitting is authenticated with a qualified e-seal under the eIDAS framework — the EU's established mechanism for legal-entity authentication. This is a meaningful signal: the registry will know, cryptographically, which economic operator stands behind each submission.

Successful submission returns a proof of registration, valid for presentation for 90 days. This is the detail most worth knowing, because it is the artefact you will actually handle. When a passport is registered, the registry issues a proof — the document an operator presents to customs and market surveillance authorities to show the battery's passport obligation is met. It is renewable evidence, not a one-off receipt, and it is what "registered" will look like in your hands.

Alongside the draft regulation, the CEN standards the DPP framework builds on — EN 18222:2026 for lifecycle APIs and EN 18216:2026 for data exchange — were published the same week. Together, the draft and the standards make the registry integration specifiable for the first time.

What is still draft

Honesty about status matters more here than anywhere. The implementing regulation is not law. The consultation closed in May; adoption and Official Journal publication are still ahead, and details can change between draft and final text. The Commission's stated target for the registry opening is July 2026 — a target, not a commitment, and one the adoption timetable will decide.

Nothing about the draft's status changes the date that binds you: from 18 February 2027, each in-scope battery placed on the EU market needs its passport, and that passport must be registered. The registry mechanics are firming up; the obligation was never in doubt.

What this means if you are the operator

If you are an importer, authorised representative, or a manufacturer issuing your own passports, the draft's practical message is reassuring: you are not expected to build any of this. The API, the e-seal integration, the proof handling — that is plumbing your passport provider carries. What you should take from the draft is a sharper standard for the question you ask any provider, including us: is your submission format aligned to what the EU has actually published, and what happens when the final text lands?

Where we stand

Our answer, stated plainly. The platform's registry submission format is now aligned to the draft implementing regulation and the published EN 18222 and EN 18216 standards — including the proof-of-registration model and its 90-day validity. Every field in the format carries a recorded source: the draft regulation, a named standard, or our earlier preliminary structure. And the version we will call final does not exist yet, deliberately — it is gated on the implementing regulation's publication in the Official Journal, at which point the per-field provenance makes reconciliation against the adopted text a checking exercise rather than a rebuild.

That is what tracking the regulation means in practice: build against what is published, label what is draft, and be one verification away from final rather than one rewrite. The registry pipeline — submission, proof handling, and the readiness checks that precede them — is part of the platform: see how the platform works.