Digital Product Passport vs Digital Twin: Business Value

European manufacturers are investing in Digital Product Passports to comply with new product transparency and sustainability rules. For battery manufacturers the deadline is concrete: from 18 February 2027, LMT batteries, industrial batteries above 2 kWh and electric-vehicle batteries need a battery passport. For many companies the immediate objective is straightforward: collect the required information, generate a compliant passport, connect it to a QR code and make it available to the relevant stakeholders.

But this raises a broader strategic question: if a company already maintains a Digital Product Passport, does it still need a Product Digital Twin? At first glance the two concepts look remarkably similar. Both involve digital information connected to a physical product. Both can include material composition, technical characteristics, manufacturing information and lifecycle data. Both can be accessed by different stakeholders and updated when information changes. Why would an organisation invest in both?

The answer depends on how these technologies are designed and what the company intends to achieve. A Digital Product Passport is primarily a structured information mechanism supporting regulatory requirements, product transparency and circularity. A Product Digital Twin can serve a broader purpose: representing a product and its evolving state throughout its lifecycle, integrating information from multiple business systems and enabling operational processes, collaboration, analysis and digital services.

The difference is not necessarily the data itself. It is how that data is structured, connected, updated, shared and used to generate value. When designed properly, the passport and the digital twin do not compete or duplicate each other: the passport becomes one regulated, purpose-specific view of a more comprehensive digital product representation. That does not mean every business needs a separate, sophisticated digital twin platform. This article explores where a Product Digital Twin adds value, when it may be redundant, and how companies, battery manufacturers in particular, can build an architecture that supports compliance while delivering measurable business benefits.

1. Digital Product Passport and Product Digital Twin: understanding the difference

What is a Digital Product Passport?

Under the EU Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781), the Digital Product Passport provides structured information about products, components and materials. Its purpose is to support product transparency, regulatory compliance, sustainability and circularity. Depending on the applicable legislation, information may include:

Product and manufacturer identification
Technical specifications
Material composition
Environmental performance
Durability and repairability
Conformity documentation
Recycling and end-of-life instructions
Relevant lifecycle information

The information requirements, granularity and access rights are set by the applicable product legislation. Under the ESPR, the delegated acts determine whether the passport applies at model, batch or item level (Art. 9(2)(d)). The EU Battery Regulation, by contrast, requires the battery passport to contain information relating to the battery model and information specific to the individual battery (Regulation (EU) 2023/1542, Art. 77(2)).

Importantly, a DPP is not necessarily a static PDF or web page. It can already be structured, interoperable, updated and connected to external systems.

What is a Product Digital Twin?

The Digital Twin Consortium describes a digital twin as a virtual representation of real-world entities and processes, synchronised at a specified frequency and fidelity (2020 definition, refined in 2024). For a physical product, this can mean a digital representation combining information about:

Product design and specifications
Components and configuration
Manufacturing
Quality and inspection results
Logistics and distribution
Operational condition
Repairs and maintenance
Ownership or custodianship, where appropriate
Lifecycle events
Product retirement and recycling

Unlike a fixed data sheet, a true digital twin reflects relevant changes in the physical product or its business lifecycle. It can support analytics, business workflows and, in more advanced implementations, simulation or predictive models. Continuous IoT connectivity, a 3D model and artificial intelligence are not mandatory characteristics of every useful digital twin, though. A product whose condition is updated after a warehouse inspection or a maintenance event can have a meaningful digital representation without transmitting sensor data every second.

The fundamental difference

Dimension	Digital Product Passport	Product Digital Twin
Primary purpose	Regulatory transparency and specified information access	Operational and business representation of the product
Information scope	Data required or permitted by applicable DPP rules	Any relevant product and lifecycle data
Granularity	Defined by applicable legislation	Selected according to business needs
Data updates	According to legal and operational requirements	According to relevant events and business processes
Main stakeholders	Authorities, consumers, economic operators, repairers and recyclers	Manufacturers, suppliers, logistics, distributors, customers and service partners
Access rights	Governed by DPP legislation	Governed by business rules, contracts and applicable law
Process integration	Possible and sometimes necessary	A central reason for implementation
Commercial services	Not the regulatory objective	Can support value-added product services
Predictive analytics	Not intrinsically required	Possible where useful and supported by data
Geographic scope	EU regulatory framework	Potentially global

