Why an architecture question matters now
Digital Product Passports are being introduced in Europe through sector-specific legislation. That can make every product group look like it needs its own data model, carrier and integration stack. ISO/IEC JTC 5 starts exactly at the boundary between those sector solutions. The joint technical committee was created in 2026 to develop foundations for cross-sector and cross-system DPP interoperability. Its first listed meeting is scheduled for 7–9 September 2026 in Berlin. ISO/IEC JTC 5 defines its scope as the framework for the DPP system and ecosystem, while leaving sector-specific standards to the relevant technical committees.
This is neither a new legal obligation nor a published ISO standard. It is, however, a sound reason to separate a company’s durable architecture from short-lived field requirements. The first work item, ISO/AWI 25534-1, remains at project stage 10.99 and was approved as a new project on 12 February 2026. Its public description covers terminology, fundamental principles, data categories, and governance and trust mechanisms. ISO’s project page explicitly says that it is under development. Treating it today as a certification requirement or a completed exchange format would be premature.
Distinguishing the international framework from EU requirements
The EU already provides concrete direction. The Commission explains that DPP information follows a decentralised model: complete data is kept by the economic operator or a DPP service provider, while the Registry records unique identifiers and required registration data. A data carrier such as a QR code connects the physical product with its passport. The Commission’s DPP page also describes role-based access and sectoral timelines.
European harmonised standards are a separate layer. Commission Implementing Decision (EU) 2026/1736 of 14 July 2026 refers to six DPP standards covering, among other matters, identifiers, interoperability, data carriers, APIs, data exchange and storage. For the requirements they cover, conformity can support the presumption of conformity under Articles 10 and 11 of the ESPR.
JTC 5 does not replace either layer. It works above them: a sector-neutral framework can clarify how terminology, data categories, governance and trust should relate across systems. Manufacturers should therefore not postpone battery, textile or steel work in anticipation of a future ISO publication. They should, however, avoid fixing today’s sector fields into the immutable core of an enterprise DPP model.
Three design choices worth making today
1. Separate stable identity from domain profiles
A passport needs a durable technical identity: product, variant, batch or individual item; responsible economic operator; and resolution from a data carrier. Applicable law then determines which domain information is required. That information belongs in versioned profiles. A battery module for carbon-footprint or state-of-health data is not a universal base schema. Nor should materials, repair or recycling information be reduced to unstructured text in a generic passport.
In practice, keep a stable core ID, a documented profile identifier and a profile version together. Every rendered passport should make clear which profile and version govern its content. Teams can then adopt a legal act, industry rule or later standard without rewriting historic data or URLs.
2. Model provenance separately from access
Interoperability is more than a JSON shape. A recipient needs to assess origin, validity and the role behind a piece of information. For each data element or package, retain at least its source, scope, collection date, responsible party and domain version. An internal quality score is not the same as a legal declaration of conformity; a supplier assertion is not the same as a measurement.
Access is the second half. The Commission describes different information access for consumers, repairers, recyclers and public authorities. That calls for a deliberate separation between a public passport, authorised professional access and an internal workspace. A URL must not become an authorisation mechanism. Roles, mandates, data categories and auditable decisions need server-side enforcement.
3. Test exchange boundaries as contracts
A DPP system has several boundaries: ERP or PLM supplies master data, suppliers provide evidence, a service provider hosts data, a registry receives metadata, and external users consume a public or protected view. Each boundary needs a machine-readable contract covering allowed fields, identifiers, semantics, failure modes, versioning and backwards compatibility.
This can be tested now. Useful cases include an unknown profile version, expired evidence, missing provenance, an unauthorised role, duplicate registration and a carrier that resolves to an unavailable passport. Such tests do not prove conformity with a future ISO standard. They do create the traceability that is otherwise missing when a later change finds data models and access rules entangled.
A 90-day plan without speculation
During the next 30 days, build an inventory: which product identifiers exist, which data profiles are actually used, and which information exists only in documents? Next, make an architecture decision covering the core model, profile registry, provenance model and access matrix. Then move one real product through every boundary — from its source system to the passport and on to a repairer or authority role.
The limits matter. ISO/AWI 25534-1 is not a completed standard; no published clauses are available for implementation. The Commission’s timeline is also indicative and does not substitute for checking the applicable legal act for a product group. The value of monitoring JTC 5 is not a premature compliance tick. It is an architecture that can absorb new profiles, roles and exchange rules cleanly.
