How fashion teams can prepare for EU product passports

Fashion teams should assume that EU product passports are moving from policy discussion into operational reality. For apparel, footwear and other textile products, the question is no longer whether more structured product data will be required, but how quickly teams can organise it in a form that is reliable, maintainable and defensible. The businesses that cope best will not be the ones with the most polished sustainability claims. They will be the ones that can connect product, supplier and compliance data to a specific SKU, batch or model and keep that record current over time.

In practice, preparing for a digital product passport for fashion in the EU means building a repeatable data process across design, sourcing, quality, compliance, logistics and IT. That starts with understanding likely scope, then deciding which data fields matter, where they sit today, who owns them, and how they will be updated when a fabric changes, a supplier is replaced or a certification expires. If you are still relying on spreadsheets, email attachments and supplier declarations stored in personal folders, now is the time to fix that.

A digital product passport is a structured digital record linked to a product. Under the EU's Ecodesign for Sustainable Products Regulation, or ESPR, product passports are expected to become a core mechanism for making key product information available across the value chain. The purpose is not only consumer transparency. It is also to support market surveillance, sustainability requirements, repair, reuse, recycling and better evidence for economic operators.

For fashion, this matters because textiles are one of the priority product groups under the EU's sustainable product policy agenda. The detailed rules for textiles will come through delegated acts, which will define exactly which products are in scope, what data must be included, how the carrier and identifier should work, and which actors must provide or verify information. Until those textile-specific rules are finalised, no responsible team should pretend every field is settled. But the direction of travel is clear enough to prepare properly.

In practical terms, fashion passports are likely to require a persistent product identifier, a data carrier such as a QR code or similar machine-readable link, and a set of mandatory data fields tied to the product record. Those fields are likely to cover areas such as product identity, composition, origin, substances, durability or repair-related information, and compliance evidence. Some data may be publicly accessible. Some may be limited to authorities or supply chain actors.

The passport is not simply a marketing page with sustainability copy. It needs to be governed like compliance data. If a jacket is sold in multiple EU markets, made in more than one factory, or updated seasonally with a revised lining or trim, the passport record has to reflect the version actually placed on the market. That means change control, document control and traceability matter as much as the front-end experience.

For teams looking at the broader operating model, fashion passport workflows and data requirements are best treated as an extension of existing product governance, not a standalone campaign.

The final scope for fashion will depend on the textile-specific delegated act under ESPR. However, brands should work on the basis that a wide range of textile and fashion products sold into the EU could be affected. That is likely to include clothing and may extend across footwear, accessories and other textile-based goods, depending on how the product categories are defined in the implementing rules.

Scope usually works through both product type and operator role. The product side determines whether the item itself is covered. The operator side determines who has obligations when that item is placed on the EU market. In EU product law, responsibilities often sit not just with the manufacturer, but also with importers, authorised representatives, distributors and fulfilment actors depending on the framework. For digital product passports, obligations are expected to align with that broader logic.

That is why brands, importers and manufacturers should all pay attention now.

If you are the brand owner and you specify the product, approve materials, control the technical file and place goods on the EU market under your name, you are likely to be central to passport readiness even where production is outsourced. If you import goods into the EU from the UK, Turkey, China, Bangladesh or elsewhere, importer obligations may become especially important because you may be the first operator placing the item on the EU market. If you manufacture for private label customers, your clients will need structured data from you, and they will increasingly expect it in a consistent format.

The position is different for businesses selling only in Great Britain. The UK has not adopted the EU ESPR framework in the same way, so there is currently no direct UK equivalent requiring the same digital passport regime for fashion products. But that difference only helps if the goods never enter the EU. A UK brand shipping to EU customers, supplying EU retail partners or using an EU importer still needs to meet EU rules for in-scope products.

Multi-brand retailers should pay attention too. Even where the primary data obligation sits upstream, retail teams will need confidence that products they list or distribute carry the correct identifier and linked data. Marketplaces may also tighten onboarding requirements once product passport rules become operational.

Most fashion businesses already hold some of the necessary data, but not in one controlled structure. The work is to identify which data elements exist, where they sit, how trustworthy they are, and what evidence supports them.

The main categories to organise are usually these:

This is the foundation. Without stable product identity, every other field becomes hard to manage.

Typical fields include:

• Brand and product name
• Internal style number
• SKU or variant code
• Model or article number
• GTIN, EAN or other market identifier
• Season or collection reference
• Product category and subcategory
• Size and colour variants
• Version or revision status

You need to decide which identifier is the master key for the passport record and how child variants inherit or override parent data.

Fashion passports are likely to rely heavily on composition and component-level information.

Typical fields include:

• Fibre composition percentages
• Main fabric, lining, interlining, padding and trim details
• Leather type, coating or finish where relevant
• Buttons, zips, labels, thread and packaging components
• Recycled content claims and calculation basis
• Material supplier and mill references
• Restricted substance declarations linked to each component where needed

A simple care label composition line is rarely enough. Teams will need structured component data that matches what was actually approved and produced.

This is where many programmes slow down, because the commercial relationship often sits with a tier 1 supplier while the key data sits deeper in the chain.

Typical fields include:

• Cut-make-trim factory details
• Fabric mill and dye house
• Spinner, tannery or processor where relevant
• Country of manufacture
• Country of origin data where legally relevant
• Production site identifiers
• Batch, lot or production run references where applicable
• Supplier declarations and date of issue

Not every passport will require full public disclosure of every tier. But internally, you should know what you can evidence and where the gaps are.

This is the area that turns a data exercise into a compliance programme.

Typical fields include:

• Test reports
• Declarations of conformity where applicable
• Restricted substances compliance evidence
• REACH-related supplier declarations
• Certifications for organic, recycled or other claims
• Packaging compliance records where linked
• Due diligence records where relevant
• Technical specifications and approved samples
• Audit trails showing approval and update history