The Product Digital Twin can represent the broader operational reality of a product. The DPP exposes the subset of information required by a particular regulatory framework. This is an architectural approach, not a legally mandated relationship between the two concepts, and a well-designed DPP platform may already contain some or all of the digital twin capabilities a company needs.

2. Does a Product Digital Twin require a second platform?

Not necessarily, and in many cases it should not. The worst possible architecture is a DPP database containing regulatory information plus a separate digital twin database holding a copy of the same information without a clear reason. That creates competing versions of the truth, additional integrations and unnecessary maintenance.

A better approach is a shared product-information foundation that connects information from authoritative enterprise systems and presents it according to different requirements:

Existing system	Information contributed
ERP	Product references, orders, commercial and manufacturing master data
PLM	Product design, engineering specifications and component structure
PIM	Commercial descriptions, product media and market information
MES	Manufacturing records, production lots and quality events
WMS	Inventory locations, stock movements and logistics status
QMS	Inspections, defects, non-conformities and corrective actions
CRM	Customer interactions and service-related information
Service management	Repairs, maintenance, spare parts and warranty events
Supplier systems	Materials, certificates and supporting declarations
IoT or BMS platforms	Operational condition and sensor-derived data

The Product Digital Twin does not need to duplicate all these systems. It can provide a consistent product identity, an information model, controlled links to authoritative sources and a relevant history of events. Applications then use this representation for different purposes, and the Digital Product Passport becomes one such application, or regulated information view.

The objective is not to create two independent product databases. It is to make the same governed product information useful for compliance and for the business.

3. The first strategic benefit: preparing for regulatory changes

One of the strongest arguments for a flexible digital twin architecture is that regulatory requirements are not static. The EU DPP framework will evolve: new product categories will become subject to passport requirements, and existing legislation allows certain technical or information requirements to be amended. Companies may need to add attributes, revise calculation methods or provide information at a different level of granularity. A DPP implementation built exclusively around a fixed list of today's attributes can become difficult and expensive to adapt.

Example: a new environmental attribute becomes mandatory

Imagine a furniture manufacturer whose DPP contains product identification, material composition and repair instructions. A future amendment introduces an additional environmental-performance indicator. With a rigid, hard-coded data structure, that may mean changes to databases, integration interfaces, forms and publication logic. A flexible architecture separates the underlying product information from the rules that define which attributes must be disclosed. The company can then:

Add the new attribute to its information model.
Identify the authoritative source.
Collect the data from internal systems or suppliers.
Define the calculation and validation rules.
Set the access permissions.
Include the attribute in the updated regulatory DPP view.

This does not eliminate regulatory analysis or new data collection, but it can reduce the technical restructuring needed.

Flexibility does not create missing data

If a future rule requires a carbon-footprint calculation that has never been performed, a flexible platform cannot invent the evidence. The organisation still needs supplier information, methodologies and verification procedures. A digital twin makes regulatory adaptation easier only when it is backed by a well-designed data model and reliable data governance.

4. From model to batch to individual product: preparing for changing granularity

Granularity is another important consideration. Under the ESPR, the applicable delegated act determines whether DPP data relates to the product model, the batch or the individual item, so companies should not assume that all future DPP requirements will use the same level. And business requirements may already justify a more detailed representation than the legally mandated passport. Consider a hypothetical industrial product.

Level 1 - Product model

All units share certain characteristics, maintained once at model level: model identification, technical specifications, nominal dimensions and weight, general material composition, manuals and operating instructions.

Level 2 - Production batch

A batch carries additional information that applies only to its units: manufacturing date and location, component supplier, material-lot references, production-process characteristics and quality inspection results.

Level 3 - Individual item

Each item may have its own information: serial number, installation date, service history, actual component configuration, product condition, and repair or refurbishment events. The individual record can inherit common model and batch information while keeping its specific attributes.

The Battery Passport: model and individual battery at the same time

Batteries show this layering in regulatory form. Under Art. 77(1) of the Battery Regulation, each LMT battery, each industrial battery with a capacity above 2 kWh and each electric-vehicle battery placed on the market or put into service from 18 February 2027 must have a battery passport. Under Art. 77(2), that passport contains both information on the battery model and information specific to the individual battery. A system that already models the relationship between a battery model, its production batches and each serialised battery can publish the model attributes once and attach the item-specific ones per battery, instead of copying the same data into thousands of separate records.

Why this matters

