Battery Passport and PLM: How EU Rules Reshape Product Data
Battery passport PLM is no longer a research topic — it is a compliance deadline. EU Regulation 2023/1542 on batteries mandates a machine-readable battery passport for light-means-of-transport (LMT), industrial, and electric-vehicle batteries above 2 kWh, with phased obligations applying from approximately February 2027. For engineering and PLM teams that have spent years managing product data inside closed enterprise systems, this regulation is the most structurally disruptive data requirement since RoHS.
What this covers: the EU battery passport data model, what it demands from your PLM/ERP stack, a reference architecture for connecting those systems to the Digital Product Passport (DPP) registry, and a concrete checklist of what to build before the compliance window closes.
Context: The EU Battery Regulation and the Digital Product Passport
The EU Battery Regulation (2023/1542) entered into force in August 2023. It repeals the older 2006/66/EC Batteries Directive and introduces a lifecycle-wide framework covering manufacturing, supply-chain due diligence, carbon footprint disclosure, end-of-life management, and — crucially — digital traceability. The battery passport is the regulation’s enforcement mechanism for that traceability obligation.
The battery passport is an instance of the broader Digital Product Passport (DPP) concept being embedded across EU product legislation. The European Commission’s Ecodesign for Sustainable Products Regulation (ESPR) established the DPP framework, and batteries are the first major product category where it becomes legally binding at scale. Understanding the DPP schema is therefore not optional context — it is the technical specification your passport service must conform to.
Under the regulation, each qualifying battery must carry a unique identifier linked to a record accessible via a QR code or RFID. That record must include composition, carbon footprint, performance, due-diligence declarations, and end-of-life instructions. The Global Battery Alliance (GBA), which ran a series of battery passport pilots between 2021 and 2024, found in its 2023 pilot report that data completeness was the single largest challenge — not the QR code, not the registry, but the underlying product data held in disconnected enterprise systems. You can read GBA’s pilot findings at https://www.globalbattery.org/battery-passport/.
The official EU text is available at https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1542. The delegated acts that will specify the exact data attributes for each passport category were in preparation as of mid-2026; manufacturers should monitor EUR-Lex for their adoption.
The thesis of this article is blunt: most PLM implementations were designed to manage design intent, not to publish live product records to external registries with legally binding accuracy. Closing that gap requires architectural change, not just a new report template.
What the Battery Passport Demands of PLM
The Data Model and Required Attributes
The battery passport data model spans six attribute clusters. Every cluster maps to a data source that currently lives in a different enterprise system — and often in a different organizational silo.
Figure 1 — The battery passport data model. Each cluster (Identity, Composition, Carbon Footprint, Due Diligence, Performance, End-of-Life) maps to a distinct data source in the enterprise stack. PLM owns the shaded clusters; ERP and MES own the rest.
The six clusters are:
1. Identity and general information. Manufacturer name, model, rated capacity, chemistry type, and date of manufacture. This data lives naturally in PLM as item master and BOM header attributes. The challenge is granularity: the passport requires cell-level or module-level unique identifiers, not just part-number-level records. Most PLM systems today carry part numbers and revisions — not serialised unit identifiers. Extending PLM to carry unit-level identity (or federating it with a serialisation service in ERP/MES) is one of the first structural changes teams must make.
2. Composition and materials. Active materials, hazardous substances, critical raw materials (CRMs) such as cobalt, lithium, nickel, and manganese, and the percentage of recycled content in CRMs. This is squarely PLM territory — it maps to the material and substance data already required for RoHS, REACH, and conflict-mineral reporting. But the battery regulation raises the bar: recycled-content percentages must be declared per CRM, and the methodology for calculating them must be disclosed. PLM teams that rely on supplier-provided SDS/material declarations without a structured substance management module will struggle here.
3. Carbon footprint data. A declared carbon footprint value in kg CO₂e per kWh for the manufacturing phase, and a carbon footprint class (A through E, to be defined in delegated acts). The carbon footprint must be calculated according to the methodology specified in the regulation — which aligns broadly with ISO 14067 and the GBA’s Battery Carbon Footprint Methodology. This data does not live in PLM today. It is assembled from supplier declarations, energy consumption data from manufacturing operations, and transport emissions calculations — typically scattered across ERP, sustainability reporting tools, and spreadsheets. The passport obligation creates a hard requirement to structure this data and link it to the product record.
4. Due-diligence data. Supply-chain due-diligence declarations for CRMs, covering sourcing origin, social and environmental risk assessments, and compliance with the regulation’s Annex X requirements. This is new data for most PLM teams — it is closer to procurement compliance than engineering data management. Structuring it as part of the product record, rather than leaving it in procurement document repositories, is a significant process change.
5. Performance and durability. Rated capacity, expected cycle life, power fade threshold, and state-of-health (SoH) reporting requirements for batteries placed on the secondary market. Performance data originates in product engineering (PLM) but is validated in manufacturing test (MES). The SoH requirement for second-life batteries means the passport record must be updatable throughout the battery’s life — it is not a static document stamped at manufacture.
6. End-of-life and recycling. Dismantling information, hazardous material locations, waste codes, and recyclability rates. This maps to service and end-of-life documentation in PLM, but the level of structured detail required — machine-readable, not just a PDF — is higher than most current implementations provide.
The implication is clear: no single system owns all six clusters. Battery passport PLM integration is fundamentally a data federation problem.
Carbon Footprint and Due-Diligence Data
Carbon footprint and due-diligence data deserve separate attention because they require the deepest changes to existing data collection processes.
For carbon footprint, the regulation distinguishes between the declared CF at time of placing on market and a verified CF that will be required once conformity assessment bodies and methodologies are fully established. Early movers should design their data collection to support both: a declared CF assembled from supplier data, and an auditable evidence trail that can support third-party verification later.
Practically, this means treating CF data as a first-class attribute in the PLM BOM — not as a sustainability report generated separately. Each material line on the BOM should carry a CF intensity factor (kg CO₂e per kg of material) sourced from the supplier’s EPD or a recognised secondary database. Process emissions from manufacturing operations should be apportioned per cell or per batch. This is not a feature most PLM systems provide out of the box; it requires configuration or a purpose-built CF calculation service connected to the PLM API.
Due-diligence data is politically and operationally complex. The regulation requires manufacturers to identify and assess risks in the supply chain for cobalt, lithium, natural graphite, and nickel. The OECD Due Diligence Guidance for Responsible Mineral Supply Chains is the reference methodology. Translating this into structured PLM records means capturing mine-of-origin or smelter-of-origin data at the supplier level, which many Tier-1 suppliers currently decline to provide or provide only in unstructured PDF form. Procurement teams need to begin supplier engagement now — the 2027 deadline is not forgiving.
The Digital Thread Across Suppliers
The battery passport is, at its core, a digital thread requirement. It mandates that information created at multiple points in the supply chain — mine, refiner, cell manufacturer, pack manufacturer, vehicle OEM — be traceable to a single product record accessible via a unique identifier.
For PLM digital thread architecture, this is the scenario the concept was designed for. But most digital thread implementations today are internal — connecting CAD, BOM, simulation, and manufacturing within one enterprise. The battery passport extends the thread upstream to Tier-N suppliers and downstream to recyclers and regulators.
Figure 2 — End-to-end data flow. PLM contributes composition and identity data; ERP contributes carbon footprint records and procurement declarations; MES contributes test results and batch IDs. A passport service aggregates, validates, and publishes a signed JSON-LD payload to the EU DPP registry, which resolves via QR code to downstream stakeholders.
The cross-enterprise nature of this thread creates three specific challenges that PLM teams must design for:
Identifier alignment. Suppliers use their own part numbers and batch identifiers. The passport requires a globally unique battery identifier — the regulation references the proposed standard under IEC 61960 and the GS1 EPCIS standard for event-level traceability. Your PLM system must map internal part numbers and serial numbers to these external identifiers without ambiguity.
Data ownership at handoff. When a cell manufacturer supplies cells to a pack integrator, who is responsible for the passport record — and who can update it? The regulation assigns passport responsibility to the economic operator placing the battery on the EU market. But the underlying data is contributed by multiple parties. Contracts and API governance between supply-chain partners must specify who can write which attributes and under what audit conditions.
Schema versioning. The DPP schema will evolve as delegated acts are adopted. A passport service that hard-codes the current schema will break when the schema changes. Building schema versioning into the integration layer from day one is not optional.
Architecture: Connecting PLM, ERP, and the DPP Registry
A battery passport implementation has three logical layers: the enterprise data layer (PLM, ERP, MES), an integration and passport service layer, and the EU registry layer. Figure 3 shows a reference architecture.
Figure 3 — Reference architecture. An integration bus federates data from PLM, ERP, and MES into a passport service that validates, signs, and publishes JSON-LD payloads to the EU DPP registry. The registry exposes a QR/RFID resolver to regulators, recyclers, and consumers. An audit log captures every write event for compliance traceability.
Enterprise Data Layer
PLM is the system of record for composition, materials, specifications, and end-of-life documentation. The PLM BOM must be extended with battery-passport-specific attributes — a configuration that is feasible in all major platforms but requires deliberate setup. For a comparison of how Aras, Teamcenter, and Windchill handle extensible attribute models, see Aras vs Teamcenter vs Windchill: PLM Comparison 2026.
ERP carries procurement records, supplier declarations, carbon footprint inputs, and batch genealogy. Connecting ERP to the passport service is primarily an API integration challenge — most modern ERP platforms expose REST APIs, but the data models for sustainability and due-diligence data vary widely and may require custom extensions.
MES provides manufacturing test results (capacity, internal resistance, cycle performance at end-of-line) and batch-to-cell serialisation. This data is typically available via MES APIs or historian exports, but it is rarely modelled as product data — it lives in production databases scoped by manufacturing order, not by product lifecycle. Mapping MES test records to PLM serial number records is a non-trivial integration project.
Integration and Passport Service Layer
The passport service is the critical new component. It is responsible for:
- Data assembly: pulling attributes from PLM, ERP, and MES via APIs and assembling them into a complete passport record
- Validation: checking completeness and range validity against the passport schema before submission
- Schema mapping: translating internal data models to the DPP-mandated schema (ECLASS classifications, IEC 62474 substance declarations, and the emerging EU DPP ontology)
- Signing: cryptographically signing the payload so the registry can verify data provenance
- Versioning: managing passport record updates (e.g., when SoH data is added for a battery entering the secondary market)
- Audit logging: recording every create, update, and read event with timestamps and actor identity for compliance traceability
This service does not exist as a commercial off-the-shelf product today (mid-2026), though several PLM vendors and system integrators are building it. Teams that cannot wait for vendor solutions should build a thin service layer using open standards: JSON-LD for the payload format, OAuth 2.0 for API authentication with the registry, and a message queue (Kafka or similar) for asynchronous data aggregation from source systems.
EU Registry Layer
The EU has not yet designated a single centralised DPP registry operator as of mid-2026. The European Blockchain Services Infrastructure (EBSI) has been explored as a decentralised option; notified bodies under the conformity assessment framework are expected to play a role. The most likely architecture is a federated model where multiple accredited registry operators interoperate via standardised APIs.
This uncertainty has a practical implication: your passport service must be registry-agnostic. Design the submission interface as a pluggable adapter, not a hard-coded integration to any single registry endpoint. The internal data model and validation logic should be stable even as the external registry API evolves.
For broader context on how IoT and digital twin systems connect to PLM in architectures like this, see IoT Digital Twin PLM: Complete Overview.
Trade-offs and What Goes Wrong
Data Ownership and Supplier Resistance
The most common failure mode in battery passport implementations is not technical — it is organisational. Tier-1 suppliers resist disclosing mine-of-origin data because it reveals their sourcing strategies to competitors. Cell manufacturers are reluctant to share detailed composition data that they consider proprietary. The regulation requires this data to be accessible to economic operators and regulators, but it also allows confidentiality protections for commercially sensitive information (Article 10 of the regulation provides nuanced rules on this).
The practical answer is a data sharing agreement architecture: suppliers provide structured data to your passport service under NDA, the service assembles the passport record with appropriate access controls (some attributes public, some restricted to regulators and recyclers, some hidden from consumers), and the registry enforces those access tiers. Designing this access-control model requires legal input, not just engineering input.
Supplier Data Quality
GBA’s pilot experience showed that supplier-provided CF and composition data is frequently incomplete, inconsistently formatted, and unverified. Building a passport on top of low-quality supplier data creates compliance risk — a passport that contains inaccurate information is worse than no passport, because it creates legal liability.
Invest in data quality at ingestion: require suppliers to submit data in structured formats (CSV templates, API push, or EDI with schema validation), run automated completeness and plausibility checks on receipt, and flag outliers for human review before they enter the PLM record. This is a procurement process change, not just an IT change.
Identifier Fragmentation
The regulation references unique battery identifiers but the delegated act specifying the exact identifier scheme was not yet adopted as of mid-2026. GS1 EPCIS, ISO/IEC 15459, and EU-specific identifier schemes are all candidates. Designing a passport service around a single identifier scheme before the delegated act is finalised creates rework risk.
The safe design choice is an identifier abstraction layer: your internal systems use internal serial numbers; the passport service maps them to whatever external identifier scheme the regulation ultimately mandates. This mapping table is cheap to maintain and far cheaper than re-instrumenting your serialisation process after the delegated act is published.
Decentralised Registry Uncertainty
As noted above, the EU registry architecture is unsettled. Betting on EBSI, a single commercial registry, or any specific API specification before the conformity assessment framework is finalised introduces integration risk. The appropriate hedge is to treat the registry as an external dependency with a published interface contract, build against a mock registry for development and testing, and plan a registry switchover sprint when the official specification is published.
Practical Recommendations: What to Build Now
The February 2027 target date for EV battery passports gives engineering and PLM teams approximately 20 months from mid-2026. That is not a long runway for the scope of change required. Here is a prioritised build list.
Q3 2026 — Foundation
- [ ] Audit your PLM BOM for battery-passport attribute gaps. Map the six data clusters to current data fields and identify missing attributes. This audit typically takes 4–6 weeks for a complex battery product.
- [ ] Identify which ERP modules and MES systems hold CF inputs, procurement declarations, and performance test data. Map data owners and API availability.
- [ ] Begin supplier engagement for due-diligence and composition data. Issue structured data templates to Tier-1 suppliers and request sample submissions.
- [ ] Evaluate PLM vendor roadmaps for battery passport support. As of mid-2026, Siemens Teamcenter, PTC Windcroft, and Aras Innovator all have announced or are developing DPP connectors — assess maturity and timeline.
Q4 2026 — Integration Design
- [ ] Design the passport service architecture. Choose between a PLM-vendor-provided service, a system-integrator-built custom service, or an emerging third-party passport platform. Define the JSON-LD schema mapping.
- [ ] Implement identifier abstraction. Establish the mapping between internal serial numbers and the candidate external battery identifier schemes.
- [ ] Implement CF calculation integration. Connect ERP procurement data and manufacturing energy data to a CF aggregation service linked to the PLM BOM.
- [ ] Stand up a mock DPP registry for development and testing. Build your submission adapter against the mock registry.
Q1–Q2 2027 — Compliance Readiness
- [ ] Complete passport service integration with PLM, ERP, and MES source systems. Run end-to-end tests with real product data for a pilot battery product.
- [ ] Implement access-control tiers in the passport record (public, restricted, confidential).
- [ ] Engage a notified body or conformity assessment partner. Understand their submission requirements before the delegated acts are finalised.
- [ ] Run a compliance readiness audit against the final delegated act specifications once published.
- [ ] Implement
restamp/ record-update workflows for batteries entering the secondary market (SoH update obligation).
Architecture principle to enforce throughout: treat the battery passport as a live product record, not a compliance document. It will be read by regulators, recyclers, second-life operators, and future EU data-space participants. Design for queryability, updateability, and auditability from the start.
FAQ
Q: Which batteries require a passport under EU Regulation 2023/1542?
The passport obligation applies to LMT batteries (e.g., e-bike, e-scooter), industrial batteries with a capacity above 2 kWh, and electric vehicle batteries. Portable batteries (below the 2 kWh threshold for industrial/EV) have separate but lighter labelling obligations. The phased application schedule in Article 89 of the regulation specifies the exact timelines; the EV battery passport requirement is targeted at approximately February 2027, with some obligations applying earlier. Always verify against the current regulation text and any delegated acts adopted after this article’s publication.
Q: Can existing PLM systems handle the battery passport data model without modification?
Not without extension. All major PLM platforms (Teamcenter, Windchill, Aras, Arena, and others) are extensible and can store additional attributes. However, the battery passport requires several capabilities most PLM systems do not provide out of the box: serialised unit-level records (not just part-revision records), live updateability (for SoH data), external registry publication via API, and cryptographic signing of published records. Expect configuration and integration work regardless of platform.
Q: What is the relationship between the battery passport and the broader Digital Product Passport (DPP)?
The battery passport is the first product-specific implementation of the DPP concept established under the EU Ecodesign for Sustainable Products Regulation (ESPR). The DPP framework defines common principles — unique identifiers, machine-readable records, controlled access, lifecycle coverage — that apply across product categories (textiles, electronics, and others will follow). Engineering teams building a battery passport implementation are effectively building a reusable DPP infrastructure capability that will be needed again as ESPR-based passports roll out for other product categories.
Q: Who is legally responsible for the accuracy of the battery passport data?
The regulation places responsibility on the economic operator placing the battery on the EU market. For an EV OEM, that is typically the OEM itself. For a battery cell imported and resold, it may be the importer or the EU-based distributor. Responsibility for the accuracy of contributed data (e.g., a supplier’s composition declaration) involves contract law between the manufacturer and the supplier, but the manufacturer bears the compliance risk with regulators. Legal review of supplier contracts in light of the passport obligation is strongly advisable before 2027.
Q: How should the passport handle data for batteries that are remanufactured or given a second life?
The regulation requires the passport record to be updatable. For a battery entering a second-life application (e.g., grid storage after EV use), the record must be updated with current SoH data and the new application context. The economic operator responsible for placing the repurposed battery on the market is responsible for the update. This is one reason the passport service must be designed as a live, mutable record system rather than a static document — and why access-control and audit-log infrastructure matters from day one.
Q: What data standards should the passport payload conform to?
The regulation mandates use of open, interoperable standards. Emerging consensus as of mid-2026 points to JSON-LD for payload encoding, ECLASS as the product classification reference, IEC 62474 for material declarations, and GS1 EPCIS for supply-chain event traceability. The delegated acts will specify mandatory standards; until they are published, design for adaptability rather than locking to any single standard.
Further Reading
- EU Regulation 2023/1542 on batteries and waste batteries (full text): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1542
- European Commission — Digital Product Passport initiative under ESPR: https://ec.europa.eu/commission/presscorner/detail/en/ip_22_2013
- Global Battery Alliance — Battery Passport: https://www.globalbattery.org/battery-passport/
- OECD Due Diligence Guidance for Responsible Mineral Supply Chains: https://www.oecd.org/en/publications/oecd-due-diligence-guidance-for-responsible-mineral-supply-chains_9789264185050-en.html
- Digital Thread PLM Architecture and Implementation 2026 — iotdigitaltwinplm.com
- Aras vs Teamcenter vs Windchill: PLM Comparison 2026 — iotdigitaltwinplm.com
Riju is a product data and PLM architect writing about industrial IoT, digital twins, and lifecycle data management at iotdigitaltwinplm.com.
