The battery passport becomes mandatory on 18 February 2027, and unlike the packaging label, that date does not move. Five months to go. The obvious question is what has actually been built on the EU side. We looked — not at press releases, but at the registry's own publicly served interface.
What the registration form asks for today
The registry's online form asks for four things:
- Unique Product Identifier (UPI) — required
- Granularity level
- Batch identifier
- Model identifier
That is precisely the three-level chain our article on model, batch and item describes: the registry thinks in models, production batches and individual units too. If you have been planning your passports flat, at model level only, this form is the first warning.
Five things the interface reveals
1. Granularity currently knows exactly one value: Item. The interface's language file contains precisely one enum label for granularity, and it is "Item". There is no "Model", no "Batch". That is why the dropdown cannot be changed — not a bug, simply the only level live so far. The batch and model identifier fields are there, so for now the hierarchy is expressed through those.
2. The UPI is a URL, and its only formal rule is one sentence. The field's error message says the value is an invalid URL and must start with https://. We found no length limit in the shipped code: we went through all thirteen JavaScript bundles and there is no length validation bound to the field. The registry's user guide, however, mentions 50 characters. The two are not in conflict — the limit does not live in the form — but it is worth knowing that the browser will not warn you if you exceed it.
This is not academic. A full model → batch → item chain in GS1 Digital Link form is 62 characters on our own domain. A model-level address is 35. In other words, the length of your domain affects whether your item-level identifier fits inside a documented budget — which the article on switching providers and lock-in approaches from another angle.
3. Bulk registration exists, and it has a fixed size. File upload accepts JSON or XML, at most 100 registration requests per file, and the interface offers downloadable template.json / template.xml samples. If you will be registering thousands of passports, that batch size is a planning figure.
4. The system is several separate services. The interface's own configuration names three distinct hosts: authentication, API and the registry itself. Sign-in goes through EU Login with OAuth2.
5. There is no public API schema. We tried the usual paths (OpenAPI, Swagger). None is reachable; the services are alive but closed. Anyone planning a machine integration cannot work from documentation today.
What we did not find in the interface
What is missing is just as telling. Regulation (EU) 2026/1778 mentions several capabilities of which there is no trace at all in the interface's strings — checked keyword by keyword:
| What the law mentions | Where | In the interface |
|---|---|---|
| Link to the backup copy held by the provider | recital 16 | absent |
| Delegation of access rights to a third party | Art. 6(1) | absent |
| Transfer of registered passports | Art. 6a | absent |
| Proof of registration | recital 17 | absent |
| Semantic data repository | Art. 3(g) | absent* |
* The word "semantic" appears twice, but both are error codes ("semantic validation failed"), not a repository.
This is not a criticism: the registry went live in July 2026, and the law itself applies in stages. But it matters when planning. Anyone promising today that their product "registers a backup link with the registry" is promising something whose interface does not yet exist.
The registry is not a database — and that is the point
It is worth being clear about what it does. The registry is an index: it stores an identifier, metadata and a location. The passport content itself stays with the manufacturer (or their provider).
One important consequence follows: access control is not the registry's job. What a person scanning your passport gets to see is decided by your system. And that is exactly where the largest open question sits.
The layer with no legal content yet
Under Annex XIII of (EU) 2023/1542, the battery passport has three layers: public · legitimate interest · authority. The middle one is the interesting one, because it is filled in by the implementing act under Article 77(9):
"By 18 August 2026, the Commission shall adopt implementing acts specifying which persons are to be considered persons with a legitimate interest … and to which information listed in those points they shall have access, and to what extent they can download, share, publish and re-use that information."
Regulation (EU) 2023/1542, Article 77(9) — official English text
That deadline has passed and the act does not exist. A draft went to the Commission's batteries expert group in April 2026, and the Commission's own timetable puts adoption in the fourth quarter of 2026.
So the state of play is this: the term "person with a legitimate interest" has no legal content — while in five months you must ship a passport that has such a layer.
What the industry assumes — and why to be careful
Commentary routinely reads the term as covering repairers, refurbishers, second-life operators and recyclers. That is probably how it will land: Article 77(2) itself names dismantling, composition and repair as the purposes.
But the assumption pre-judges an instrument that has not been adopted. It remains open whether some form of proof or registration will be required to qualify, what may be done with the data seen (download, sharing, publication), and whether the list will be closed or extensible. Anyone burning a fixed roster into their system today will likely rebuild it.
How we measured. The findings about the registry come from its publicly served interface files (entry HTML, language file, JavaScript bundles, configuration) as of 7 September 2026; the production and acceptance environments were byte-identical at that point. We did not submit a registration, so we make no claim about what the server accepts — only about what the interface asks for and validates. This article is information, not legal advice, and it describes a moving situation.
What you can do in five months
The good news is that the missing act does not block most of the work. What can be done today:
- Set up the three-layer structure. Annex XIII already tells you which field belongs to which level. What is unsaid is only who may reach the middle one.
- Fill in the public layer. It is fully known, and it is what most scanners will see.
- The QR code and the identifier. The code encodes an address, not data — see the GS1 Digital Link article — so it can be printed before the last field is settled.
- Carry the levels through. If your product lives in batches or individual units, build that now: the registration form already asks for batch and model identifiers.
- Collect supplier data. It takes the longest and depends on no act at all.
What to leave open: the recipients of the legitimate-interest layer. What should be hard-wired is the classification of fields, not the roster of who qualifies — that has to remain adjustable.
How does Veridyn help?
This is precisely the distinction we built in. In Veridyn's schemas, fields are pre-assigned to access levels — public, legitimate interest, authority — so the structure is ready before the law says who qualifies for which level. When the act appears, you do not rebuild the data model; you classify the recipients.
You already grant the authority layer through a token link, with field-level precision — the same machinery will serve legitimate-interest actors. The model → batch → item chain can be carried through, and the printed QR resolves the whole chain.
See it live, or start for free — the first passport takes minutes.