EU Battery Passport Software Architecture: Build for February 2027
From 18 February 2027, each covered EV battery, light-means-of-transport battery, and industrial battery above 2 kWh placed on the EU market needs an electronic battery passport. Build it as a durable identity and access system: one globally unique battery identifier, a QR-resolvable public entry point, governed restricted data, interoperable formats, and lifecycle updates.
The passport is not a PDF behind a QR code. It is a long-lived data product that must remain accurate across manufacturers, repairers, recyclers, and regulators. The Commission's August 2026 guidance identifies 71 data points, while the regulation controls who may see which data.
Which batteries and systems are affected?
| Design input | Requirement | Architecture consequence |
|---|---|---|
| Scope | EV, LMT, and industrial batteries above 2 kWh | Resolve regulatory scope at SKU and physical-unit level |
| Identity | Unique passport for each battery | Use an immutable battery ID, not a mutable model or batch URL |
| Access | Public and restricted data classes | Enforce policy at field level and log privileged reads |
What is the minimum viable battery passport architecture?
Use five layers: identity, ingestion, canonical data, policy, and publication. Keep the QR destination stable while services behind it evolve. The canonical record should retain provenance, effective dates, units, validation status, and superseded values instead of overwriting history.
- Identity service for battery ID, model, economic operator, and QR resolver.
- Signed ingestion APIs for manufacturing, testing, service, state-of-health, and recycling events.
- Versioned schema with units, vocabularies, source, timestamp, and quality flags.
- Policy engine for public, notified-body, market-surveillance, repairer, and legitimate-interest access.
- Export and availability layer that does not depend on one vendor's proprietary portal.
How should teams model the 71 data points?
Start with a requirements matrix, then map every item to source system, owner, update event, validation rule, access class, retention rule, and failure behavior. A field without a reliable source is a delivery risk, even when the JSON schema is complete.
- Separate static model data from unit-specific manufacturing and lifecycle data.
- Represent measurement units explicitly and reject ambiguous conversions.
- Attach evidence references and signatures to claims that affect conformity or sustainability.
- Design correction and dispute workflows for data supplied by third parties.
What fails in real battery-passport projects?
The recurring failures are identity collisions, broken QR destinations, spreadsheet-based handoffs, excessive public exposure, and no owner for post-sale updates. Test degraded connectivity and organizational handovers, not just happy-path API calls.
- Never encode sensitive passport data directly in the QR payload.
- Do not make a recycler depend on the original manufacturer's employee login.
- Define availability and export plans for insolvency, acquisition, and provider replacement.
A practical delivery sequence
- Inventory battery categories, economic-operator roles, markets, and unit volumes.
- Build the data-point matrix and close source-system gaps before choosing a portal.
- Prototype one battery identity from production through service and recycling.
- Implement public and restricted views with auditable authorization tests.
- Run interoperability, QR durability, load, backup, export, and supplier-failure tests.
- Pilot on one product line, measure data quality, then scale before 18 February 2027.
Build the product, not just the backlog
If this article maps to a real product decision, Wavect can help you scope, build, harden, or lead the software work with senior founder-level judgment.
Useful service paths:
EU battery passport FAQ
When does the EU battery passport become mandatory?
Is a battery passport just a QR code?
Must every field be public?
Should we buy a portal or build one?
Final thoughts
The winning architecture starts with unit identity and data ownership, then adds interoperable access. Teams that begin with a QR demo usually discover the expensive lifecycle and governance work too late.
Primary sources
- Regulation (EU) 2023/1542. Binding battery-passport scope and requirements
- European Commission battery-passport guidance. Current preparation guidance and the 71-data-point summary
- European Commission Digital Product Passport hub. Current implementation resources and registry information