Suppose a future requirement introduces an additional batch-specific attribute. A system that already understands the relationships between models, batches and items can integrate it without duplicating all the common information. Or a manufacturer starts with a model-level DPP but later needs serial-level information for recalls and warranties: it can introduce more granular tracking in its product digital twin without changing the current regulatory DPP granularity.

One important limitation

An identifier for a product model cannot become an identifier for a specific physical item. If every product carries the same model-level QR code, scanning it cannot tell which individual item is in your hands. An item-level requirement may need additional identification, serialisation, system integration or a different physical data carrier. We looked at this in detail in our article on pre-printed QR code labels for batch and item passports.

A flexible architecture should therefore prepare for future granularity while accounting for the identifiers already applied to physical products. The best approach is to keep separate:

The product's persistent identity
The relationships between model, batch and item
The level of data available
The level legally required in the DPP
The information accessible to each stakeholder

5. One product, multiple regulatory markets

The Digital Product Passport is a European regulatory instrument, but most international manufacturers sell into several markets: the EU, the United Kingdom, the United States, Canada, Japan, Australia and others. Each can impose different requirements on product identification, labelling, safety declarations, chemical substances, warnings, country of origin, energy performance, recycling, languages and market-specific documentation. A European DPP should not automatically be treated as a universal global compliance record.

Example: EU and California

Consider a product sold in the EU and in California. The EU may require specified Digital Product Passport information. In California, Proposition 65 requires businesses to provide a "clear and reasonable" warning before knowingly exposing people to listed chemicals, with exemptions, for example for businesses with fewer than 10 employees or exposures below safe-harbor levels. These are different regulatory mechanisms. A digital twin can associate the product with information relevant to both jurisdictions and support separate compliance workflows, but publishing information on a web page does not automatically replace legally prescribed warnings or other mandatory presentation requirements.

Example: U.S. medical-device identification

The U.S. Food and Drug Administration operates a Unique Device Identification system for medical devices. Labelers submit device identifier information to the Global Unique Device Identification Database (GUDID); only the device identifier portion of the UDI goes there, not production identifiers such as lot or serial numbers. This is not the EU DPP framework, but companies can still benefit from a shared architecture that manages product identity and supports different jurisdiction-specific information processes.

Country-specific views

A global manufacturer can maintain common technical and material information while applying different publication rules per market:

EU view: applicable DPP information, authorised stakeholder access and relevant European conformity documentation.
U.S. view: applicable local warnings, documentation and identification requirements.
Other markets: certifications, safety instructions, language variants or other locally required information.

The advantage is not one universal compliance document. It is one governed product-information foundation supporting several distinct compliance regimes.

6. Better supplier collaboration and B2B information exchange

One of the biggest practical challenges is obtaining reliable information from suppliers. A manufacturer of industrial equipment may source hundreds or thousands of components, and each supplier controls different information about materials, processes, performance and conformity. The DPP may require only part of it; engineering, quality management and procurement often need much more.

A digital twin architecture can connect product and component information through consistent identifiers and relationships. A battery assembler, for example, may need cell specifications, component supplier identifiers, batch-level quality reports, certificates, material declarations, assembly records, technical compatibility data and change notifications. Only some of this needs to appear in the battery passport; the rest is essential for procurement, warranty analysis, quality control and production planning. (For what cell and module suppliers are legally required to provide, see missing battery data from suppliers.)

A practical collaboration model

The supplier maintains the authoritative data about a component. The manufacturer receives the relevant information through an agreed interface or structured submission process, and it is associated with the product or component representation. When a specification changes, the manufacturer can identify affected products and workflows. This speeds up communication and reduces repeated requests for the same technical information. The data does not have to be copied into one central repository: it can stay with the supplier, subject to availability, contractual and access arrangements.

The commercial opportunity

The infrastructure used to prepare DPP data can also improve supplier onboarding, technical document exchange, purchasing decisions and change management. But a digital twin delivers these benefits only when suppliers actually participate and data formats, responsibilities and contractual permissions have been agreed.

7. Logistics, inventory management and product traceability

A regulatory DPP does not replace a warehouse management or supply-chain execution system, but a digital twin can connect product identity with logistics events. Imagine a manufacturer that assembles industrial batteries and distributes them through several warehouses. Each battery passes through production completion, quality release, packaging, warehouse receipt, shipment, distributor receipt, installation, and possibly return or service. A digital twin can maintain the relationships between the product and these events, which creates:

