Choosing a battery passport that works for energy storage

Choosing a battery passport for stationary storage is not the same exercise as choosing one for electric vehicles. The data is different, the asset life is different, and the people who need to use the passport are different. For energy storage, the right approach is the one that can follow a battery from cell and module build, through system integration, commissioning, operation, maintenance, augmentation, repowering, and finally dismantling or recycling, without breaking the chain of evidence.

A battery passport for energy storage systems needs to do more than satisfy a future compliance check. It needs to support day to day asset management, warranty decisions, service records, safety documentation, and end of life handling across projects that may run for well over a decade. That is why the best choice is usually not the provider with the broadest marketing claim, but the one that can handle identity, interoperability, governance, and operational change at site level.

For stationary storage, the starting point is clear asset identity. We need to know what the passport is identifying, and at what level. In practice that usually means several linked identities, not one. Cell, module, rack, container or enclosure, power conversion system, and the installed site asset may all need their own records. If a module is replaced during service, or a site is augmented with additional capacity, the passport structure has to preserve that lineage.

The core data should cover at least five areas.

First, product and technical composition data. This includes manufacturer details, model references, serial numbers, chemistry, rated energy and power, bill of materials at the level required for compliance and service, hazardous substance information, and where relevant the declarations and conformity documents attached to the product family. If you are still organising this stage, our guide on mapping a battery bill of materials for passport readiness is the practical place to start.

Second, manufacturing and provenance data. For many operators, this is where the passport moves from a static file set to a real control tool. We need to know which factory, batch, lot, or production run a unit came from, and how that links to test results, quality release records, and supplier declarations. If upstream material information is in scope, the passport also needs a clear method for linking supplier submissions to the finished battery record without exposing confidential data more widely than necessary.

Third, installation and commissioning data. This is especially important for energy storage because site conditions matter. The passport should record the project location, installation date, commissioning tests, firmware or software version at handover, as-built configuration, safety settings, and the parties responsible for installation and acceptance. A passport that stops at factory gate does not help much when a site owner needs to prove how the system entered service.

Fourth, operational and maintenance data. A useful battery passport for energy storage systems should be able to record inspections, service interventions, fault history, replaced parts, software updates, state of health assessments, and any events that affect warranty or residual value. This is where stationary storage diverges sharply from simple product traceability. The passport becomes a living asset record.

Fifth, end of life and circularity data. We need to know what happens when the system is decommissioned, partially repowered, moved to another site, dismantled for parts, or sent for recycling. That means handover records, waste classification where applicable, chain of custody, recycler details, and evidence of treatment. In the EU, requirements under the Batteries Regulation shape a growing part of this picture. In the UK, the legal framework is not identical, so businesses operating in both markets should avoid assuming that one reporting workflow will cover both without adjustment.

The lifecycle stages that matter are broader than many teams first expect. For stationary systems, we usually map them as design, sourcing, manufacture, logistics, integration, commissioning, operation, maintenance, augmentation, repowering, decommissioning, and recovery. If the passport platform cannot model those stages cleanly, it will become a compliance repository instead of an operational system.

The stakeholder list is just as broad. Manufacturers need controlled product data. Integrators need system structure and configuration management. Developers and EPC contractors need commissioning evidence. Owners and operators need service history and performance context. O and M providers need maintenance access with clear permissions. Recyclers need treatment and composition information. Insurers, lenders, and auditors may need read access to selected evidence. A workable passport has to support role based access, not just a single public record.

Most projects fall into one of four models, or a hybrid of them.

The first is the in-house build. This usually means creating a passport layer using internal databases, ERP, PLM, quality systems, service software, and document management tools. The advantage is control. We can design the data model around our products and sites, keep sensitive information inside our own environment, and connect directly to existing workflows. This suits organisations with strong internal digital teams and established master data governance.

The weakness is implementation depth. Building a credible passport system is not just a matter of storing files and serial numbers. We need persistent identifiers, access controls, audit logs, supplier onboarding, versioning, and a method for external sharing that does not collapse into spreadsheets and email. In-house builds also tend to struggle when a customer, regulator, or recycler expects a standardised external interface.

