What our battery passport can do — and what it cannot

The battery passport is not a product idea but an obligation under the EU Battery Regulation. Four provisions carry everything else.

Art. 77(1)

Every LMT battery, industrial battery above 2 kWh and electric vehicle battery placed on the market needs a passport. From 18 February 2027.

Art. 77(2)

The passport carries the information "to the extent applicable to the category of battery concerned". The obligation therefore depends on what kind of battery it is — which is why we measure completeness per category and not against a fixed list. What only becomes mandatory later (Art. 77(1): 18 Feb 2027; recycled content 18 Aug 2028; LMT 18 Aug 2033) does not block publication today — the studio lists it with its deadline, and the passport shows what it does not yet carry.

Art. 77(3)

One unique identifier per battery, reachable through a data carrier, with tiered access: the public sees part of it, market participants and authorities see more.

Annex XIII

The data content itself — in thirteen groups, from general battery information to the operating data of the individual battery.

The field catalogue is our implementation of Annex XIII. Each field carries its regulatory reference, its group, its expected data type, its plausibility bounds and the categories for which it is mandatory. It is publicly queryable.

How many of these fields are mandatory depends on the battery category. The German text of the regulation says "LV-Batterie" rather than LMT — which is why our category token is lv.

• lv · 103 mandatory fields
• industrial · 115 mandatory fields
• ev · 112 mandatory fields
• furniture · 43 mandatory fields

Art. 77(3) tiers the access. Every field in the catalogue carries its tier, and the tier decides whether a value leaves a response at all.

public135

Everyone. No sign-in, no key, no fee — this is the part a QR code on the vehicle opens.

restricted39

Market participants with a legitimate interest, and authorities. Repairers, remanufacturers, recyclers: what you need to take a battery apart and reuse it.

authorities5

Authorities and notified bodies only. Test reports, type-approval data, conformity evidence.

individual32

Only whoever operates the individual battery. State of health, cycles, operating events — data that says something about use.

The filter runs on the server, not in the browser. A field a role may not see is not hidden but not sent: it is not in the page source either.

The passport identifier is printed onto the battery and has to stay readable there for 15 years and more. It is therefore derived by a procedure, not assigned.

1. 1.Identifier per ISO/IEC 15459: issuing agency code (IAC) and company identification number (CIN) first, the battery serial number after. If IAC or CIN is missing, publication aborts — nothing is guessed.
2. 2.Data carrier: QR code per ISO/IEC 18004, quality grade per ISO/IEC 15415, verified per ISO/IEC 15426-2. Sizes, module width and quiet zone are fixed as a print specification, every value with its source.
3. 3.The QR code points at the passport address, and that address must be reachable by the public. A publication run from a development environment is refused — the address lands in an immutable record and would stay there for the life of the battery.
4. 4.Identifier and QR address are written by the passport itself, not supplied. Both values only come into existence at publication, and a supplied value there would not be a contribution but a contradiction.

Every published passport comes with a proof. It is reachable without a key and without a fee, because a check that presupposes a contract is not a check — whoever wants to verify a passport is precisely not a customer.

curl -s https://elektro-beta.vercel.app/api/v1/dpps/<UID>/proof

snapshot_sha256

The hash over the published state. A verifier holds the retrieved data against it and sees whether it is unchanged.

chain

The hash chain across all versions (EN 18221 4.2). Every version from the second onwards carries the hash of its predecessor; the database enforces it on write, the proof checks it on read. A removed or inserted version breaks the chain.

signature

The signature (JWS/ES256) over identifier, version, hash, operator and timestamp. It additionally answers who the state came from.

public_key

The public key as a JWK. Without it the signature cannot be checked, and a public key is public.

verification

Our own recomputation — so a person without cryptographic tooling sees something. Explicitly not the proof: whoever does not trust us checks the signature against the key themselves.

validity

Is the passport valid? Status, issue date, expiry, and the mapping onto the four status values of the standard. A revoked passport does not answer "does not exist" but "no longer valid".

integrity_status

ok, suspect or compromised. If the recomputation contradicts a signature that is present, the service marks the passport suspect itself and records an incident.

issuer

The issuer as a did:oyd. The identifier resolves at a public resolver to a document carrying the signing key behind this proof, making "who issued it" a verifiable chain rather than a number.

No key, no fee, no account. A higher request quota than the passport view, because a verifier does not check one passport but a delivery — and the quota is stated in every response so nobody discovers it by hitting it.

Every value carries its provenance. Not decoration: an estimated carbon figure and one taken from a test report look different in the passport, because they are worth different amounts.

verified

Taken from a test or evidence document and cross-checked.

partner_provided

Supplied by the economic operator and taken over unchanged. We assert nothing about it.

estimated

Estimated or derived. Permitted, but visible — and never presented as checked.

A value a model read out of a document and nobody cross-checked blocks publication. Not because models read badly, but because in a document with legal effect the difference between "read" and "checked" must not disappear.

The passport view is the page someone opens because they trust a marking on a product. It therefore collects as little as possible.

• No analytics and no third-party components on the passport route. No cookie banner, because there is nothing to consent to.
• Public reads are not logged. The rate-limit log names route and quota, never the caller's address.
• No input fields, no sign-in, no download on the passport page. If you are asked for any of those, you are not with us.
• What we do not control, we say: the hosting platform's access logs contain IP addresses. We have no access to them and we do not evaluate them.

A passport accompanies a battery across its lifetime. What changes has to stay traceable — including the mistakes.

• Every publication creates a new version with its own hash. Versions are only appended, never overwritten: a later state does not rewrite an earlier one. A later version requires a reason; reason, actor and hash chain are stored on the version and in the audit log (EN 18246 4.7). An archived passport — after a reissue — stays readable as the last published version and names its successor (EN 18221 4.2).
• The state at any point in time is retrievable. Whoever wants to know what the passport said on the day of an incident does not ask for a publication but for a date.
• A published passport cannot be deleted. A draft can. The difference is deliberate: the regulation requires the passport, and the GDPR exempts it from erasure in Art. 17(3)(b).

Eight documents from CEN and CENELEC describe what a digital product passport looks like technically. Six are final, two are drafts.

Important, and easily missed: none of these documents is cited in the Official Journal of the EU. Without that citation there is no presumption of conformity — conformity with the standard is therefore not evidence of conformity with the regulation. We build against these standards because they are the best available state of the art, not because they cover us.

The read methods follow EN 18222:2026. They return JSON, on request XML or JSON-LD, and redirect a browser to the human-readable view.

Every route states its request quota in every response, including on errors. An unusual number of rejections leaves a note in the operations log — counted per route, never per caller.

A passport that asserts something false is worse than a missing one. Whoever finds a mistake should be able to report it without signing in.

Wrong data, a QR code leading to a foreign address, or a passport whose proof does not add up: hello@sustainista.net