Battery Passport Data Model

Skip key takeaways

Updated September 21, 2026

• One record belongs to one battery, not one model line Model-level and instance-level information are split by Article 77(2), and only the instance record carries lifecycle use data.
• Read rights and write rights are both tiered Article 78 restricts introducing, modifying and updating the passport the same way Article 77 restricts reading it.
• A lifecycle event replaces the passport, it does not edit it Remanufacturing and end-of-life both trigger a new linked record rather than an update to the existing row.
• A durability figure has a test behind it, not a form field Performance values trace back to Article 10 documentation, and state of health to a live battery management system reading.
• The QR code resolves to the record, it is not the record A carrier applied before the record exists is a link with nothing on the other end for that whole production run.

Copy takeaways

Battery passport data model work usually starts with the wrong question, which format to export. The Regulation answers a different question first: who has to keep a record, about which battery, from what moment. Article 77(1) of the consolidated Batteries Regulation puts the duty this way: "From 18 February 2027 each LMT battery, each industrial battery with a capacity greater than 2 kWh and each electric vehicle battery placed on the market or put into service shall have an electronic record (‘battery passport’)." Read as a data-model brief, that one sentence already fixes three decisions: which batteries are in scope, that the record is electronic and that it exists before anyone asks which fields it carries.

In short: one passport belongs to one battery instance, never to a model line. Three access tiers govern both read and write, making the passport an authorization model rather than a document. And custody of the record moves at defined lifecycle events, so one long-lived row per battery is already the wrong shape.

The obligation, the parties and the record

Delegation never moves the accountability itself, only the paperwork. Article 77(4) puts the duty on the economic operator placing the battery on the market: "The economic operator placing the battery on the market shall ensure that the information in the battery passport is accurate, complete and up to date. It may give written authorisation to any other operator to act on its behalf." The second sentence is the delegation clause an account model needs from day one: the accountable operator can authorize another party in writing, but accountability never leaves the operator who placed the battery on the market. That operator is not the manufacturer by default either. Article 3 of the consolidated text defines it broadly, down to its operative clause: "‘economic operator’ means the manufacturer, the authorised representative, the importer, the distributor or the fulfilment service provider or any other natural or legal person who is subject to obligations in relation to... the placing of batteries on the market, including online, or the putting of batteries into service in accordance with this Regulation;"

Scope is class-bound rather than universal: each LMT battery, each industrial battery above 2 kWh and each electric vehicle battery. A schema built for every battery over-scopes; one built for every battery that gets a passport encodes the capacity threshold and the battery-type distinction as fields, not as an afterthought filter.

That capacity threshold is not the only reading of the term industrial battery in the text, and the gap matters for issuance logic. Article 3 defines the category itself with no capacity floor at all: "‘industrial battery’ means a battery that is specifically designed for industrial uses, intended for industrial uses after having been subject to preparation for repurposing or repurposing, or any other battery that weighs more than 5 kg and that is neither an electric vehicle battery, an LMT battery, nor an SLI battery;" Read next to the more than 2 kWh figure Article 77(1) states for the passport obligation itself, the two do not agree: every industrial battery meets the Article 3 definition, but only the ones above 2 kWh trigger a passport under Article 77(1). A schema cannot resolve that by treating the Article 3 category alone as the signal to issue a passport; issuance logic has to hold both readings at once, gating on the capacity figure as a first-class field rather than assuming the category decides the question by itself.

The battery passport data categories

Annex XIII is the entity list, and Article 77(2) turns it into a schema decision: "The battery passport shall contain information relating to the battery model and information specific to the individual battery, including resulting from the use of that battery, as set out in Annex XIII." The table below reads that split into ten categories. The first four columns are sourced from the Regulation; the last is Pharos Production practice.