The critical question is not only whether a document exists, but whether it is current, product-specific and tied to the exact version sold.

Depending on the final rules, fashion teams may also need data that supports durability, repair or end-of-life handling.

This may include:

• Care and maintenance instructions
• Spare part availability for certain products
• Repair guidance
• Disassembly or material separation information
• Take-back or recycling instructions
• Expected product lifetime claims, if made

If you already publish some of this for consumers, check whether the underlying source data is controlled or just copied into marketing copy.

The hard part is not listing fields. It is making the data move properly between systems and teams.

In most fashion businesses, product data starts in design or merchandising, then moves into PLM. Supplier, costing and order data may sit in ERP or sourcing tools. Compliance documents may sit in a quality platform, shared drive or email chain. Packaging data may live elsewhere again. If each system uses a different product code, matching records becomes manual and error-prone.

Operationally, the passport process should work like this:

Design and product development create the base product record, with style, variant and component structure.

Sourcing and supplier management attach approved supplier and facility details to the product and component records.

Compliance and quality attach test reports, declarations, certificates and specification approvals to the same product structure, not to a generic supplier folder.

ERP or order systems confirm the actual production and sales context, including which factory, which purchase order and which market the goods are for.

A passport layer then assembles the required fields from those upstream systems, applies validation rules, and publishes the correct record against the product identifier and data carrier.

When a product changes, the update should trigger review of the passport record. A fabric substitution, a new trim supplier or a revised composition should not wait until after goods are shipped.

This is why governance matters more than a nice interface. Before choosing a platform, most teams should clarify what to look for in a digital product passport system, especially around identifiers, document evidence, permissions and update workflows.

At scale, supplier engagement is essential. You will need standard templates, required fields, validation checks and deadlines. Asking each supplier for "all sustainability documents" will produce unusable results. Asking for named documents against named fields, with accepted formats and expiry controls, is far more effective.

The same weaknesses appear in most fashion data projects.

Many teams have declarations, but not enough evidence behind them. A supplier may state recycled content, fibre composition or chemical compliance without a current certificate, test report or traceable source document.

Fix this by defining evidence standards per field. Decide which claims require a certificate, which require a declaration, which require a lab report, and how current each document must be.

A style may have one code in PLM, another in ERP, another in the e-commerce catalogue and another in supplier paperwork. That makes it difficult to prove that the passport record matches the item sold.

Fix this by creating a cross-reference table and deciding which identifier controls the passport. Then enforce that identifier across supplier documents and internal workflows.

Teams often overwrite files, reuse old test reports after a material change, or fail to distinguish proto, salesman sample and bulk-approved specifications.

Fix this with formal versioning rules. Every material change should trigger a review of related compliance fields. Withdrawn documents should be archived, not left active in shared folders.

If nobody owns a field, it will go stale. If three teams think they own it, it will become inconsistent.

Fix this with a data ownership matrix. For each field, assign an owner, a contributor, an approver and a review frequency.

Spreadsheets are useful for gap analysis, but they are fragile as a live compliance process. They break when product counts increase, teams change and update frequency rises.

Fix this by moving critical passport fields into governed systems with access control, audit trails and validation rules.

If the project sits only with marketing, digital or sustainability communications, the data quality will usually be too weak for regulatory use.

Fix this by putting compliance, sourcing, product and IT into the same operating group from the start.

For teams working through governance questions, how compliance teams assess digital product passport systems is a useful way to frame the controls you will need internally even before any procurement starts.

The most effective preparation plans are practical and limited in scope at first. Start with one product area, one market route and one manageable data set. Then build.

Create a list of products that are likely to fall within future textile passport rules, especially those sold into the EU. Split them by category, brand, market and sourcing model. Identify where you act as manufacturer, importer or distributor.

List the data fields you expect to need under likely passport requirements. Then map where each field currently sits, which system holds it, who owns it, what format it is in, and what evidence supports it.

Use a simple status such as:

• Available and reliable
• Available but inconsistent
• Missing
• Unknown

Do not start with every possible field. Prioritise the ones that are hardest to evidence or most likely to fail under scrutiny, such as composition, supplier traceability, restricted substances evidence, recycled content support and product identifiers.

Create a RACI or equivalent ownership model. For each field, define:

• Who provides it
• Who checks it
• Who approves it for passport use
• When it must be reviewed
• What triggers an update

Replace ad hoc document chasing with structured requests. Use standard templates for composition, facility details, certificates and declarations. State accepted file formats, naming rules, validity periods and escalation paths for missing data.

Pick a small number of products and run the full process. Build the record, collect the evidence, assign the identifier, generate the linked passport view and test how updates are handled when a component changes.

The point of the pilot is to find operational failures early. You want to know where data is duplicated, where suppliers cannot respond, where systems do not align, and where approvals get stuck.

Document the rules for data validation, access permissions, document retention, version control and audit history. If a regulator or retail customer asks how a field was derived, you should be able to show the source, date and approver.

Once the pilot works, expand by product family or sourcing region. Avoid a big-bang launch across every category at once. Fashion assortments change too quickly for that to be realistic.

Keep your preparation model flexible. The textile-specific delegated act will determine the final required fields and technical conditions. Your architecture should be able to add or revise fields without rebuilding the whole process.

A passport is not completed once and forgotten. New seasons, revised materials, supplier changes and expiring certificates all create update events. The process has to become part of normal product lifecycle management.

Fashion teams do not need to wait for every final legal detail before acting. The sensible move now is to organise the product data you already depend on, close the obvious evidence gaps, and make sure your systems can support a passport record that is current, specific and traceable. That is what will separate businesses that can scale EU compliance from those still trying to reconstruct the truth from last season's email threads.