Battery Passport Technical Design (Article 78)

In the EU Battery Regulation, Article 77 says what the battery passport is and Article 78 says how it must work: the "essential requirements for the technical design and operation". It is a few paragraphs long, but it dictates a Digital Product Passport platform's identity, access, storage and verification architecture end to end.

Because the regulation was written before ESPR and the EN 1821x standards, it does not cite them. The requirements nevertheless line up: every sentence of Article 78 has a standard counterpart and an implementation decision. This article draws that mapping.

What Article 78 asks for

In plain language, the article requires:

• The passport must be fully interoperable with other battery passports; the data must rest on open standards, in an interoperable format, transferable without vendor lock-in (Article 77 states this explicitly).
• The data must be machine-readable, structured and searchable.
• Consumers, economic operators and other actors must have free access to the passport according to the access rights in Annex XIII.
• The data is stored by the responsible operator or by operators it has authorised; an authorised party must not process the data beyond what is necessary, nor sell it.
• The passport must remain accessible even if the responsible operator ceases to exist or ends its activity in the EU.
• The rights to access, introduce, modify and update data are limited by access rights.
• The authentication, reliability and integrity of the data must be ensured.
• The passport must be designed with a high level of security and privacy, and protected against fraud.

Article 77 adds one rule: access runs through the QR code on the battery and the unique identifier assigned by the operator placing it on the market.

Requirement, standard, implementation

Identity and access

The identifier decision is the passport's most permanent one: the identifier printed in the QR does not change for the battery's lifetime. The unique identifier rules of EN 18219 define global uniqueness and persistence; EN 18220 defines the carrier and app-free, free-of-charge access. Article 78's "free access" means the public tier opens without registration and without an app; the restricted tiers stay behind authentication.

Data model and APIs

The counterpart of the "open standard, interoperable format, machine-readable" triad is a core data model and standard APIs. The EN 18223 core data model gives the common fields; battery fields ride on top as an extension. EN 18222 passport APIs standardise querying the passport and a specific version of it; for audits, the version query is the most critical operation. Which dictionary names the Annex XIII fields, and how JSON-LD and AAS outputs are produced, is in the Battery Pass data model and Catena-X.

Persistence and the end of the operator

This is Article 78's hardest condition: the passport must remain accessible even if the responsible operator ceases to exist. That takes more than keeping one server alive. EN 18221 data storage and archiving defines retention period and archive format; data persistence and backup providers covers the triad of domain, export and an independent backup provider. The passport ends when the battery is recycled; until then every version must stay readable.

Authentication, security and tiers

The "authentication, reliability and integrity" condition means signing the data and proving it has not changed. EN 18246 data authentication and integrity lists the accepted approaches, such as verifiable credentials and eIDAS seals; in practice every version is signed at publication and earlier versions never change. Write rights are limited by access rights as well: who may update which field, which role only reads? Who gets each of the three battery tiers is covered in access roles in the battery passport.

Frequently asked questions