Data category	Who is the source	When it is written	Access tier	Failure mode seen in practice
Model identity, marking, declaration of conformity	economic operator placing on the market	before placing on the market	public	keyed on the model identifier, so every unit shares one record and instance history has nowhere to attach
Material composition and chemistry	manufacturer, from supplier declarations	before placing on the market	public	supplier data arrives after the battery has shipped, so the public record launches with placeholders
Carbon footprint, recycled content, responsible sourcing	manufacturer, from its own Article 7, 8 and 52 documentation	before placing on the market	public	a figure with no pointer back to the declaration it came from cannot be re-derived at audit
Performance and durability values	manufacturer, under Article 10(1) test conditions	at placing on the market and at every status change	legitimate interest for the instance, public for the model headline figures	written once and never refreshed, so a battery years into service still reports its factory numbers
State of health	battery management system, under Article 14	continuously in the BMS, snapshotted at each status change	legitimate interest	copied once at manufacture and never read again, so the field is a constant pretending to be a measurement
Battery status: original, repurposed, re-used, remanufactured, waste	whichever operator performs the operation	at each lifecycle transition	legitimate interest	a single mutable field instead of an append-only log, so transition history cannot be reconstructed
Usage data: cycles, negative events, temperature, state of charge	the vehicle or system operator, via the BMS	periodically, over the service life	legitimate interest	the ingest timestamp is stored instead of the occurrence timestamp, so an accident lands in the wrong place in the history
Dismantling information, detailed composition, safety measures	manufacturer, at engineering release	before placing on the market	legitimate interest plus the Commission	the tier is enforced only in the interface, so the payload still reaches the browser and the rule is a CSS class
Test reports proving compliance	notified body with the manufacturer	at conformity assessment	notified bodies, market surveillance authorities, the Commission	stored as an opaque file with no link back to the requirement it evidences
Unique identifier and the QR code carrier	economic operator placing on the market	at marking, before the record behind it is complete	public for resolution, tiered for the content	applied before the record it links to exists, so a scan resolves to nothing for that whole production run

One passport per battery instance, not per model

The sentence quoted above rules out a passport-per-model design. A battery model is defined narrowly: "‘battery model’ means a version of a battery all units of which share the same technical characteristics relevant for the requirements of this Regulation on sustainability, safety, labelling, marking and information, and the same model identifier;" A model identifier groups units sharing the same technical characteristics; it is not a stand-in for the unit itself. Annex XIII point 4 makes the instance side explicit: "A battery passport shall include the following specific information and data relating to an individual battery, which shall be accessible only to persons with a legitimate interest" including "information and data resulting from its use, including the number of charging and discharging cycles and negative events, such as accidents, as well as periodically recorded information on the operating environmental conditions, including temperature, and on the state of charge." None of that use data has anywhere to live in a model-level row, since it differs from one physical battery to the next even when two batteries share a model identifier.

The two levels do not share a lifecycle either. Article 77(8) states it as a fact about the instance record alone: "A battery passport shall cease to exist after the battery has been recycled." A model record can outlive every unit built to it; an instance record cannot outlive its own battery. Keying everything on the model identifier and storing instance fields as extra columns on that row loses the thing the Regulation requires: a record that follows one physical battery from placing on the market to recycling.

Annex XIII is not fixed for good either, which is a second reason to version the two schemas separately. Article 77(2) closes with a delegation: "The Commission is empowered to adopt delegated acts in accordance with Article 89 to amend Annex XIII as regards the information to be included in the battery passport in view of technical and scientific progress." A schema pinned to today's Annex XIII needs a version field on the model side at minimum, because a delegated act can reshape a category without touching Article 77 itself.

The three access tiers are an authorization model

Article 77(1) states three tiers in one subparagraph, each a distinct clause. Public access: "information accessible to the general public in accordance with point 1 of Annex XIII;" Notified bodies, market surveillance authorities and the Commission: "information accessible only to notified bodies, market surveillance authorities and the Commission in accordance with points 2 and 3 of Annex XIII;" And persons with a legitimate interest: "information accessible only to any natural or legal person with a legitimate interest in accessing and processing that information for the purposes referred to in points (a) and (b) of the third subparagraph in accordance with points 2 and 4 of Annex XIII." Modeling this as one boolean, public or not, collapses a three-way partition into two states and loses the middle tier entirely.

The legitimate-interest tier is purpose-bound, not identity-bound: the Regulation gives exactly two admissible purposes, dismantling and repair, "concern dismantling of the battery, including safety measures to be taken during the dismantling, and the detailed composition of the battery model and be essential to allow repairers, remanufacturers, second-life operators and recyclers to conduct their respective economic activities in accordance with this Regulation;" and participation in the energy market, "in the case of individual batteries, be essential to the purchaser of the battery or parties acting on the purchaser’s behalf, for the purpose of making the individual battery available to independent energy aggregators or energy market participants." A grant is not a bare permission to read the passport; it is a permission scoped to one of those two purposes, so the authorization check has to carry the purpose alongside the identity.