More precise traceability: identifying the products or batches involved in a specific production or logistics event.
Better inventory visibility: linking product identifiers to current WMS inventory instead of manually reconciling documents and warehouse records.
Improved exception management: linking a product damaged in transit to a specific shipment, inspection and claim.
More efficient recalls: identifying affected batches, components and potentially individual items more accurately.
Better information sharing: giving distributors and logistics partners the technical or handling information their role requires.

Which standards can help?

GS1 EPCIS is designed to share supply-chain visibility events describing what happened, where, when and why, and, since EPCIS 2.0, how. GS1 Digital Link, together with a resolver, connects a product identifier to one or more online resources. Combined with a well-designed product representation, these standards can link product master data to logistics events without replacing the ERP or WMS.

The value comes from connecting product identity, product information and operational events, not from creating another isolated logistics database.

8. Quality management, complaints and product recalls

This is one of the most commercially relevant applications. A company receives complaints about a product model: customers report a failure after several months of use. Without granular data, the quality team struggles to tell whether the failures relate to a particular supplier, production batch, manufacturing process or component.

A practical example

A manufacturer receives repeated warranty claims for an industrial component, each linked to the item's serial number. The digital representation connects that serial number to the product model, production batch, manufacturing date, supplier lots, inspection history, component configuration, shipment information and previous repairs. The quality team finds that several affected products contain components from the same supplier batch, investigates, determines the potentially affected population and starts the corrective process.

What changes compared with a DPP-only system?

A regulatory DPP may provide mandatory product and manufacturing information. It will not contain internal defect analysis, supplier corrective actions, return authorisations or the commercial history of each complaint. The digital twin can connect these operational records without making them part of the DPP.

The value depends on the quality of the underlying production and service records. A digital twin does not identify defects by itself, but it makes the information needed for an investigation much easier to retrieve and correlate.

9. Returns, warranty and after-sales service

For many companies, product information fragments once the product is sold. The manufacturer knows the original configuration, the distributor knows the sales transaction and the service partner knows the repair history. A digital twin can connect these records through the product identity, subject to the relevant permissions.

Example: a returned appliance

A customer returns an appliance that is not working properly. The service organisation scans its serial number and retrieves the original model, manufacturing information, installed configuration, warranty eligibility from the authorised commercial system, previous repairs, technical documentation, compatible spare parts and applicable service bulletins. The operator diagnoses the fault and records the outcome. If the appliance is repaired and returned, the repair event stays associated with that specific item; if it is refurbished and resold, the refurbishment information can be maintained too.

Why a DPP alone may not be enough

The regulatory DPP may include repairability or maintenance information, but it does not need to contain every warranty transaction or customer interaction. A digital twin supports a richer operational model, including information that must remain internal or restricted. The result is faster service handling, better spare-parts identification, more consistent warranty decisions and visibility of recurring failures: product identification turns from a regulatory cost into a tool for day-to-day service operations.

10. Product configuration management: what was actually delivered?

For complex products, the configuration as designed may differ from the configuration as manufactured and delivered, because of alternative components, supplier substitutions, engineering updates, production deviations, customer-specific configurations, or later repairs and upgrades. The DPP may only need to expose selected information. A digital twin can maintain a more detailed link between the product's configuration and the supporting engineering and manufacturing data.

An industrial machine may share a general model specification but contain a specific control unit, motor and software version. When the customer orders spare parts, the service team needs that machine's configuration; a model-level document is not precise enough.

The digital thread

This relates closely to the digital thread: linking information across engineering, manufacturing, distribution and service. A useful architecture connects the product's design definition, its as-manufactured configuration and its as-maintained configuration. The distinction is essential for spare parts, compatibility, software updates and technical support.

11. Beyond regulatory compliance: communicating with B2B customers

A Digital Product Passport is built around regulatory information and defined access rights. Professional customers often need much more: customer-specific configurations, installation instructions, operating parameters, maintenance recommendations, integration documentation, spare-parts catalogues, service bulletins, warranty information and product-specific quality documentation. A digital twin can support controlled access to these resources.

Different customers, different needs

An OEM customer may need component-level technical data. A distributor needs availability, specifications and commercial documentation. An installer needs configuration and commissioning instructions. A maintenance provider needs diagnostic and spare-parts information. A recycler needs material composition and dismantling information. There is little reason to expose everything to everyone; each party should get what is relevant to its role, while the regulatory DPP continues to follow its own legally defined access rules.

