How Do You Prepare a Battery Passport for February 2027 While Implementation Rules Are Still Moving?

The legal start date is fixed, but not every implementation dependency is. This is a dated readiness guide for battery manufacturers, importers and product/data teams deciding what to implement now, what to test and what to keep configurable.

Start with what is already fixed

Regulation (EU) 2023/1542 sets the controlling battery-passport obligation.

From 18 February 2027, a battery passport is required for each:

• electric-vehicle battery
• light means of transport battery
• industrial battery with a capacity greater than 2 kWh

placed on the market or put into service within the Regulation's scope.

The existing Battery Digital Product Passport requirements page owns the detailed legal scope. For readiness planning, the important point is simpler: the deadline and core category scope are not waiting for a future BatteryPass-Ready release.

The law also establishes durable design requirements around accurate, complete and up-to-date information, differentiated access, interoperability and lifecycle continuity.

Those are safe foundations for implementation work now.

What changed during 2026

The implementation environment became much more concrete during July and August 2026.

The table is deliberately date-stamped. It describes the implementation state on 6 September 2026, not a permanent legal taxonomy.

The implementation stack has four different authorities

The easiest way to make a battery-passport programme brittle is to treat every document as if it has the same authority.

1. Regulation and adopted Commission acts

The Batteries Regulation and applicable adopted implementing or delegated acts control the legal obligation.

The Registry implementing regulation belongs in this layer.

2. Cited technical standards

The six DPP standards cited in July 2026 provide concrete technical support across areas including data exchange, unique identifiers, data carriers, storage, APIs/lifecycle/searchability and interoperability.

A standard can define how a technical capability works. It does not replace the product-specific legal requirement.

3. Commission guidance

The Commission's August 2026 battery guidance organises the current 71-point view by battery category and applicability.

The Commission states that the guidance is non-binding and does not create additional legal requirements.

For the detailed distinction between the legal source and the 71-point guidance, use which Battery Passport data points are actually required.

4. Programme models and test resources

BatteryPass-Ready's Data Attribute Longlist v2.0, Data Model v2.0, user stories and test environment turn parts of the regulation, guidance and standards landscape into implementable models and scenarios.

That makes them useful.

It does not make them law. BatteryPass-Ready itself says the longlist and data model will be updated as relevant regulatory, standardisation and technical developments continue.

What you can implement now

The safest sequence is to build around the parts that are already durable.

Establish battery and passport identity

Define the battery identifiers, the relationship between model-level and individual-battery records and the identifiers required for Registry interaction.

Do not make the QR carrier itself your source of truth. The carrier points into an identity and data architecture.

Govern the data before publishing it

For each material field or information territory, know:

• which battery or model it applies to
• which system owns the value
• the legal or implementation basis
• source evidence and provenance
• whether it changes over the battery lifecycle
• whether it is public, restricted or still dependent on a pending access rule.

The public passport is an output of that governed data, not the only place the data exists.

Implement Registry integration

The EU DPP Registry is operational. Teams can work against the Registry layer now rather than treating it as a future concept.

The existing Registry test environment guide owns the detail of how Registry testing works.

Implement version and lifecycle handling

Battery passports have to survive change.

Your data model should be able to distinguish current values from historical values and handle battery lifecycle transitions without rewriting history. Where reuse, repurposing or remanufacturing changes the legal passport responsibility, keep the detailed rule with the battery second-life owner.

Keep evidence with the value

For important facts, retain the source, responsible owner, effective date, last update and relevant evidence.

That turns later regulatory or standards changes into controlled changes rather than archaeology.

What should stay configurable

Some implementation uncertainty is real. The answer is not to leave the whole programme undefined.

Isolate the parts most likely to move.

Access and authorisation policy

The Regulation establishes differentiated access, but the Commission still shows the battery access-rights implementing act for Q4 2026.

So keep:

• actor and role mapping
• legitimate-interest qualification
• field-to-role permission rules
• credential or authentication mappings
• policy conditions

configurable rather than embedding them irreversibly into application logic.

For the current legal status, see which Battery Passport data is public, restricted or legitimate-interest controlled.

Dependency-sensitive schema validation

BatteryPass-Ready v2 is a sensible current implementation reference, but it is explicitly versioned and expected to change.