Write access follows the same partition as read access. Article 78 states it directly: "the rights to access, introduce, modify or update information in the battery passport shall be restricted based on the access rights specified in Annex XIII and the implementing act adopted pursuant to Article 77(9);" while read access is free of charge: "consumers, economic operators and other relevant actors shall have access to the battery passport free of charge and based on their respective access rights set out in Annex XIII and the implementing act adopted pursuant to Article 77(9);" The matrix a platform needs has three dimensions: tier, operation and, for the legitimate-interest tier, which purpose applies.

Two more of the essential requirements bind the schema itself, ahead of who may touch it. Article 77(5) requires the passport's content to be "based on open standards and be in an interoperable format, transferable through an open interoperable data exchange network without vendor lock-in, machine-readable, structured and searchable, in accordance with the essential requirements laid down in Article 78." Article 78 then fixes where that content is allowed to live: "the data included in the battery passport shall be stored by the economic operator responsible for the fulfilment of the obligations under Article 77(4) or (7), or by operators authorised to act on their behalf;" A serialization tied to one vendor's proprietary format fails the first requirement outright, and a hosting arrangement that hands the data to a party outside that chain fails the second, whichever access tier happens to be reading it.

One boundary of that tier is still open. Article 77(9) required the Commission to settle exactly who qualifies, against three criteria including a limit on commercially sensitive information, "the need to ensure that the accessing and processing of information in the battery passport that is commercially sensitive is limited to the minimum necessary in accordance with applicable Union law." by a fixed date that has since passed: "By 18 August 2026, the Commission shall adopt implementing acts specifying which persons are to be considered persons with a legitimate interest as referred to in points 2 and 4 respectively of Annex XIII for the purposes of paragraph 2, point (c), of this Article 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." Nothing checked for this article confirms whether that act has landed. The safer design writes the tier as a configurable list rather than hard coding today's best guess.

Custody handover across the lifecycle

Responsibility is not fixed to one operator for the battery's whole life; it moves at named events. The first move happens on a second-life operation. Article 77(7) states it in two sentences a data model should read as two facts: "For a battery that has been subject to preparation for re-use, preparation for repurposing, repurposing or remanufacturing, the responsibility for the fulfilment of the obligations under paragraph 4 of this Article shall be transferred to the economic operator that has placed that battery on the market or has put it into service. Such battery shall have a new battery passport linked to the battery passport or passports of the original battery or batteries." That is a new record with a lineage edge back to the old one, not an update of the existing row. Reusing the same passport row across a remanufacturing event breaks the rule stated plainly here.

The second move happens when a battery becomes waste, to a different set of parties, per Article 77(7): "Where the status of a battery changes to that of a waste battery, the responsibility for the fulfilment of the obligations under paragraph 4 of this Article shall be transferred either to the producer or, where appointed in accordance with Article 57(1), the producer responsibility organisation, or the waste management operator selected in accordance with Article 57(8)." The passport's life then has the same hard stop already stated above for the instance record, the same Article 77(8) deletion rule rather than an archival one, and it applies here regardless of which party's responsibility triggered the waste transfer. Physical marking follows the same event structure: batteries that change status "Batteries that have been subject to preparation for re-use, preparation for repurposing, repurposing or remanufacturing shall bear new labels or shall be marked with markings in accordance with this Article, and containing information on their change of status in accordance with point 4 of Annex XIII, which shall be accessible through the QR code." A carrier printed once and never reissued cannot represent a battery whose status has since changed.

What the text leaves unresolved matters for a platform's design. Article 77(7) links the new passport to the old one, but nothing says what happens to the original record's data or who may still read it once responsibility has moved. A lineage graph that keeps the old record readable to at least the parties who already held legitimate-interest access is a defensible default, not a stated requirement. A related handover sits outside Article 77 on the same timeline: Article 77(10) of the consolidated text requires the same operator to upload the unique identifier into the registry under Article 13(1) of Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation, alongside the passport's own creation, not after it.

Where a measured value comes from

A durability figure in the passport has an upstream source, named two and a half years before the passport obligation itself starts. Article 10(1) requires a document, not a passport field, from an earlier date: "From 18 August 2024, rechargeable industrial batteries with a capacity greater than 2 kWh, LMT batteries and electric vehicle batteries shall be accompanied by a document containing values for the electrochemical performance and durability parameters set out in Part A of Annex IV." Annex XIII point 4(a) then points the passport at that same parameter set: "the values for performance and durability parameters referred to in Article 10(1), when the battery is placed on the market and when it is subject to changes in its status;" A value stored without a pointer back to the Article 10(1) document and its test conditions is a number with no way to be checked later.

