The new passport is a data contract, not another PDF
Regulation (EU) 2026/1738, published in the Official Journal on 24 July 2026, gives the vehicle industry its own digital-passport trigger: the Digital Circularity Vehicle Passport. Article 13 requires one for every vehicle placed on the market from 1 September 2032. It is neither a renamed battery passport nor a product page behind a QR code. It is intended to make a vehicle's circularity information structured, free to access and interoperable with other relevant passports.
Manufacturers, suppliers, dismantlers and software teams therefore do not start in 2032. They start with an architecture decision: which information belongs to a vehicle type, which belongs to one vehicle or component, who may change it, and how can the same fact be prevented from appearing inconsistently in several passports?
What Article 13 actually requires
The vehicle passport must be accessible free of charge. The manufacturer placing the vehicle on the market is responsible for information being accurate, complete and up to date. Article 13 refers, among other things, to Article 11 information, declared derogation information for lead, mercury, cadmium and hexavalent chromium, recycled-content declarations for plastics and Article 10(1) materials, and the official spare-parts catalogue for the relevant vehicle type.
Its most important design instruction concerns the boundary between passports. Information that is already available through another passport required by Union law must not be duplicated in the vehicle passport if interoperability is ensured. The Regulation explicitly points to alignment with battery, tyre and other relevant passports. That does not prevent duplication by itself: copied battery chemistry in a vehicle record can become stale while the authoritative battery record has been updated. A traceable reference with source, version, validity and defined resolution is safer.
Separate four data layers
A durable implementation separates at least four layers.
1. Vehicle type and variant
The official spare-parts catalogue, design-level material information and many recycled-content declarations relate to a type or variant. Those facts should not be copied to every vehicle identification number. They need a version, an effective period and evidence of origin, for example from a bill of materials or an approved catalogue.
2. Individual vehicle
An individual vehicle needs a unique identity, a link to its variant and a time-traceable status. This does not mean publishing broad operational data. The public view must not inadvertently disclose safety-sensitive, personal or commercially sensitive data.
3. Component and external passport
A traction battery, tyre or later regulated component may have its own authoritative source. Rather than mirroring content, the vehicle record should keep a reference with a verification state: which source is authoritative, what population does it cover, when was it last read, and what happens when it is unavailable? The same approach fits GS1 Digital Link and resolvers: one stable entry point can connect multiple specialist destinations without taking ownership of their data.
4. Evidence and change event
“Up to date” is not a free-text claim. Each relevant value should expose its source, responsible role, timestamp, version and reason for change. Corrections and spare-part updates also need to say whether a fact was added, replaced or invalidated. That makes it possible to understand why a value was shown at a particular time.
Open standards mean verifiable portability
Article 13(5) requires open standards, interoperable formats, an open interoperable data-exchange network without vendor lock-in, and machine-readable, structured and searchable information. It does not itself prescribe one JSON schema. It does, however, create a clear procurement and architecture test.
An export that is only a designed web page or an unversioned PDF is not demonstrably machine-readable. An API that can only be interpreted by its original supplier is similarly weak. Useful foundations are versioned data schemas, stable identifiers, documented fields, traceable permissions and test data for import, export and update.
For QR access, the carrier should resolve durably but does not need to carry every fact. A short stable URL with server-side permissions and version logic is more robust than a changing file link. The DPP QR-code guide helps with print and resolver fundamentals; vehicle-passport rules will become more specific only through later acts.
What remains open — and why it matters
By 14 August 2030, the Commission must adopt implementing acts on technical design and operation. They include the access solution and data carrier, storage and processing, third-party updates, access conditions including data and intellectual-property protection, and availability when the responsible manufacturer ceases activity in the Union. Teams should not turn these open points into assumptions or compliance claims.
The practical interim approach is a profile that separates requirements from assumptions. Data provenance, versioning, roles, public and restricted views, and references to external passports can be designed now. Later, the profile must be checked against the Commission rules. Documenting that boundary avoids an expensive migration from a seemingly finished but incorrectly scoped model.
An implementation plan to 2032
- Create a data inventory: map spare-parts catalogues, material data, substance derogations, recycled-content evidence and existing battery or tyre references.
- Assign data authority: name exactly one authoritative source and accountable role for every fact.
- Model type, vehicle and component: do not copy type facts to vehicles and do not publish operational data by default.
- Make changes evidential: store version, source, time, validity and correction reason.
- Test access: deliberately separate public information from workshop, authority and protected views.
- Simulate interoperability: reference an external battery passport or component record, then test outage, version change and duplicate-data handling.
The Digital Circularity Vehicle Passport is therefore primarily an integration problem. Product data, spare parts, material evidence and later sectoral passports must complement one another without overwriting one another. Starting now with identities, sources and versions does not promise compliance in advance. It does provide a sound basis for the rules that will still arrive by 2030.
