What goes in a construction Digital Product Passport: the data, and where it already lives in your company

The passport is a wrapper, not a new document

The most expensive misreading of the revised CPR is that the Digital Product Passport is another compliance artefact to author - one more file to produce per product, alongside the declaration and the datasheet. It is not. The passport is a container, and almost everything it contains is something you are already obliged to produce today.

What changes is not what you must say about a product. It is the form in which you must be able to say it: structured rather than laid out, addressed rather than filed, and served on request to anyone with a scanner rather than emailed on request to a customer. That is a different kind of work from compliance drafting, it lands on different people, and it is the reason the readiness horizon is measured in years while the legal text can be read in an afternoon.

The centre of the container is the Declaration of Performance and Conformity (DoPC) - the successor to the DoP, merging declared performance with regulatory conformity and phasing in mandatory environmental content. Our guide to the revised CPR covers what the DoPC is and when it bites; this piece assumes it and looks at everything around it.

What Article 76 actually lists

Article 76 of the revised CPR sets out what a construction digital product passport must include. Read as a data specification rather than as legal text, it is seven things:

1. The Declaration of Performance and Conformity, referred to in Article 15 - combining declared performance and, where applicable, conformity with product requirements in a single declaration. It also includes the information referred to in Article 15(6), notably information required under Articles 31 or 33 of the REACH Regulation.
2. General product information, instructions for use and safety information, referred to in Article 22(6) and set out in Annex IV.
3. The technical documentation referred to in Article 22(3), including the specific sections required where the simplified procedures under Articles 59 to 61 are used.
4. The label required in accordance with Article 22(9).
5. Unique identifiers issued in accordance with Article 79(1).
6. Documentation required under other Union law applicable to the product.
7. The data carriers of key parts, where a Digital Product Passport is available for those parts.

The whole thing is then linked to a data carrier on the product, its packaging or its documentation - a QR code, a linear barcode, a data matrix, or any other automatic identification medium a device can read.

Item seven is the one worth stopping on. A passport that must carry the data carriers of key parts that already have passports of their own is more than a self-contained document: it begins to look like a node in a graph. Your product passport can point to passports associated with key parts supplied to you, creating links across the value chain.

That has an important operational consequence. The required information may not be generated entirely inside the manufacturer's own compliance function; some of it may depend on data made available by suppliers. In practice, that can push DPP readiness upstream into supplier-data management, procurement requirements and, potentially, contract language. It may also create longer lead times where suppliers are less advanced in their own DPP readiness. The CPR does not explicitly prescribe those procurement processes, but Article 76(2)(a)(vii) creates the dependency that makes them relevant.

Where each of these already lives in your company

This is the part that surprises manufacturers in a readiness assessment, and it is good news before it is bad news. Almost every element already exists somewhere in the business. It is simply scattered across four or five functions, in formats chosen for printing, and keyed to identifiers that were never meant to leave the building.

Read the fourth column downward and the shape of the programme appears. Two rows are document conversion, which is tractable. Two rows are data governance, which is a project. One row - environmental characteristics - is a measurement exercise with an external dependency and a lead time you cannot compress. And one row is a procurement negotiation with your own supply chain. That is why this is a multi-year programme with an accountable owner, and not a task for the person who currently maintains the declarations.

What "machine-readable" rules out

The word does more work in this regulation than it looks like it does. A PDF placed behind a QR code satisfies none of it, even when the PDF contains every fact the passport requires. Three demands sit behind the phrase.

Structure

A declared performance value has to arrive as a value - with its unit, its test method and its tolerance as separate, addressable data - not as a cell in a table in a layout. Anything a receiving system has to parse out of prose is not structured, and a receiving system that guesses is a liability rather than a feature.

Identity

The passport is reached through an identifier, so the identifier has to be worth reaching. Most manufacturers' article numbers fail this on the first test: they get reused when a product is discontinued, they change when the ERP is migrated, and the same physical product carries different numbers in different markets. A passport identifier has to survive all three.

Permanence

The passport is served through the construction digital product passport system, not from your marketing site. That distinction matters more than it first appears: a website gets redesigned, re-platformed and pruned on a marketing cycle, and every URL printed on a product outlives at least one of those.

Article 75(2)(i) puts numbers on it, and they are the most planning-relevant figures in the whole regulation. The system must remain accessible for 25 years after the last product of that product type is placed on the market, and the economic operator must make the passport available for at least 10 years. Those are not website timescales. They are longer than most ERP migrations, most CMS platforms and a good many companies, and they are the reason this is a system obligation with an owner and a budget line rather than a page someone maintains.