State of health follows a parallel chain. Article 14 puts the live data in the battery's own management system: "From 18 August 2024, up-to-date data for the parameters for determining the state of health and expected lifetime of batteries as set out in Annex VII shall be contained in the battery management system of stationary battery energy storage systems, LMT batteries and electric vehicle batteries." and grants a non-discriminatory read-only right to it to the purchaser, for the purpose of "evaluating the residual value or remaining lifetime of the battery and capability for further use, based on the estimation of the state of health of the battery;" Annex XIII ties the passport's field back to that article: "information on the state of health of the battery pursuant to Article 14;" A passport storing a state-of-health number with no reference to the BMS reading it came from has substituted a snapshot for the live measurement Article 14 grants access to.

The carrier: an identifier before the record it names

The QR code is not the passport, and the text is explicit about the direction the link runs. Article 77(3): "The battery passport shall be accessible through the QR code referred to in Article 13(6) which links to a unique identifier that the economic operator placing the battery on the market shall attribute to it." The identifier is not a free-form string: "The QR code and the unique identifier shall comply with the ISO/IEC standards 15459-1:2014, 15459-2:2015, 15459-3:2014, 15459-4:2014, 15459-5:2014 and 15459-6:2014 or their equivalent." Both defined terms are narrow. A unique identifier "‘unique identifier’ means a unique string of characters for the identification of batteries that also enables a web link to the battery passport;" and a QR code "‘QR code’ means a machine-readable matrix code that links to information as required by this Regulation;" The carrier resolves to a record; it never carries the record's content itself.

Physical durability is a stated requirement, not packaging detail a platform can defer, and Article 13 requires the mark to be printed or engraved indelibly on the battery itself. Read against a manufacturing timeline, that is where the identifier-before-the-record failure actually happens: a production line marks the carrier when the physical battery exists, often before the back-office system has finished writing the record it resolves to. A carrier applied before its target record is queryable resolves to nothing for every unit made in that run, for however long the gap lasts.

Reference points: a German specification, a reference model and the wider product passport

The Regulation states what a passport must contain; it does not hand a team a field-by-field schema. Two non-binding reference points fill that gap, neither a standard a platform must follow. DIN DKE SPEC 99100, from the German Institute for Standardization and the German Commission for Electrical, Electronic and Information Technologies, states its purpose on its DIN Media catalog page: "In the context of a digital product passport for batteries (short: battery passport), this document gives guidance for battery passport data attributes." Its qualifier matters as much as its scope, since the 106-page document was not opened beyond its catalog record: "The development of a DIN DKE SPEC according to the PAS procedure is carried out in DIN-DKE-SPEC-consortiums and does not require the participation of all stakeholders." A specification developed that way is guidance, not a harmonized standard, and the DIN press release calls it exactly that: "The DIN DKE SPEC 99100 defines data attributes to be included in the digital battery passport based on both requirements by the EU Battery Regulation as well as voluntary additions."

A second reference point is a public reference data model, published by the Battery Pass consortium on GitHub under a permissive license. Its README describes the approach: "The data modelling approach follows the idea to provide a common formal plattform independent description of the semantic data model by means of the W3C Resource Description Framework (RDF) from which platform specific data model formats can be derived from." It ships RDF source with generated JSON Schema, JSON-LD context and OpenAPI derivations, a useful worked example of turning Annex XIII categories into machine-readable structures, organized into several parameter categories such as material composition and circularity. Its own banner carries two qualifiers: "The battery pass data model is still in draft mode and not finished yet." and the project itself has concluded, licensed "This work is made available under Creative Commons Attribution 4.0 International (CC-BY-4.0) license." A successor project, BatteryPass-Ready, has since published a newer data-attribute longlist, so this repository is a historical reference rather than a live specification to build against unmodified.

One requirement in the text points outward, to a passport this article does not otherwise cover. Article 78 states it: "the battery passport shall be fully interoperable with other digital product passports required by Union law concerning eco-design, in relation to the technical, semantic and organisational aspects of end-to-end communication and data transfer;" The battery passport is one instance of a wider product-passport pattern that Regulation (EU) 2024/1781 sets up across categories, and our headless commerce guide covers that Digital Product Passport architecture in full.

How Pharos Production helps

A battery passport implementation is three systems held to one identity: a model-level store carrying version history for Annex XIII changes, an instance-level store keyed on the unique identifier that accepts append-only lifecycle events rather than in-place updates and an authorization layer that checks tier, operation and purpose together rather than a single read flag. None of the three is optional, because Article 77 and Article 78 tie them together directly.

