Why a One-Time Entry Isn't Enough
A Digital Product Passport (DPP) is not a static PDF that gets created once and then filed away. The Battery Regulation (EU) 2023/1542 explicitly requires that certain data points remain updatable throughout the entire lifecycle of a battery. If you fill in your passport when placing the product on the market and never touch it again, you are not fully meeting these requirements — and you risk serious compliance problems starting February 18, 2027.
That may sound straightforward, but it isn't. The Minespider Implementation Report 2026 identifies two structural weaknesses that cut across the entire industry: data fragmentation along the supply chain and the absence of processes for dynamic data updates. Together, these make it difficult to keep a DPP consistent during day-to-day operations.
This article explains which data must change and when, what the technical infrastructure for updates looks like, and which organizational processes manufacturers and operators should be building right now.
What Changes — and When
Static vs. Dynamic Data Points
Not all fields in a DPP are equally volatile. Two broad categories can be distinguished:
Static data is established when the product is placed on the market and generally does not change afterward:
- Material composition and hazardous substances
- Manufacturer identification and production location
- Certifications at the time of market launch
Dynamic data, on the other hand, evolves with the product's life:
- State of Health (SoH) and State of Charge (SoC) for batteries — both values change with every charge and discharge cycle
- Repair and maintenance history
- Changes of ownership and location data
- Results of refurbishment inspections at the end of first life
For batteries that go on to a second life as stationary storage after their use in an electric vehicle, up-to-date condition data is not only a regulatory requirement but also economically significant: an operator of a secondary storage system needs to know exactly how much remaining capacity they are actually purchasing.
Triggers for Mandatory Updates
The regulation does not specify exact update intervals, but it does define events that trigger an update:
- Completion of a maintenance or repair job
- Transition to a new phase of use (first life → second life)
- Change of owner or operator
- New readings from BMS (Battery Management System) systems
- Recall or safety notice
If you haven't embedded these events into your internal processes, they will get overlooked in the course of daily operations.
The Technical Architecture for DPP Updates
GS1 Digital Link as a Stable Anchor
The link between a physical battery and its digital passport is established via a GS1 Digital Link — a standardized URI that encodes the GTIN and serial number and points to the associated record. The key point: the link on the product (e.g., printed as a QR code) remains unchanged. Only the record it points to gets updated.
A typical GS1 Digital Link for a battery looks like this:
https://id.example.com/01/04012345678901/21/ABC-0042
01= GTIN qualifier04012345678901= battery GTIN21= serial number qualifierABC-0042= individual serial number
The resolver behind this URL redirects to the current DPP record. When the record changes, the QR code on the product stays the same — only the target in the backend is updated. This is the conceptual core of dynamic data maintenance.
API-Based Updates: The Basic Principle
Modern DPP platforms provide REST APIs that allow specific data points to be updated without rewriting the entire passport. A typical PATCH request against a DPP API might look like this:
PATCH /dpp/v1/batteries/04012345678901/21/ABC-0042
Content-Type: application/json
Authorization: Bearer <token>
{
"stateOfHealth": 0.83,
"lastMeasuredAt": "2026-06-20T14:32:00Z",
"measuredBy": "operator:fleet-mgmt-system-v2"
}
The advantage over a full PUT: only the changed fields are transmitted, versioning remains traceable, and the audit log doesn't grow unnecessarily.
Versioning and Audit Trail
The EN standards 18216 through 18223, which CEN and CENELEC presented at a public webinar on June 25, 2026, define requirements for data consistency and interoperability. This implicitly includes the traceability of changes: who changed which value, when, and on what basis?
A minimal versioning strategy should store the following fields for each update event:
{
"version": "3",
"updatedAt": "2026-06-20T14:32:00Z",
"updatedBy": "system:bms-connector",
"changedFields": ["stateOfHealth", "lastMeasuredAt"],
"previousValues": {
"stateOfHealth": 0.87
}
}
Without this trail, you cannot prove in a dispute that the data was correct at the relevant point in time.
Organizational Processes: What Companies Need to Build Now
Clarify Data Ownership
The biggest practical challenge is not technical. It's the question of who in the organization is responsible for which data points — and who initiates an update when one is needed.
A simple RACI matrix is recommended, capturing for each dynamic data point:
- Responsible: Who carries out the update?
- Accountable: Who is answerable to the regulatory authority?
- Consulted: Who supplies the measurement data?
- Informed: Who needs to be notified of changes?
Bring the Supply Chain On Board
Many dynamic data points are not generated by the manufacturer but by suppliers, maintenance shops, or fleet managers. The manufacturer, however, remains regulatorily responsible for the accuracy of the passport. This requires clear contractual arrangements and technical interfaces through which third parties can contribute data — with defined formats and validation rules.
The BatteryPass-Ready consortium, which launched a public test environment on June 24, 2026, offers a neutral validation platform for exactly this purpose: companies can test their DPP solutions against regulatory requirements before going live in production.
Keep an Eye on the Central Registry
The European Commission is working on a central registry through which all DPPs will be registered and made discoverable. Orgalim — the European industry association for technology — has published clear recommendations on this: the registry must support high-volume, automated registration processes and be resilient against outages.
For companies, this means your update processes must not only work against your own platform but must also be capable of synchronizing with the central EU registry down the line. If you lock yourself into proprietary siloed solutions now, you're building migration work for later.
Practical Checklist for the Update Process
Before the first DPP goes into production, the following points should be addressed:
- Data points classified: Which fields are static, which are dynamic?
- Triggers defined: Which events require a mandatory update?
- API access governed: Who is allowed to change which fields through which interface?
- Audit trail implemented: Every change is stored with a timestamp, author, and previous value.
- Supply chain interfaces tested: External data suppliers can submit valid updates.
- Registry compatibility verified: Your system can communicate with the future EU registry.
- Test environment used: The BatteryPass-Ready test platform or equivalent environments have been used for interoperability testing.
Conclusion
The DPP is not a document — it's a living dataset. The regulatory requirements of the Battery Regulation (EU) 2023/1542 are unambiguous on this point: dynamic data points must be kept current throughout the entire product lifecycle. If you don't build the technical and organizational infrastructure for this in time, you will not be compliant by the February 18, 2027 deadline.
The good news: the building blocks are already there. GS1 Digital Link solves the identification problem, REST APIs enable granular updates, and initiatives like BatteryPass-Ready provide test infrastructure. What many companies still lack are the internal processes and a clear assignment of data ownership — and that is exactly where the work should begin.
