--- title: "EU Battery Passport Software Architecture for 2027" canonical: https://wavect.io/blog/eu-battery-passport-software-architecture-2027/ language: en description: "Design an EU battery passport for February 2027: scope, unique identity, 71 data points, access policy, APIs, QR durability, testing, and rollout." image: "https://wavect.io/img/blog/headers/header_eu-battery-passport-software-architecture-2027.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 24 Aug 2026 Last reviewed August 24, 2026 [**Next**](/blog/eu-product-liability-software-evidence-2026/) # EU Battery Passport Software Architecture: Build for February 2027 TL;DR Covered EV, LMT, and industrial batteries above 2 kWh need an electronic passport from 18 February 2027. Build one immutable identity per battery, keep the QR destination stable, map all required data to accountable source systems, separate public and restricted access, preserve lifecycle history, and test interoperability, export, weak connectivity, and provider failure before scaling. **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 1. Inventory battery categories, economic-operator roles, markets, and unit volumes. 2. Build the data-point matrix and close source-system gaps before choosing a portal. 3. Prototype one battery identity from production through service and recycling. 4. Implement public and restricted views with auditable authorization tests. 5. Run interoperability, QR durability, load, backup, export, and supplier-failure tests. 6. Pilot on one product line, measure data quality, then scale before 18 February 2027. ## EU battery passport FAQ ### When does the EU battery passport become mandatory? The obligation applies from 18 February 2027 for covered batteries placed on the market or put into service. ### Is a battery passport just a QR code? No. The QR code is an access mechanism. The passport also needs unique identity, governed data, lifecycle updates, availability, and interoperability. ### Must every field be public? No. The regulation distinguishes generally accessible information from data available only to specified actors or people with a legitimate interest. ### Should we buy a portal or build one? Decide after mapping data ownership, integrations, identity, access, exit, and operational obligations. A portal cannot repair missing source data. ## 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 1. [Regulation (EU) 2023/1542](https://eur-lex.europa.eu/eli/reg/2023/1542/oj). Binding battery-passport scope and requirements 2. [European Commission battery-passport guidance](https://single-market-economy.ec.europa.eu/news/guidance-support-preparations-digital-batteries-passport-2026-08-21_en). Current preparation guidance and the 71-data-point summary 3. [European Commission Digital Product Passport hub](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en). Current implementation resources and registry information ## You may also like.. [**Smart-city architecture best practices** See how durable device identity, edge systems, and data platforms fit together.](/blog/smart-city-architecture-best-practices-2026/) [**Wavect vs development agencies** Compare IoT delivery options for a regulation-driven platform.](/compare/wavect-vs-dev-agencies/) Architecture and platforms ## Continue through this cluster Framework, platform and system-design choices that affect delivery over the long term. [Start with the cornerstone**Smart City Architecture Best Practices: MQTT, LoRaWAN, Kubernetes and Terraform**](/blog/smart-city-architecture-best-practices-2026/) - [EU Data Act: Connected-Product API Checklist](/blog/eu-data-act-connected-product-api-2026/) - [Cursor Origin vs GitHub: Should Your Team Switch?](/blog/cursor-origin-vs-github-code-hosting/) - [MoneyPrinterTurbo Review 2026: Free AI Video, Real Costs](/blog/moneyprinterturbo-review-2026/) - [Odoo API integration: the five limits that decide your architecture](/blog/odoo-erp-api-integration-limits-2026/) - [AI in Grocery Retail: An MPREIS Opportunity Map](/blog/mpreis-ai-grocery-retail-opportunity-map/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 24 Aug 2026 Last reviewed August 24, 2026 [**Next**](/blog/eu-product-liability-software-evidence-2026/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/eu-battery-passport-software-architecture-2027/#webpage", "@type": "WebPage", "dateModified": "2026-08-24", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-24", "url": "https://wavect.io/blog/eu-battery-passport-software-architecture-2027/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Covered EV, LMT, and industrial batteries above 2 kWh need an electronic passport from 18 February 2027. Build one immutable identity per battery, keep the QR destination stable, map all required data to accountable source systems, separate public and restricted access, preserve lifecycle history, and test interoperability, export, weak connectivity, and provider failure before scaling.", "articleBody": " Blog overview/Delivery and QA/Architecture and platforms EU Battery Passport Software Architecture: Build for February 2027 TL;DR Covered EV, LMT, and industrial batteries above 2 kWh need an electronic passport from 18 February 2027. Build one immutable identity per battery, keep the QR destination stable, map all required data to accountable source systems, separate public and restricted access, preserve lifecycle history, and test interoperability, export, weak connectivity, and provider failure before scaling. 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 inputRequirementArchitecture consequence ScopeEV, LMT, and industrial batteries above 2 kWhResolve regulatory scope at SKU and physical-unit levelIdentityUnique passport for each batteryUse an immutable battery ID, not a mutable model or batch URLAccessPublic and restricted data classesEnforce 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. Useful service paths: Internet of Things See it in production: Bond Analytics Platform Decide it first: How to choose a software development agency EU battery passport FAQ When does the EU battery passport become mandatory? The obligation applies from 18 February 2027 for covered batteries placed on the market or put into service. Is a battery passport just a QR code? No. The QR code is an access mechanism. The passport also needs unique identity, governed data, lifecycle updates, availability, and interoperability. Must every field be public? No. The regulation distinguishes generally accessible information from data available only to specified actors or people with a legitimate interest. Should we buy a portal or build one? Decide after mapping data ownership, integrations, identity, access, exit, and operational obligations. A portal cannot repair missing source data. Final thoughts The winning architecture starts with unit identity and data ownership, then adds", "articleSection": "IoT", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Regulation (EU) 2023/1542", "url": "https://eur-lex.europa.eu/eli/reg/2023/1542/oj" }, { "@type": "WebPage", "name": "European Commission battery-passport guidance", "url": "https://single-market-economy.ec.europa.eu/news/guidance-support-preparations-digital-batteries-passport-2026-08-21_en" }, { "@type": "WebPage", "name": "European Commission Digital Product Passport hub", "url": "https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en" } ], "dateModified": "2026-08-24", "datePublished": "2026-08-24", "description": "Covered EV, LMT, and industrial batteries above 2 kWh need an electronic passport from 18 February 2027. Build one immutable identity per battery, keep the QR destination stable, map all required data to accountable source systems, separate public and restricted access, preserve lifecycle history, and test interoperability, export, weak connectivity, and provider failure before scaling.", "headline": "EU Battery Passport Software Architecture for 2027", "image": "https://wavect.io/img/blog/headers/header_eu-battery-passport-software-architecture-2027.svg", "inLanguage": "en", "keywords": "EU Battery Passport, IoT Architecture, Digital Product Passport", "mainEntityOfPage": { "@id": "https://wavect.io/blog/eu-battery-passport-software-architecture-2027/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/eu-battery-passport-software-architecture-2027/", "wordCount": 977 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/delivery-qa/", "name": "Delivery and QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/architecture-platforms/", "name": "Architecture and platforms", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/eu-battery-passport-software-architecture-2027/", "name": "EU Battery Passport Software Architecture for 2027 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "The obligation applies from 18 February 2027 for covered batteries placed on the market or put into service." }, "name": "When does the EU battery passport become mandatory?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. The QR code is an access mechanism. The passport also needs unique identity, governed data, lifecycle updates, availability, and interoperability." }, "name": "Is a battery passport just a QR code?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. The regulation distinguishes generally accessible information from data available only to specified actors or people with a legitimate interest." }, "name": "Must every field be public?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Decide after mapping data ownership, integrations, identity, access, exit, and operational obligations. A portal cannot repair missing source data." }, "name": "Should we buy a portal or build one?" } ] } ```