For brands, this replaces emailing different versions of the same documents to several partners with controlled, current information tied to a stable product identity.

12. Consumer communication: turning product identity into an ongoing relationship

For consumer brands, the product itself can become a digital touchpoint. A consumer scanning a product identifier may want information that is not part of the mandatory DPP: how to use and set up the product, videos and tutorials, care advice, spare parts, repair services, support, authenticity checks, optional warranty registration, accessories and recycling options. These services can be connected to the product identity without becoming DPP information.

Example: a premium furniture brand

A consumer buys a designer chair. The regulatory DPP may provide material composition, identification, repairability and environmental information. A connected digital twin could add:

Immediately after purchase: assembly instructions and setup videos.
During use: care and maintenance guidance suited to the specific materials.
If damage occurs: compatible spare parts and repair options.
At resale: product specifications and potentially an authorised record of refurbishment or authenticity.
At end of life: repair, reuse or disposal options.

Such services can strengthen the relationship between the brand and the user, but their value depends on relevance. Adding promotional messages to every scan is not inherently useful and can undermine trust.

Regulatory separation matters

The DPP's legally required information must remain accessible according to the applicable rules. Under the ESPR, personal data relating to customers must not be stored in the digital product passport without their explicit consent, in compliance with Art. 6 GDPR (ESPR Art. 10(1)(e)). Sector legislation can add further restrictions: under the Packaging and Packaging Waste Regulation, mandatory packaging information provided electronically "shall not be displayed with other information intended for sales or marketing purposes" (PPWR Art. 12(5)). Companies should therefore design separate, legally appropriate regulatory and commercial experiences.

A shared product identity does not mean that regulatory information and marketing content can always be displayed together.

13. Product authentication and anti-counterfeiting

A digital product identity can also support authenticity services. A brand can connect individual serial numbers to manufacturing and distribution records, so that an authorised partner or a consumer can check whether an identifier corresponds to a recognised product.

A QR code alone does not prove authenticity, however: a counterfeit can copy a genuine code. Effective anti-counterfeiting may require secure identifiers, tamper-evident features, controlled serial-number issuance or analysis of suspicious scan patterns. The digital twin can provide the information infrastructure for these processes, and the DPP can coexist with them without itself becoming an anti-counterfeiting system.

14. Repair, refurbishment and second-life business models

The circular economy creates business opportunities beyond mandatory product information. A product with a reliable digital history is easier to inspect, repair, refurbish and resell. This matters most for long-lived products: industrial batteries, professional equipment, machinery, consumer electronics, premium furniture and reusable transport assets.

Example: a second-life industrial battery

A battery is manufactured and placed on the market with a battery passport containing the required information. During use, its condition changes. A broader digital twin can maintain or link to additional information: service interventions, usage events, component replacements, diagnostic results, condition assessments, operational configuration and transfer to a different application. When a second-life operator evaluates the battery, appropriate access to this information supports technical and commercial decisions.

The Battery Regulation defines what happens to the passport itself. When a battery is prepared for re-use or repurposing, or is remanufactured, responsibility for the passport passes to the economic operator that places the battery on the market or puts it into service, and the battery gets a new passport linked to the passport or passports of the original battery (Art. 77(7)). After the battery has been recycled, the passport ceases to exist (Art. 77(8)). Who carries which obligation at each stage is covered in who is responsible for the Digital Product Passport.

Passport and digital twin therefore serve different but complementary needs. The passport satisfies the regulatory information framework and follows its legal lifecycle; the broader product representation supports business decisions about condition, maintenance and reuse, under the operator's own contracts, retention policies and applicable law.

A caution about data availability

Not every product has sensors or a detailed service history. The system must distinguish between measured, declared, estimated and missing information. A digital twin should never suggest that a battery has a verified condition history when no reliable operational data has been collected.

15. Predictive maintenance and connected products

For connected industrial equipment, a digital twin can support more advanced analytics. Sensor data, operating conditions and maintenance records associated with the individual equipment identity can enable condition monitoring, detection of unusual operating patterns, predictive maintenance, analysis of component degradation, optimised service intervals and better-informed replacement decisions.

