ESPR Compliance: An Engineering Team's Checklist

Read the delegated act, not the regulation

The most common and most expensive mistake in ESPR programmes is treating Regulation (EU) 2024/1781 as though it contained the requirements. It does not. It is a framework regulation that establishes the mechanism through which requirements are set, product group by product group, through delegated acts adopted separately over a period of years.

This distinction has direct engineering consequences. Teams that read the framework and start building generic passport infrastructure frequently build the wrong thing, because the data fields, the identifier granularity and the access requirements are all determined by the delegated act covering their specific category. Building before that is known produces infrastructure that has to be substantially reworked.

The Commission's working plan identified priority categories including textiles, iron and steel, aluminium, furniture and tyres, with obligations phasing in from around 2027. Batteries sit outside this under Regulation (EU) 2023/1542, which sets a battery passport obligation from February 2027. Establishing which instrument applies to you, and reading it, is genuinely the first engineering task.

The decisions that come first, in order

• Which delegated act applies to your product category, and what it actually requires
• Identifier granularity: model, batch or item level, and the production line consequences
• Which data carrier: QR code or Data Matrix, and where it physically goes on the product
• Which data model and vocabulary, chosen for interoperability rather than internal convenience
• Which actors get which view: consumer, repairer, recycler, market surveillance authority
• Where the data lives, how long it must persist, and what happens if you change systems
• How supplier data will be collected, validated, and handled when it is missing

Identifier granularity is the decision you cannot cheaply reverse

Everything else in a passport programme can be refactored. Identifier granularity cannot, because it is embodied in physical products already in the field. Choosing model-level identification means every unit of a product shares one identifier, which is cheap to implement and provides essentially no traceability when a defect or recall arises.

Item-level serialisation gives full traceability and touches parts of the business that engineering does not usually reach. Unique codes must be generated, printed, verified on the line, and reconciled through manufacturing and distribution. That involves production equipment, packaging processes and often external contract manufacturers, which is why this decision has a lead time measured in months rather than weeks.

Batch level is the usual compromise and is frequently what a delegated act effectively assumes. The important thing is to make the choice deliberately, with the applicable act open, rather than defaulting to whatever is easiest to implement in the first sprint and discovering the consequences after fifty thousand units have shipped.

Supplier data is the critical path, always

Engineering teams consistently underestimate this, and it is worth stating without hedging. Building the passport infrastructure is tractable, well-understood work: an identifier scheme, a resolver, a structured data model, a tiered access API. Competent engineers deliver that in a few months using open standards.

Obtaining accurate material composition data from a tier-two supplier who has never been asked for it in structured form is a different category of problem. They may regard it as commercially sensitive. They may genuinely not know, because their own supplier has not told them. They may be willing but have no system capable of producing it. None of these are engineering problems and none of them are solved by better architecture.

Programmes that succeed start the supplier workstream on day one, in parallel with everything else, and design the passport to handle gaps explicitly rather than pretending they will not occur. That means documented proxy methodology, disclosed uncertainty, and a data model that can represent 'not yet supplied' as distinct from 'zero'. Programmes that struggle build elegant infrastructure and then discover, weeks before a deadline, that they have nothing accurate to put in it.

Who needs to be in the room

ESPR programmes fail more often on organisational grounds than on technical ones, and the composition of the team is a large part of why. An engineering team working alone will build competent infrastructure against assumptions nobody else has validated, and will discover late that procurement cannot obtain the data, or that the production line cannot print what the design assumes.

Four functions have to be involved from the start. Engineering owns the data model, the resolver and the access tiers. Procurement owns the supplier relationships through which the data actually arrives, and they need lead time measured in months. Operations owns the production line and packaging changes that item-level or batch-level identification requires. And whoever owns regulatory interpretation has to confirm which delegated act applies before anyone builds anything.

The practical mechanism that works is a single named owner with authority across all four, meeting weekly against a shared decision log. The failure mode is a project run entirely from engineering, where the supplier data workstream has no owner and consequently does not start until it is already the binding constraint.

Part of the Circular Economy & Digital Product Passports cluster · Read the pillar page