There is a useful rehearsal available now, before any of this is mandatory. Under the new CPR the DoPC may already be provided electronically - via a data carrier or a permalink to a website - rather than on paper, provided the document is genuinely reachable at that address. A manufacturer who cannot yet run a permalink that still resolves in three years is not ready for a passport, and that is a cheap thing to discover now.

The four things almost nobody has yet

Across readiness assessments, the same four gaps appear - and none of them is the QR code that everybody asks about first.

1. EN 15804 life-cycle data, per product line. Climate-change indicators become declarable as soon as your family migrates, and the indicator set widens in 2030 and again in 2032. EPD programmes routinely run 6-12 months per product line, and they cannot be parallelised past the capacity of your data and your verifier.
2. An identifier scheme that survives. Not a format decision - a governance decision about who may issue, retire and never reuse an identifier, enforced in the ERP rather than in a policy document.
3. Something that answers for decades. Not a figure of speech: 25 years of system accessibility after the last unit of that type ships, and at least 10 years of availability on you. That is an owner, a budget line and a migration plan - not a CMS and not a folder on a share.
4. Data-delivery clauses with suppliers. Where key parts carry passports of their own, part of your passport depends on data your suppliers make available. That is contract language, and contracts renew slowly.

The QR code, by contrast, is a week of work. It is worth saying plainly because the market currently sells the easy end: a great deal of DPP tooling solves the carrier and the hosting, which is the part you were never going to struggle with.

How the CPR borrows from the ESPR, and why that matters

Most of what is published about "the EU Digital Product Passport" describes the framework created by the Ecodesign for Sustainable Products Regulation - ESPR, Regulation (EU) 2024/1781. Construction products do not sit under it: they get their passport through the CPR's own system. It would be a mistake, though, to conclude that ESPR material is therefore irrelevant to you. The CPR does not reinvent everything, and the places where it borrows are easy to miss.

Identifiers are the clearest case. Article 79(1) of the CPR reaches across to Article 12 of the ESPR, which in turn points at ESPR Annex III - and that is where the identifier rules, including conformity to the ISO/IEC 15459 series, actually live. So an ESPR-sourced identifier requirement may well apply to a construction product, arriving by reference rather than by being written into the CPR. It is also subject to construction-specific alternatives, which the CPR can set.

Backup is the other case, and it resolves differently. The CPR contemplates a backup explicitly, so the question is not whether - but the detailed, construction-specific mechanism is left to the Article 75 delegated act, which has not been adopted. Anyone who tells you today exactly how backup will work for a construction passport is describing either the ESPR arrangement or a guess.

The practical rule is therefore neither "ESPR does not apply to us" nor "the ESPR checklist is our checklist". It is to follow the chain of references before you build to a requirement: which CPR article puts it on you, whether it arrives via the ESPR, and whether the construction-specific detail exists yet or is waiting on the delegated act. A structural-steel manufacturer may genuinely feel both regimes directly; everyone else feels the ESPR through the CPR's references to it.

When this becomes real, and what to do this quarter

Two clocks run, and confusing them is the most common planning error we see.

The first is the system clock. The construction DPP system is established by a delegated act, and the manufacturer's obligation to make a passport available through it applies 18 months after that act enters into force. The Commission currently indicates Q2 2027 for adoption of the construction DPP delegated act; if that timetable holds and the act enters into force shortly afterwards, the obligation would therefore arise around late 2028. This is an extrapolation from an indicative Commission milestone, not a fixed compliance deadline. The binding date will depend on when the delegated act actually enters into force.

The second is the family clock: which product families migrate to the new harmonised technical specifications, and when. That order is set by the CPR Working Plan, and we read it family by family in which construction products need a DPP first. Your own date is the later-arriving of the two, but your preparation is governed by the earlier one - because the data work below does not start when the obligation lands.

What that means for the next ninety days:

1. Inventory against the seven elements above, product family by product family. The output is one honest yes/no/partial per cell - not a plan yet, just the truth about what exists.
2. Pick one product line and take it end to end. A single line carried from declaration to structured data, identifier to carrier, teaches more than a portfolio-wide audit and costs a fraction of it.
3. Start the life-cycle data now, whatever your family's position in the Working Plan. It is the only item on the list whose duration you cannot buy your way out of.
4. Decide who owns the identifier. One named person, with authority over the ERP article-number rules. This decision is free today and expensive in two years.
5. Put a data clause in the next supplier contract you renew. Not a renegotiation programme - just stop signing contracts that make the problem worse.

This piece states the position as at 28 August 2026. The construction DPP delegated act had not been adopted at that date. When it is, the content list above gains operational detail that only the act can supply - and the queue this article belongs to is written on the assumption that it will need revisiting then.

FAQ