The registry is open and cannot take a battery. So we tested somewhere that could

Where the registry actually is

The EU Digital Product Passport registry went live on 20 July 2026. Its implementing regulation, (EU) 2026/1778, has applied since 6 August. It is a real system with a real front door.

It cannot yet take a battery. Registering a passport needs a format for that product group, and the battery format has not been published. There is no date for it. Six of the harmonised DPP standards were listed in the Official Journal on 15 July under Implementing Decision (EU) 2026/1736; two further standards, EN 18239 and EN 18246, are still awaited, with a second decision expected in September.

None of this moves the obligation. From 18 February 2027, every EV battery, every light-means-of-transport battery and every industrial battery above 2 kWh placed on the EU market must have a passport. The door is open and the form is missing, and the deadline is the same.

If you are an importer, an authorised representative or a manufacturer issuing your own passports, that leaves a practical question. How do you find out whether what you have built will work before the one place that matters can tell you?

What BatteryPass-Ready is

BatteryPass-Ready is a free test environment for the battery passport. It is built by Fraunhofer IPK, acatech, TU Berlin and GEFEG, the consortium behind the earlier Battery Pass project, whose technical and content guidance much of the industry works from. It is funded by Germany's Federal Ministry for Economic Affairs and Energy and runs until March 2027. It is not the Commission and it does not speak for the Commission. What it does is take the harmonised standards being developed for the EU passport, EN 18222 for the passport lifecycle interface and EN 18219 for identifiers, and build a working copy of what the central services are expected to look like: a registry, a back-up provider, and the calls between them.

You point it at your own system and it runs scenarios against you. Eleven of them at present, in three groups. Placing a battery on the market, which drives the full registration workflow. Reading a passport back, by its identifier and by the product it belongs to, with the access filtering the Battery Regulation requires. Updating a passport, including the case where someone without the right to update tries.

It also validates the passport document itself against its own data model, which is the consortium's reading of Annex XIII in JSON Schema form, published openly.

What we did

We built the pieces the test drives. The lifecycle interface from EN 18222, at the exact paths the standard defines. The adapter their harness uses to set up each scenario. The registration workflow: back the passport up, then register it. Role-based access, so a public reader and an economic operator see different things. And a translator from our own passport into their February 2027 document format.

Then we ran the eleven scenarios against our production system. Not a staging copy. All eleven pass.

That exercises the interface with the consortium's own reference battery records. We then did the other half: we took one of our own production passports, translated it into their February 2027 document format, and put it through their services directly. Their back-up provider accepted it. Their validator accepted it as well-formed against the February 2027 schema, and listed what was missing.

What that proves

It proves that our platform speaks the interface the standard defines, in both directions, and gets the lifecycle right: a new version on every update, archived passports invisible to normal reads, the correct refusal when a caller has no write permission, and the right fields withheld from a public reader. It proves that a battery can be placed on the market through the full sequence of calls the standard expects, against a system that behaves like the central services.

For our customers, it means the platform's registration and passport-serving plumbing has been exercised end to end by someone other than us, against the published standard, before the real registry can do so.

It also proves that a passport built on our platform, not a hand-made test file, produces a document the consortium's tooling accepts and can hold in back-up. That is the half of the test most people will skip, and the half that tells you whether your real data is ready.

What it does not prove

It does not prove compliance. Nobody at the Commission has seen a byte of this. BatteryPass-Ready is one careful reconstruction by a well-placed consortium, and it may differ from the registry that eventually opens to batteries. When the battery format is published, we test again, against the real thing.

It also surfaced something worth knowing before anyone else runs the same test. The consortium's February 2027 document requires just over a hundred data points. The Commission's own mandatory list for a passport is considerably shorter. That same passport, which met the Commission's mandatory list, showed more than forty gaps against their validator. That is not a defect on either side. It is the difference between what the law requires and what a full technical model can hold, and it is exactly the kind of thing you want to see now rather than in February.

What this means for you

There is nothing you can do at the registry today, and there will not be until the battery format lands. What you can do is make sure your passport data is complete against the mandatory list, that your identifiers follow EN 18219, and that whoever hosts your passports can serve them through the standard interface when the time comes.

Our platform does that now, and has been tested doing it. You can see how a passport is built, served and kept up to date at /platform.