A connected industrial pump, for example, generates temperature, vibration and pressure data. The digital twin combines these measurements with the installed configuration and maintenance history, and an analytics service can flag possible deterioration. For batteries, data from a battery management system can play a similar role. This goes well beyond the purpose of a regulatory DPP, and not every manufacturer needs it.

Predictive analytics should be introduced when the product, the available data and the business case justify it, not simply because the company has created a digital product identity.

16. One identifier, multiple digital services

Product identification is the technical link between the DPP and the digital twin. GS1 Digital Link offers a standards-based way to connect product identifiers to different online resources, and a resolver can associate one identifier with several destinations:

Destination	Example purpose
Regulatory DPP	Mandatory product information
Technical documentation	Manuals and specifications
B2B partner portal	Restricted customer information
Service application	Maintenance and spare parts
Logistics system	Traceability information
Consumer support	Instructions and support services
Product authentication	Identity verification
Product analytics	Operational information for authorised stakeholders

These destinations do not all have to live inside one platform. The resolver directs users or applications to different systems depending on the type of information requested. That matters, because a digital twin should not become a monolith trying to replace every enterprise application.

Why persistent identifiers matter

Products can remain in use long after the technology that created their records has changed. A stable identifier preserves the link between the physical product and its information as websites, databases and software platforms evolve. Persistence still requires governance and infrastructure: printing a QR code with a URL does not by itself guarantee that the information will remain accessible for years.

17. A reference architecture: digital twin as the foundation, DPP as a regulated view

A future-ready architecture can be organised into five layers.

Layer 1 - Authoritative enterprise systems

ERP, PLM, PIM, MES, WMS, QMS, CRM and supplier systems remain responsible for the data they legitimately own.

Layer 2 - Product digital twin and digital thread

A shared product representation provides consistent product identities, model, batch and item relationships, product and component structures, links to authoritative data, lifecycle events, version and configuration information, data provenance and business access policies. It can be implemented as one platform or as a federation of connected systems.

Layer 3 - Controlled information services

Applications use the product representation for specific purposes: regulatory compliance, supplier collaboration, logistics, quality, after-sales support, repair and refurbishment, analytics and customer experience.

Layer 4 - Regulatory DPP

The DPP publishes the legally required information according to product category, applicable regulation, required granularity, data formats and standards, access rights, and versioning and registration requirements. It should not indiscriminately expose everything held in the digital twin.

Layer 5 - Product identification and access

QR codes and other data carriers, resolvers and APIs connect the physical product to the appropriate information resources. One product identity can then support multiple applications without forcing all information into one regulatory passport.

18. A practical example: one battery, six business applications

Consider a manufacturer of rechargeable industrial batteries. The company maintains a digital representation of each battery model, its production batches and every individual battery.

EU battery passport: the system makes the required information available under Regulation (EU) 2023/1542, combining model-level and battery-specific data as Art. 77(2) requires.
Supplier quality: cells and components are linked to supplier declarations and quality records.
Manufacturing traceability: production batches and serial numbers are linked to assembly and inspection events.
Logistics: battery identities are connected to shipment and distribution records.
Warranty and service: authorised service partners retrieve the product configuration and service history.
Second-life assessment: condition and lifecycle information supports repair, repurposing and recycling decisions, and feeds the new passport when a repurposed battery is placed on the market again.

All six benefit from consistent identification and shared data relationships, but they do not expose the same information or serve the same users. This is where the value of a Product Digital Twin becomes visible: the regulatory passport is only one of several applications that use the underlying product information.

A broader product representation creates real governance challenges. The company must distinguish between:

Regulatory information: data required to be made available under applicable law.
Commercially sensitive information: supplier prices, proprietary specifications, internal manufacturing methods and other confidential information.
Operational information: inventory movements, production events, maintenance and quality records.
Personal information: customer or employee data, subject to data-protection law.
Calculated or inferred information: environmental indicators, analytics and estimates derived from underlying data.

These categories must not be treated identically. Each important attribute or event should have an identified source, an accountable owner, a defined granularity, a timestamp or validity period, a validation status, supporting evidence, access permissions and a change history. A supplier declaration that has been received but not verified should not become a validated regulatory claim just because it entered the digital twin. Likewise, a quality engineer's internal comment must never surface in a public DPP.

A flexible platform can provide different views of the same underlying information: a compliance view for authorities, a restricted technical view for service partners, a supplier collaboration view, an operational view for internal staff and a consumer view. Each follows the applicable legal and contractual requirements.

