Where does DPP data live? PLM, PIM, ERP and the passport platform explained

KEY TAKEAWAYS Summary by the editors

1. Digital Product Passport data is spread across systems: PLM usually holds materials and bills of materials, ERP holds orders, batches and suppliers, and PIM holds published product content.
2. A passport platform should assemble and publish passport records from these systems rather than become a second master for product data.
3. CEN-CENELEC published six DPP standards on 14 July 2026 covering data exchange (EN 18216), identifiers (EN 18219), carriers (EN 18220), storage (EN 18221), APIs (EN 18222) and interoperability (EN 18223).
4. Commission Implementing Decision (EU) 2026/1736, adopted on 14 July 2026, approves harmonised standards for the Digital Product Passport developed with CEN-CENELEC.
5. The most important integration decision is the identifier: the passport must link reliably to the product level the textile rules will require, whether model, batch or item.

Digital Product Passport (DPP) data lives in several systems at once: material and composition data in PLM, published product attributes in PIM, orders, batches and supplier transactions in ERP, and certificates in supplier or compliance tools. A passport platform should collect, validate and publish this data under a stable identifier, not replace these systems. Getting ownership clear per attribute matters more than choosing a tool.

Which system should own which passport data?

Every attribute needs one system of record, the place where it is created and corrected. Other systems may copy it, but only one may change it. The table shows a common split in fashion companies; your own landscape may differ, but the principle of single ownership should not.

What does the passport platform actually do?

A passport platform is the layer that turns internal data into a published, standardised passport. Its main jobs are to receive data from source systems through interfaces, validate completeness against the required data list, store passport versions, resolve the data carrier (for example a QR code) to the right record and handle registration where required. USB Certification reports that the Commission launched the EU Digital Product Passport Registry and its testing environment on 20 July 2026, describing it as the infrastructure in which businesses placing products on the EU market must register each passport.

The platform should not become a second place where designers or merchandisers edit composition or certificates. If corrections happen in the passport layer, the source systems drift, and the next season's passport repeats the old error.

Read also

What a modern tech stack looks like for a mid-sized fashion brand

Which standards shape the integration?

The technical rules arrived in July 2026. Commission Implementing Decision (EU) 2026/1736, adopted on 14 July 2026, approves harmonised standards for the passport developed with CEN-CENELEC. Six standards were published on the same day:

• EN 18216: data exchange protocols and machine-readable formats.
• EN 18219: unique identifiers for products, economic operators and facilities.
• EN 18220: data carriers, including optical 2D codes, RFID tags and NFC chips.
• EN 18221: data storage, archiving and persistence, including historical versions.
• EN 18222: APIs for finding, resolving, retrieving and managing passport information.
• EN 18223: semantic, technical and organisational interoperability.

For apparel, existing GS1 standards are also relevant. GS1 UK describes the GTIN as identifying every product variant by style, size, colour and fit, EPC and RFID as enabling item-level visibility, and GS1 Digital Link QR codes as a consumer-facing access point to product information and the passport. Whether the textile delegated act will require specific carriers is still open, so integration designs should keep the identifier logic separate from the physical carrier.

What is the hardest integration decision?

The identifier and its level of granularity. The textile rules may require passports per model, per batch or per item. Most fashion companies identify products by style, colour and size in PLM and ERP, and only some serialise individual items. If the passport later needs batch or item data, the link between a garment and its production lot must already exist in ERP and logistics data.

A practical test: pick one style and try to answer, from systems alone, which mill made the fabric for a specific delivery of size M in navy. If that requires emails and spreadsheets, the gap is in the data model, not in the passport platform.

How should the systems connect, step by step?

1. Define the target data list using current drafts and voluntary schemes, and tag each attribute with its system of record.
2. Agree on the passport identifier and how it maps to GTIN, style-colour-size and production lot.
3. Close gaps at the source: add missing fields in PLM or ERP rather than in the passport platform.
4. Build interfaces from source systems to the passport layer, preferably event-based so that a corrected certificate updates the passport.
5. Add validation rules for completeness and plausibility before a passport is published.
6. Version every published passport, because EN 18221 addresses historical versions and long-term accessibility.
7. Test registration and carrier resolution with the Commission's testing environment once textile requirements are known.

Where does AI fit into the integration layer?

AI is most useful where data is unstructured or inconsistent: extracting values from supplier certificates and test reports, mapping free-text composition to controlled vocabularies, matching facility names across systems and spotting anomalies such as fibre shares that do not add up. It can also draft care and end-of-life text in PIM for human approval.

AI should not sit between source systems and the published passport as an unsupervised transformer. Each automated value needs a trace back to its source document and, for published attributes, a documented human or rule-based check. Passport data may be inspected by authorities, so explainability of where a value came from is a requirement, not a nice-to-have.

Read also

Moving a fashion ERP to the cloud: lessons from 2024 to 2026 migrations

What should IT teams do in 2026 and 2027?

Use the period before the textile delegated act to clean master data and define ownership, because those tasks take longest and are needed whatever the final data list contains. Read the six standards with your architects, map your identifier logic to EN 18219 and GS1 practice, and keep platform choices flexible until the textile requirements are published.

Frequently asked questions

Is PLM or PIM the right system for the Digital Product Passport?

Neither alone. PLM usually owns materials and bills of materials, PIM owns published product content and ERP owns orders and batches. A passport platform or integration layer should pull from all of them, with each attribute owned by one system of record.

Do I need a separate Digital Product Passport platform?

You need a capability that assembles, validates, versions and publishes passports and resolves the data carrier to the right record. That can be a dedicated platform or an extension of existing systems, but it should not become a second place to edit product data.

What standards apply to Digital Product Passport integration?

CEN-CENELEC published six DPP standards on 14 July 2026, covering data exchange, identifiers, data carriers, storage, APIs and interoperability. Commission Implementing Decision (EU) 2026/1736 approves harmonised standards for the passport. GS1 identifiers and Digital Link are also widely used in apparel.

Will the textile DPP be per item or per product model?

That is not yet decided. The textile delegated act, tentatively planned for adoption in 2027, will set the required granularity. Companies should design identifiers so they can move from model to batch or item level without rebuilding systems.

GuideThe complete guide to AI in the fashion supply chain and sustainabilityRead the complete guide