Passport Control for Hardware: The BOM-Level Work UK Engineering Teams Must Start in 2026
Photo: UK engineer reviewing digital product passport data on laptop in factory with PLM dashboard, photorealistic, via upload.wikimedia.org
The digital product passport (DPP) has a deceptively simple user interface: a code on a product, a page of data, a lifecycle record. For UK hardware manufacturers exporting into the European Union, the difficult work sits far below that interface. It sits in the bill of materials, the supplier declaration, the test certificate and the service history. As of November 2026, engineering leaders should be planning DPP as a systems-integration programme, not a labelling exercise.
The code is the easy part
A QR code can be printed in an afternoon. A DPP needs a governed data model that can answer questions about materials, substances of concern, carbon footprint, repairability, spare parts and end-of-life treatment. The EU's Ecodesign for Sustainable Products Regulation provides the framework, while the Battery Regulation sets an early milestone with the digital battery passport from February 2027. Other product groups will follow through delegated acts. For UK exporters, the trigger may be an EU customer's contract before it is a UK regulation.
That distinction matters for programme design. A compliance team may own the legal obligation, but engineering owns the product data. If the DPP is treated as a marketing portal or a supplier questionnaire, the data will be incomplete, inconsistent and hard to audit. If it is treated as a master-data and integration programme, it can become a useful digital thread across design, manufacturing and service.
What the passport asks of an engineering team
The exact data requirements will vary by product group, but the direction is consistent. A DPP is expected to carry a unique product identifier, manufacturer and production facility details, material composition, substances of concern, recycled content, carbon footprint, performance and durability information, repair and disassembly guidance, spare-part availability and end-of-life instructions. Not every field will apply to every product, but the passport is designed to be machine-readable and updatable.
For UK hardware teams, the practical question is not whether the company has this information somewhere. It is whether the information can be linked to a specific product, batch or serial number and retrieved in a form that an EU market-surveillance authority, customer or recycler can trust. That is a data architecture question before it is a compliance question.
Why BOM-level data is the pinch point
Most UK manufacturers have bills of materials in a PLM or ERP system, supplier data in spreadsheets, test records in quality systems and service data in field-service tools. The DPP needs these to be linked by part number and serial number. A supplier's declaration that a part is compliant is not enough. Teams need material composition, CAS numbers where relevant, country of origin, recycled content, test evidence and change history.
This is where many DPP pilots will fail. The bill of materials is an engineering artefact, not a compliance artefact. It changes as designs change. It may contain substitutes, optional variants and supplier-specific parts. A DPP that is built once from a static spreadsheet will be out of date before the product ships. The programme needs a repeatable method for collecting supplier data, validating it and linking it to the configuration that was actually manufactured.
Supplier provenance is the second pinch point. UK manufacturers often sit in multi-tier supply chains. A first-tier supplier may not know the material composition of a sub-component. The DPP programme therefore needs a supplier engagement plan, clear data templates and a way to escalate missing data without stopping production. It also needs a legal basis for sharing data across the chain, especially where commercial confidentiality or export control applies.
Lifecycle records expose the after-sales gap
A DPP is not only a birth certificate. It is a record of events: repairs, part replacements, firmware updates, inspections and end-of-life treatment. That creates a new integration challenge. Many UK engineering firms have strong manufacturing data but weaker field-service data. Service records may sit with distributors, maintenance partners or customers rather than the original manufacturer.
A practical DPP pilot should therefore include at least one lifecycle event, not just a static product record. For example, a repair event could update the passport with the replacement part number and date, while preserving the original configuration. That requires an event model, access controls and a clear rule for who can update the record. It also requires cyber-security thinking, because a publicly accessible passport must not expose intellectual property or personal data.
A 2026–27 pilot plan
A sensible pilot starts with one product family that has EU exposure and a manageable supplier base. The first step is to assign data owners across engineering, procurement, quality, manufacturing and service. The second is to build a minimum data model that reflects the likely DPP fields without trying to model the entire portfolio. The third is to map where each field currently lives: PLM, ERP, MES, quality management, PIM or supplier portals.
The fourth step is a supplier data pilot with a small group of critical suppliers. The fifth is a serialised digital thread that links a finished product to its as-built BOM, test records and service history. The sixth is a customer-facing test with an EU buyer or distributor. The seventh is a completeness and latency measure: can the team answer a reasonable DPP query in minutes, hours or weeks?
That pilot should not wait for every delegated act to be finalised. The data plumbing takes longer than the legal text. Teams that start in 2026–27 will learn where their BOM, supplier and service data break. Teams that wait for a single UK regulation may find that their EU customers have already made DPP data a condition of supply.
Governance beats a QR-code vendor
DPP programmes need a data steward, not just a software vendor. The steward owns definitions, validation rules and change control. Legal and compliance teams need to review claims and access rights. Cyber teams need to review authentication and update permissions. Engineering teams need to review the product data model. Without that governance, a DPP can become a polished front end over unreliable data.
The most useful framing for UK engineering leaders is this: the passport is a product data product. It has users, interfaces, quality requirements and a lifecycle. Treating it as a systems-integration programme is not bureaucratic overhead. It is the only way to make the passport accurate enough to be useful and durable enough to survive the next product change.