20. Standards: avoiding another proprietary data silo

A proprietary digital twin that cannot exchange information with suppliers, customers or other systems simply becomes another data silo. Several standards are relevant.

ISO 23247 - Digital twin framework for manufacturing

The ISO 23247 series (Parts 1 to 4, published 2021) sets out a digital twin framework for manufacturing, from principles and a reference architecture to information exchange. It helps organisations structure manufacturing-related digital twin systems.

IEC 63278 and the Asset Administration Shell

The Asset Administration Shell (AAS), standardised in IEC 63278-1:2023 and promoted by the Industrial Digital Twin Association (IDTA), represents industrial assets digitally through reusable submodels such as technical data, digital nameplates, carbon footprint, bills of materials and documentation. The IDTA publishes the Digital Battery Passport as a series of AAS submodel templates (IDTA 02035-1 to -7) covering nameplate, handover documentation, carbon footprint, technical data, product condition, material composition and circularity. This shows how structured industrial product information can serve different applications without forcing every use case into a single fixed dataset.

GS1 identification and traceability standards

GS1 identifiers support consistent identification of products, batches, serialised items and logistics units. GS1 Digital Link and resolvers connect those identifiers to digital resources, and GS1 EPCIS supports the capture and exchange of business events associated with products and assets.

EU DPP technical requirements

The ESPR sets its own technical framework for the regulatory passport: data carriers, unique identifiers, interoperability and access rights are covered by Articles 10 to 12 and Annex III, and Article 13 establishes the EU DPP registry, which has been live since 20 July 2026 (see what the EU DPP registry validates). Harmonised standards for the DPP were cited in Implementing Decision (EU) 2026/1736, which lists six EN standards. The regulatory passport must comply with the applicable requirements; a digital twin should be designed to coexist with them, rather than assuming that conformity with an industrial digital twin standard establishes DPP compliance.

The objective is not to pick one standard for every purpose. It is to select compatible standards that solve clearly defined problems.

21. Does a Product Digital Twin have to be real-time?

No, and this is a common misunderstanding. A digital twin should reflect the relevant state of its physical counterpart at a frequency appropriate to the use case. Connected industrial machinery may need frequent sensor updates. A piece of furniture may change meaningfully only when it is repaired, refurbished or resold. A batch of industrial components may only need updating when manufacturing, inspection or logistics events occur. A useful distinction:

Static digital product record: describes a product but is not meaningfully synchronised with later events.
Event-driven digital twin: reflects relevant product or lifecycle changes when they occur.
Connected operational digital twin: receives regular operating or condition information.
Analytical or predictive digital twin: uses models and data for analysis, simulation or forecasting.

These are practical architectural distinctions, not regulatory classifications. A company should choose the least complex approach that delivers its intended outcomes.

22. What is the real return on investment?

The business case should not rest on the idea that a digital twin is more advanced than a DPP. It should be tied to measurable improvements:

Business area	Potential benefit	Example KPI
Supplier management	Less repeated data collection	Time to onboard a supplier
Compliance	Easier adaptation to new rules	Time to implement a new data requirement
Manufacturing quality	Faster issue identification	Root-cause investigation time
Product recalls	More targeted identification	Units requiring precautionary action
Logistics	Improved visibility	Time to trace a shipment or batch
Inventory	Better product identification	Inventory discrepancies
Warranty	Faster product verification	Average claim-handling time
Service	Better access to technical data	First-time repair resolution
Spare parts	Better compatibility identification	Incorrect spare-part orders
Customer support	More self-service	Support requests per product
Circularity	Better reuse and refurbishment decisions	Share of eligible products recovered or refurbished
B2B collaboration	More efficient document exchange	Manual information requests
Regulatory scalability	Reuse of common data structures	Integration effort per new product category

These are potential KPIs, not guaranteed improvements.

How to evaluate the business case

Start with two or three processes that are currently expensive, fragmented or highly manual. For each, establish:

The current cost or performance.
The information needed to improve it.
Whether that information already exists.
The integration and governance work required.
The expected operational benefit.
The ongoing cost of maintaining the digital twin.

Only then decide whether a more sophisticated product representation is justified. For many manufacturers, adding a business application to an existing structured product-information platform costs much less than building a separate application from scratch, but that depends on architecture, licensing, data quality and integration costs, and should be validated through a pilot rather than assumed.

23. When is a Product Digital Twin unnecessary?