Use versioned schemas and validation rules. Record which release a test used. Avoid presenting the programme model as the immutable EU legal schema.

Standards-dependent interfaces

Where a remaining standard or Commission act may change an interface requirement, isolate the dependency and make the implementation replaceable.

That is change control, not an excuse to avoid implementation.

The two test environments test different things

Battery teams may now encounter two different testing surfaces. They are useful for different reasons.

BatteryPass-Ready describes 11 scenarios across three use cases in its current test environment.

That makes the programme useful for finding gaps before production. Passing those scenarios should be treated as evidence that a tested implementation behaved as expected against that test version, not as a certificate that every legal obligation has been satisfied.

Use the user stories as test hypotheses

BatteryPass-Ready's Technical User Stories v1.0 translate requirements and technical dependencies into workflows around onboarding, passport creation, reading, updating and lifecycle events.

They are especially useful for asking practical questions:

• Who initiates the action?
• Which identifier is needed?
• Which system responds?
• What happens when permission is missing?
• What happens when a value changes?
• Which lifecycle event should create or update a record?

But the user stories are non-exhaustive and depend on areas where secondary acts or standards were still pending when they were written.

So use them as test hypotheses and process models, not as substitutes for the Regulation or later adopted acts.

Evidence to retain from readiness testing

A readiness test is much more valuable when you can prove what you actually tested.

For each material test run, keep:

• test environment and version
• schema/model version
• test scenario or user story
• date
• product/battery test identity
• input dataset
• expected result
• actual result
• failed validation or access conditions
• corrective action
• evidence of the retest
• any assumption tied to a pending act or standard.

This creates a change trail. When the access-rights act or a standards dependency changes, you can identify which controls need retesting instead of rerunning the entire programme blindly.

A practical readiness sequence

If you are working towards 18 February 2027, the sequence is:

1. Confirm whether each battery product is in scope.
2. Map the governed data and evidence you already hold.
3. Separate model-level from individual-battery and lifecycle data.
4. Establish stable identity and Registry integration.
5. Implement versioning, update rights and evidence provenance.
6. Classify access at a policy level without inventing the unresolved legal detail.
7. Test against the current Registry and BatteryPass-Ready surfaces.
8. Record versions, assumptions, failures and retest evidence.
9. Watch the remaining Commission acts and standards.
10. Change the isolated policy/schema components when the authoritative position changes.

The useful distinction is stable core versus configurable edge. That gives the team something real to implement now without pretending the moving parts have stopped moving.

Dated watchlist

As of 6 September 2026:

• NOW: 18 February 2027 battery-passport start date for the covered categories.
• NOW: EU DPP Registry operational.
• NOW: six DPP standards cited in the Official Journal.
• NOW: Commission battery guidance available as non-binding guidance.
• NOW: BatteryPass-Ready v2 longlist/data model and current test resources available as implementation aids.
• EMERGING: battery access-rights implementing act, still shown by the Commission for Q4 2026.
• EMERGING: decisions on two remaining DPP standards, still shown on the Commission's September 2026 timetable.
• EMERGING: later BatteryPass-Ready updates that incorporate those dependencies.

What would change this page

This page requires review when any of the following happens:

• the Commission publishes the battery access-rights implementing act
• the remaining DPP standards receive a new formal status
• BatteryPass-Ready releases a material new longlist, data model, user-story or test-environment version
• the page reaches or passes 18 February 2027.

On or after 18 February 2027, this temporal readiness page should receive a lifecycle decision. Its durable material should either remain useful as implementation guidance or be moved into the stronger long-term battery owner rather than being left as a pre-deadline page indefinitely.

Sources

• Regulation (EU) 2023/1542 concerning batteries and waste batteries, EUR-Lex
• European Commission Digital Product Passport implementation page
  European Commission
• European Commission guidance to support preparations for the Digital Batteries Passport
  European Commission
• Commission Implementing Decision (EU) 2026/1736 on DPP standards
  Delegated act
• Commission Implementing Regulation (EU) 2026/1778 establishing the DPP Registry
  Delegated act
• BatteryPass-Ready Data Attribute Longlist v2.0 and Data Model v2.0 release
• BatteryPass-Ready test environment launch
• BatteryPass-Ready resources and Technical User Stories