Our manufacturing software development work covers exactly that combination for production and asset-heavy platforms: the instance-keyed data layer, the authorization model behind a tiered access rule and the integration between a plant's own systems and the record a battery passport must keep accurate for the unit's life. Our manufacturing software development guide covers the wider platform patterns this system sits inside.

Sources: Regulation (EU) 2023/1542, consolidated text of 13 August 2026, on eur-lex.europa.eu; the European Commission, DG Environment, on environment.ec.europa.eu; DIN Media and DIN on dinmedia.de and din.de; the Battery Pass consortium data model repository on GitHub and the BatteryPass-Ready project on thebatterypass.eu. Read 21 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: September 21, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Does the QR code on a battery contain the passport data itself?

  Copy link Copies a direct link to this answer to your clipboard.

  No. Article 77(3) of the consolidated Batteries Regulation states that the battery passport is accessible through the QR code, and that the code links to a unique identifier the economic operator placing the battery on the market attributes to it. The identifier and the code are both defined narrowly in Article 3: a unique identifier enables a web link to the passport, and a QR code is a machine-readable matrix code that links to information.

  Neither definition describes a container for the record's content. Design the QR code and identifier as a stable pointer that resolves through your own lookup, never as a payload carrying data, and keep the resolvable content behind the same authorization checks that apply everywhere else in the system.

• What happens to the original battery passport when a battery is remanufactured?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 77(7) is explicit about one half of this: a battery that has been prepared for re-use, prepared for repurposing, repurposed or remanufactured gets a new battery passport, linked to the passport or passports of the original battery, and responsibility transfers to the operator that placed the remanufactured battery on the market. What the text does not say is what happens to the original record afterward, or who may still read it once responsibility has moved.

  That is a genuine gap the Regulation leaves to implementation. Our practice at Pharos Production is to keep the original record readable to at least the parties who already held legitimate-interest access to it, as a defensible default rather than a stated requirement.

• Has the EU decided who counts as a "person with a legitimate interest" yet?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 77(9) required the Commission to adopt an implementing act specifying exactly that, against three stated criteria, by a fixed deadline that has already passed. Nothing checked for this article, including the European Commission's own battery policy page, confirms whether the act has been adopted.

  Writing that it has, or that it has not, would both be unsupported claims from where this article stands. The workable position for a platform is to build the legitimate-interest tier as a configurable list of qualifying purposes and evidence checks rather than a hard-coded assumption, so the authorization logic survives either outcome without a redesign.

• Does every industrial battery need a passport?

  Copy link Copies a direct link to this answer to your clipboard.

  No, and the gap is easy to miss because the Regulation defines the term two different ways for two different purposes. Article 77(1) creates the passport obligation only for industrial batteries with a capacity greater than 2 kWh, alongside LMT and electric vehicle batteries.

  Article 3's definition of industrial battery itself carries no capacity floor at all; it is any battery designed for industrial use that is not an electric vehicle, LMT or SLI battery. A product team building one system for a mixed portfolio of industrial batteries hits this immediately: the capacity threshold has to be a first-class field the passport-issuance logic checks, not an assumption baked into which batteries reach the pipeline at all.

• Must a battery passport be built on a blockchain or a decentralized registry?

  Copy link Copies a direct link to this answer to your clipboard.

  No requirement in the text says so. Article 77(5) and Article 78, covered in the body, fix the passport's interoperability, format and storage-locus requirements, and neither one names a distributed ledger, a blockchain or any other particular architecture.

  Whether a decentralized registry is the right way to meet those requirements anyway is a genuine open engineering question the Regulation does not answer, and treating it as settled either way, in favor of a ledger or against one, overstates what the text says.

• Where should a data model start if the Regulation itself doesn't define field names?

  Copy link Copies a direct link to this answer to your clipboard.

  Two non-binding reference points exist today, and neither is a standard a platform is required to follow. DIN DKE SPEC 99100, developed under a PAS procedure that by its own description does not require every stakeholder's participation, gives guidance on battery passport data attributes based on Article 77, Annex XIII and the wider Ecodesign for Sustainable Products Regulation.

  A separate reference data model, published by the Battery Pass consortium on GitHub under a CC-BY-4.0 licence, models Annex XIII categories in RDF with generated JSON Schema and OpenAPI derivations, though its own README states the model is still in draft mode and the schemas are for demonstration purposes only. Treat both as a starting vocabulary to adapt, never as a schema to adopt unmodified.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.