Sometimes a simple DPP implementation is enough. A company selling low-cost, simple products with little maintenance, no individual tracking, no meaningful operational data and very few after-sales interactions will struggle to justify an item-level digital twin. And a company that already runs a mature PLM, ERP and service infrastructure may duplicate existing capabilities by adding a separate digital twin platform.

Warning signs of unnecessary complexity

The same data is stored in several systems without clear ownership.
The proposed digital twin has no identifiable business use case.
Item-level serialisation is introduced without operational justification.
The company cannot explain which processes will improve.
The new platform requires extensive manual data entry.
The project increases supplier workloads without a clear benefit.
The digital twin has attractive visualisations but no reliable operational information.

In such cases, the better decision is to improve existing product data and build a compliant DPP on top of it. A Product Digital Twin is valuable when it enables useful synchronisation, information relationships and business actions, not when it is just another name for a product database.

24. The recommended approach: progressive product digitalisation

Companies do not need to launch a large digital twin transformation programme alongside their DPP project. A phased approach is generally more effective:

Build the DPP-ready information foundation: identify product categories, data requirements, identifiers and authoritative sources, and start structuring the data needed for compliance.
Model the relationships between products, batches and items: where justified, link model-level information, batches and individual products without duplicating shared attributes.
Connect operational data sources: pick one or two valuable processes, such as warranty, supplier quality or logistics traceability, and connect the relevant data to the product identity.
Introduce controlled data-sharing services: make appropriate information available to suppliers, distributors, professional customers or service partners, with the necessary permissions and contractual controls.
Extend to lifecycle applications: where justified, support repair, refurbishment, maintenance, second-life operations or condition monitoring.
Expand across markets and regulatory frameworks: reuse the foundation for country-specific requirements and future DPP changes.
Measure the actual value: evaluate operational improvements, cost savings, service quality and new revenue, and extend the programme only where the business case is demonstrated.

25. The future: from product passports to connected product ecosystems

Once physical products are tied to stable digital identities and structured information, manufacturers can build more connected supplier networks, automated information exchange, end-to-end traceability, data-supported resale and new second-life business models.

A Product Digital Twin can provide the architectural foundation for these applications. The transformation will depend on connecting existing business systems, establishing reliable data governance and exchanging information across organisational boundaries. The DPP alone does not guarantee this, but DPP investments create an opportunity to begin.

26. Conclusion: the DPP is a requirement, the digital twin can be a strategic asset

So, is a Product Digital Twin redundant when a company already has a Digital Product Passport? Not if it provides capabilities that go beyond the passport's regulatory purpose.

A well-designed digital twin connects regulatory information with manufacturing, logistics, quality, service, supplier collaboration and customer experiences. It can support compliance in several markets, provide flexibility as requirements evolve, and enable more granular tracking where it helps the business, even when the regulatory DPP only requires model- or batch-level information. It should not mean duplicating product information or running independent systems with competing versions of the same data. The most effective approach is a flexible, interoperable product-information foundation, with the Digital Product Passport as one controlled application of it.

The central strategic question therefore shifts from "How do we create a Digital Product Passport to comply with the regulation?" to "How can we use the product information and digital identity we are building for compliance to improve the way we manufacture, distribute, service and communicate about our products?"

For some companies, a compliant DPP will be sufficient. For others, a broader product digital twin turns a regulatory investment into a long-term business capability. The difference lies in the use cases, the architecture and the measurable value.

27. How GoodsTag helps organisations go beyond DPP compliance

GoodsTag provides a digital product information platform that connects physical products with structured data and services. Through Digital Product Passports, including the Battery DPP, standardised product identification, GS1 Digital Link resolution and data integration, GoodsTag helps companies build a foundation that can be extended beyond individual regulatory requirements: connecting compliance information with additional product data, supplier collaboration, operational information and customer-facing experiences.

Rather than treating each regulation or business application as an isolated project, the aim is a reusable, scalable digital product infrastructure. The right architecture depends on the product category, the available data, the existing enterprise systems and the use cases that justify it. The objective is not to build a digital twin because it is technologically possible. It is to turn product information into measurable business value.

Sources

Last regulatory review: 10 October 2026. This article distinguishes regulatory obligations from optional business capabilities and architectural recommendations. Product Digital Twins are not required by EU DPP legislation; their value depends on the applicable legal requirements, the product and the business use cases. It is not legal advice.