The second model is the specialist software platform. This is often the fastest route to a structured battery passport for energy storage systems because the passport logic, data model, user permissions, and reporting framework already exist. A good platform should let us connect manufacturing records, technical files, service data, and end of life evidence without forcing every process into a generic form.

This model works well when we need interoperability, implementation support, and a clearer path to regulatory readiness. It is especially useful where multiple business units or external partners need to contribute data. The main risk is choosing a platform that was designed around consumer products or EV use cases and only later adapted to stationary storage. If the structure cannot cope with containerised systems, partial replacements, or site level reconfiguration, the fit will be poor.

The third model is the supply chain led solution. Here, the passport framework is effectively set by a major customer, OEM, cell supplier, or system integrator, and the rest of the chain contributes data into that environment. This can work well where one party has enough influence to standardise submissions and identifiers across the chain. It can also reduce duplication if the same passport record follows the product through several commercial stages.

The drawback is dependency. If the lead party controls access, schema, and change management, everyone else may end up adapting their systems to a process they do not own. This can become difficult when the battery changes hands, enters a second life arrangement, or needs to be serviced by a party outside the original chain.

The fourth model is the document based approach. This is the familiar mix of technical files, declarations, spreadsheets, PDF manuals, inspection reports, and service logs, often organised in a customer portal or shared repository. It can be enough for very small portfolios or early stage pilots, and it may satisfy immediate customer requests where no digital integration is yet required.

But it is rarely enough for long term storage operations. Documents alone do not create a durable identity model, a reliable audit trail, or machine readable interoperability. They are also weak at handling asset changes over time. If a module is replaced, a rack is reconfigured, and the site is augmented three years later, a folder structure quickly becomes unreliable.

For many organisations, the practical answer is a hybrid. Core passport data sits in a specialist platform or structured in-house layer, while supporting evidence remains in linked source systems and controlled document repositories. That often gives the best balance between usability and governance. If you are weighing these routes, our article on how to compare battery passport platforms in the UK is a useful companion, especially for businesses that need to separate UK practice from EU wide assumptions.

The biggest difference is asset structure. An EV battery is usually tied to one vehicle identity and one manufacturer controlled configuration. A stationary storage system is more modular and more likely to change during its life. Containers are opened, modules are swapped, racks are rebalanced, firmware is updated, and additional capacity is added to the same site. The passport has to track all of that without losing the history of what was there before.

The second difference is ownership and responsibility. Vehicle battery records often sit within a relatively clear chain of manufacturer, dealer, owner, and authorised repair network. In energy storage, responsibility is distributed. A project developer may procure the system. An integrator may assemble it. An EPC may install it. An asset owner may finance it. An O and M contractor may maintain it. A specialist service partner may perform diagnostics. A recycler may only appear at the end. The passport must support controlled collaboration across parties who do not share one system.

The third difference is maintenance intensity. Stationary systems are maintained as infrastructure. That means scheduled inspections, thermal and electrical checks, firmware management, incident records, spare parts handling, and warranty evidence all matter more. If service partners cannot update the passport in a controlled way, the record becomes stale. Our guidance on what repair workshops need before battery passports start is relevant here even beyond traditional workshop settings, because the same issue applies to field service teams.

The fourth difference is repowering and augmentation. Energy storage projects are often expanded or refreshed before the original asset reaches formal end of life. New modules may be added to an existing site, or ageing units may be replaced while the balance of plant remains. A passport that assumes one fixed physical object from birth to disposal will not handle this well. We need a model that can record parent child relationships, superseded components, and revised site configurations.

The fifth difference is end of life routing. EV batteries often enter a second life discussion before recycling. Stationary batteries may also be redeployed, but many will instead move through partial dismantling, materials recovery, or project specific decommissioning plans. This creates a stronger need for chain of custody records and treatment evidence at component and site level.

Finally, the operating context is different. Stationary assets are tied to a location, a grid connection, a fire safety strategy, and local permitting conditions. Those factors can affect what data needs to be retained and who needs access to it. A battery passport for energy storage systems should therefore support site context, not just product context.

Most suppliers can say they are aligned with emerging rules. That is not enough. We need to test how their system actually works.

Start with interoperability. Ask what data formats they support for import and export. Can they ingest ERP, MES, PLM, BMS, CMMS, and document repository data without custom work every time? Can we export our records in a structured form if we change provider or if a customer requests direct handover? If the answer is a PDF export, that is not real interoperability.

Then look at data governance. Who owns the data? Where is it hosted? How are permissions managed across manufacturers, integrators, owners, service companies, and recyclers? Can we control field level visibility for commercially sensitive data? For cross border operations, ask directly how the provider handles differences between EU obligations and UK practice, especially where a workflow is marketed as one size fits all.

Auditability is next. Every significant record should show who created it, who changed it, when it changed, and what the previous value was. This matters for warranty disputes, incident investigations, and regulatory assurance. Version control is not optional. Neither is a defensible link between the passport record and the source evidence behind it.

Security needs more than a generic statement about encryption. We should ask about identity and access management, tenant separation, API security, backup and recovery, logging, and incident response. If service partners and recyclers will use the system, supplier onboarding and offboarding controls matter too.

Implementation support is often where good projects fail or succeed. We should ask who maps the data model, who helps connect source systems, who defines the identifier logic, who trains internal teams, and who supports supplier onboarding. A platform may be strong technically and still be the wrong choice if the implementation model assumes we will do all the heavy lifting ourselves.

We also need to test whether the supplier understands battery data itself. Ask them to walk through a real scenario. A module fails in year four, is replaced under warranty, and the removed unit is sent for analysis before recycling. What records are updated, by whom, and how is the chain of custody preserved? If the answer is vague, the implementation will be too.

For teams still defining their baseline, our pieces on what data a battery passport needs and battery passport reporting rules businesses need to meet can help sharpen the supplier brief before procurement starts.

Manufacturers usually need the strongest control over product, process, and provenance data. If we build battery systems or major subassemblies ourselves, a specialist platform or a robust in-house build tends to make most sense. The decision usually depends on whether we already have mature internal systems and integration capability. Where supplier declarations and downstream handover matter, a specialist platform often reaches operational readiness faster.

System integrators need flexibility. We are often combining cells, modules, enclosures, controls, and balance of plant from multiple sources, then handing over to developers, EPCs, or owners. That makes interoperability and configuration management more important than deep factory process capture alone. A specialist platform, or a hybrid model with strong integration to project documentation and commissioning records, is usually the better fit.

Project developers often do not need to own every upstream data process, but they do need confidence that passport obligations and handover requirements are being met before financial close and operation. For them, a supply chain led solution can work if contractual control is strong and the data handover is well defined. If not, they risk receiving incomplete records at commissioning.

Asset owners and operators need a passport that works after handover. Their priority is continuity through operation, maintenance, incident management, augmentation, and end of life. A document set is rarely enough. They benefit most from a structured platform that can connect to service workflows and preserve a reliable history even when contractors change.

Service providers need controlled write access. If we maintain storage assets in the field, we need to update inspection records, replaced parts, software versions, and safety findings without exposing unrelated confidential data. That makes role based access and auditability essential. A passport approach that treats service as an afterthought will create gaps within the first maintenance cycle.

Recyclers and decommissioning partners usually need targeted access rather than full system visibility. They need composition, hazard, dismantling, and chain of custody information in a form they can trust and use. If the chosen model cannot share that information cleanly at the right time, end of life compliance becomes manual and error prone.

For smaller operators with a limited portfolio, a document led approach may be acceptable as a temporary step, but only if the structure is disciplined and there is a clear route into a proper passport system later. For larger fleets, multi party projects, or businesses operating across EU and UK markets, that temporary step tends to become expensive rework.

The right battery passport for energy storage systems is the one that fits the operational life of the asset, not just the first compliance milestone. If we choose a model that can hold technical truth, service history, configuration change, and end of life evidence in one governed structure, we make the passport useful to the people who actually run the asset. That is what turns passport readiness into something commercially durable.