Construction Products Digital Product Passport Requirements

Current regulatory status

Which products are covered?

The CPR defines a construction product and sets out the broader products falling within its scope in Article 2.¹ Scope questions can be technically important, so a company should check the legal category applying to its product rather than rely on a generic label such as "building material".

The DPP chapter applies to products under the Regulation, subject to its provisions and exemptions.

Article 76(4) also states that products for which the exemption in Article 14 applies are exempt from the obligation to provide a DPP.¹

For readiness, the useful starting point is therefore:

1. confirm whether the product falls within the CPR
2. identify the applicable product family/category and technical specification
3. determine the product type
4. connect the documents and identifiers that belong to that type.

Do not force a construction-product catalogue into battery-style individual-asset logic.

The legal concept of product type

Construction provides one of the clearest examples of why DPP granularity cannot be described universally as "item level".

Article 3(27) defines product type as:

the abstract model of individual products, determined by intended use and a set of characteristics that exclude variation in performance or fulfilment of product requirements, with identical products from different manufacturers belonging to different product types.¹

In plain English, the product type is the regulated model against which performance and conformity are assessed. It is manufacturer-specific and is not simply a marketing SKU.

Article 22 requires the manufacturer to determine the product type and to ensure its products bear a manufacturer-specific unique identification code of the product type, together with a batch or serial number where available.¹

Article 76 then requires the DPP to correspond to the product type and its unique identification code.¹

Article 77 goes further: the DPP must be connected through one or more data carriers to a persistent unique identification code of the product type.¹

That is a materially different architecture from assuming one passport per individual physical item.

What legislation creates the construction DPP system?

The construction DPP system is created through Chapter X of Regulation (EU) 2024/3110.¹

The core provisions are:

• Article 75 — Construction digital product passport system
• Article 76 — Digital product passport
• Article 77 — General requirements for the digital product passport
• Article 78 — Technical design and operation
• Article 79 — Unique identifiers and DPP Registry
• Article 80 — Mandatory use and technical adaptation

These provisions are adopted law.

The implementation dependency is that Article 75(1) instructs the Commission to adopt delegated acts setting up the system.

That distinction should remain visible on the page because it is the difference between the architecture is legally established and the system is already running in its final form.

What the law already establishes

Article 75: what the system must do

Article 75 requires the future construction DPP system to be compatible and interoperable with the DPP established by ESPR while also taking account of construction-specific requirements and interoperability with Building Information Modelling (BIM).¹

The system must address:

• functions needed to create and manage construction DPPs
• which actors can access which information
• which actors can introduce or update information
• detailed update arrangements
• continuity after insolvency, liquidation or cessation of activity
• back-up arrangements
• requirements for DPP service providers
• potentially more detailed or alternative rules for identifiers, data carriers, digital credentials and the DPP Registry
• long-term information availability
• reuse and remanufacturing information needs.¹

This is already a substantial legal architecture.

Persistence is not left entirely open

Article 75 says the system must be accessible for 25 years after the last product corresponding to its product type has been placed on the market, and the economic operator must make the DPP available for at least 10 years, subject to the Regulation's proportionality wording for longer periods.¹

Implementation details still need to be operationalised, but the persistence objective is already far more specific than in many developing product categories.

Article 76: what the passport must include

Article 76(1) says DPP information must be accurate, complete and up to date.¹

Article 76(2) establishes important information classes. A construction DPP must include:

1. the declaration of performance and conformity
2. the associated documentation specified by the Regulation
3. general product information, instructions for use and safety information
4. technical documentation
5. the applicable label
6. unique identifiers
7. documentation required under other Union law applicable to the product
8. data carriers of key parts where those parts have DPPs.¹

The passport must also:

• connect to one or more data carriers
• be electronically accessible through the displayed carrier
• correspond to the product type and its unique identification code
• be accessible free of charge to the relevant actors through the carrier
• support different access levels
• permit specified actors to introduce or update information
• remain accessible for the established period.¹

These are adopted requirements.

The system-setting delegated act is still needed to make the architecture operational and settle the detailed system rules.

Product information and system architecture are different

Even in construction, where the law is unusually detailed, it helps to separate two questions.

Product information already named by the CPR

The CPR names the core documentation and information classes that belong in the DPP.

That is product content.

System architecture already named by the CPR

The CPR also specifies:

• persistent product-type identity
• one or more data carriers
• electronic access
• differentiated access
• open and interoperable formats
• anti-vendor-lock-in requirements
• data persistence
• controlled update rights
• security and privacy
• Registry interaction
• compatibility with ESPR architecture.

That is system architecture.

Keeping these separate makes implementation easier and prevents a data-carrier choice from being mistaken for a product-data requirement.

Declaration of performance and conformity

The declaration of performance and conformity is central to the construction DPP.

Article 76(2)(a)(i) explicitly includes it, together with the relevant information and accompanying documentation.¹

For manufacturers, this creates a strong low-regret preparation task now:

• give each declaration a stable identifier
• link it to the correct product type
• maintain version and validity history
• map the characteristics and declared performance to source evidence
• retain the relationship to harmonised technical specifications or European assessment documents
• separate the declaration from supporting technical evidence while making the relationship machine-readable.

The DPP should not become a document dump. The legal architecture supports a structured relationship between the regulated product type, declarations, technical evidence and the accessible digital record.

General product, use and safety information

Article 76 includes general product information, instructions for use and safety information referred to in Article 22(6).¹

This means the construction DPP is not limited to sustainability data.

A business preparing only environmental-product information would be preparing too narrowly.

The product record should be able to connect:

• intended use
• product description
• instructions
• safety information
• relevant performance information
• conformity documentation
• other legally required documents.

Technical documentation

Technical documentation is explicitly part of the Article 76 passport information architecture.¹

This does not mean every technical document must be public to every user.

Article 75 requires the system to determine actors and access rights while considering intellectual property, commercially sensitive information and safety.¹

Article 78 also requires protection of trade secrets and intellectual property and restricts access and update rights according to the system's access model.¹

The correct implementation principle is therefore:

Make the document governable and addressable first. Decide visibility by legal access level, not by whether a file happens to exist in the passport store.

Identifiers

Construction has a strong adopted identity rule.

Article 22(5) requires the manufacturer to ensure its products bear a manufacturer-specific unique identification code of the product type, with a batch or serial number where available.¹

Article 77 requires the DPP to connect through one or more data carriers to a persistent unique identification code of the product type.¹

Article 79 then imports ESPR Article 12 for unique identifiers and data carriers unless the construction DPP delegated act establishes more detailed or alternative rules.¹³

This does not create a universal GTIN mandate.

The implementation should distinguish:

• product-type unique identification code
• batch number where available
• serial number where available
• internal SKU or catalogue code
• GTIN if used
• declaration code
• Registry identifiers
• identifiers of economic operators and facilities where relevant.

Do not collapse them.

See /knowledge/fields/identifiers and /knowledge/fields/the-three-identifiers.

Data carrier

The CPR establishes that the DPP is connected to one or more data carriers.¹

Article 76 requires electronic access through the displayed data carrier.

Article 77 requires the carrier to connect to the persistent unique identification code of the product type.

Article 79 applies the ESPR Article 12 carrier/identifier framework unless the construction delegated act lays down more detailed or alternative rules.¹³

The law therefore establishes the function and relationship of the carrier.

It does not justify a generic statement that every construction DPP must already use one fixed QR implementation.

The final system-setting act can add detail.

A construction product-data programme should keep the carrier as a resolvable presentation layer over durable identity and information, not as the master record itself.

Access rights: public does not mean everything is open

Article 76 says the passport must be accessible free of charge to economic operators, clients, users and authorities through the data carrier, while also giving different levels of access.¹

Article 75 requires the system to determine which actors can access which information, taking into account:

• intellectual property
• sensitive commercial information
• construction-work safety.¹

Article 78 requires easy free access based on the recipient's respective access rights and protects trade secrets, intellectual property, security and privacy.¹

So two propositions can both be true:

1. the passport is designed for broad electronic accessibility
2. individual data are not necessarily visible to every actor.

The detailed access matrix remains an implementation dependency.

Do not infer it from another DPP regime such as batteries.

See /knowledge/passport/who-sees-what.

Open standards, interoperability and vendor lock-in

Article 77 requires DPP information to be based on open standards and, as appropriate, to be machine-readable, structured, searchable and transferable through an open interoperable data-exchange network without vendor lock-in.¹

Article 78 requires technical, semantic and organisational interoperability with other DPPs.¹

This is already a strong procurement and architecture signal.

A manufacturer choosing a DPP service provider should therefore prepare for:

• exportable identifiers
• exportable metadata
• documented data models
• stable links between the product type and underlying documents
• machine-readable data where required
• the ability to migrate provider without losing the product record
• documented access and update rights.

See /knowledge/passport/what-you-can-take-with-you and /knowledge/passport/when-the-link-dies.

Storage, provider use and continuity

Article 78 says data storage is to follow the construction DPP system established under Article 75.¹

Where authorised operators or DPP service providers store or process the data, Article 78 restricts them from selling, reusing or processing it beyond what is necessary for the service unless specifically agreed with the economic operator placing the product on the market.¹

The Article also requires the passport to remain available through insolvency, liquidation or cessation scenarios and ties this to back-up arrangements under Article 75.¹

This is unusually concrete evidence for a future procurement checklist.

Businesses can already ask providers:

• how data are exported
• how continuity is protected
• what happens if the provider ceases trading
• who can update which fields
• how authenticity, integrity, security and privacy are controlled
• what contractual rights exist to reuse the customer's data.

Those are architecture and governance questions, not guesses about future product fields.

Registry interaction

Article 79 applies ESPR Article 13 to the construction DPP Registry relationship unless the construction delegated act sets more detailed or alternative rules.¹³

The EU DPP Registry became operational on 20 July 2026.⁴

The Commission describes the Registry as an indexing service that stores unique identifiers, registration data and high-level metadata rather than the full detailed product information by default.⁴⁵

The Registry being live does not mean the construction system-setting delegated act has been adopted.

For construction, the key point is:

The CPR already anchors construction DPPs into the wider EU DPP identifier, Registry and portal architecture, while preserving the ability to set construction-specific detailed or alternative rules.

See /knowledge/regulation/where-passport-data-lives and /knowledge/evidence/what-the-registry-records.

BIM interaction

Article 75 explicitly requires the construction DPP system to be compatible and interoperable with the ESPR DPP while not compromising interoperability with Building Information Modelling (BIM).¹

This makes construction structurally different from many consumer-product DPP discussions.

The DPP should be designed as a regulated product-information source that can participate in a wider digital construction information environment.

That does not mean the DPP and a BIM model are the same thing.

A good architecture should preserve:

• product-type identity
• stable machine-readable references
• defined data semantics
• document relationships
• open interchange
• access control.

The future delegated act and technical work will determine the detailed implementation.

When does the system become mandatory?

The Commission currently indicates Q2 2027 for a delegated act for construction materials under the CPR.²

That is an indicative roadmap date.

The legally important timing rule is Article 80.¹

Once the Article 75 delegated act enters into force:

Six months later

The construction DPP system must be fully operational and fulfil its intended objectives, including the Article 76 functions.

Eighteen months later

The obligations established pursuant to Article 22(7) apply.

Interim period

Manufacturers may use the system voluntarily.

This means the page should never convert "Q2 2027" into "construction DPP compliance starts Q2 2027".

The correct public explanation is:

The CPR contains a relative implementation clock tied to the future system-setting delegated act. The Commission currently indicates Q2 2027 for that act, but the exact calendar dates depend on the act's adoption and entry into force.

What manufacturers can prepare now

Construction has more adopted detail than textiles or tyres, so readiness can be more concrete.

PREPARE

1. Establish product-type master data

Use the CPR concept of product type, not just marketing product names. Link each type to its manufacturer-specific unique identification code.

2. Link batch and serial information without making it the DPP level

Retain batch or serial numbers where available and connect them to the product type.

3. Structure declarations of performance and conformity

Give declarations stable identities, versions, dates, scope and product-type relationships.

4. Govern general product, use and safety information

Keep instructions and safety information current and linked to the correct type.

5. Govern technical documentation

Maintain technical evidence and product documentation with access classification rather than treating it as unstructured files.

6. Build a label and identifier crosswalk

Know how the product-type code, declaration code, label, existing commercial identifiers and any future Registry identifiers relate.

7. Build role-based access controls

The law already requires differentiated access. Public versus restricted information should be technically separable.

8. Design for open export and interoperability

Avoid provider lock-in. Preserve machine-readable structured data and documented interfaces.

9. Plan persistence and back-up

The law already contains long-term availability requirements and continuity expectations.

10. Keep the carrier separate from the canonical data

Use one or more carriers as access mechanisms tied to persistent product-type identity.

11. Prepare Registry integration as a distinct system

Keep registration identifiers and states separate from the detailed product-data store.

12. Map BIM-facing information relationships

Do not turn the DPP into BIM, but make the core product-type data semantically reusable.

WATCH

Monitor:

• adoption and entry into force of the Article 75 delegated act
• exact construction DPP system rules
• detailed or alternative identifier rules
• carrier and placement rules
• digital credential requirements
• detailed Registry rules
• service-provider requirements or certification
• actor-by-actor access rights
• update permissions
• final technical schemas and semantics
• guidance on interoperability with BIM
• transition dates calculated from the adopted act.

DO NOT HARD-CODE YET

Do not make the implementation dependent on:

• Q2 2027 being the compliance date
• one specific QR format being the only lawful carrier
• GTIN being universally required
• one commercial provider's proprietary product ID
• a universal public-access model
• a battery-style item-level passport
• final service-provider certification details that have not yet been adopted
• final Registry metadata beyond what current horizontal rules establish
• one proprietary BIM integration format
• one storage topology that cannot adapt to the Article 75 system act.

What remains too uncertain to hard-code?

Construction has an adopted content and architecture skeleton, but several operational details remain open.

The main dependencies include:

1. the precise system-setting delegated act
2. detailed actor and access matrices
3. final update permissions and workflows
4. service-provider requirements and any certification
5. detailed or alternative identifier lifecycle rules
6. data-carrier details
7. digital credential requirements
8. detailed Registry interaction
9. exact technical and semantic implementation
10. BIM interoperability detail
11. operational back-up arrangements
12. exact calendar application dates once the delegated act enters into force.

The implementation strategy should therefore be concrete on adopted requirements and configurable on pending implementation detail.

Direct construction questions

Does EU construction law establish a DPP system?

Yes. Regulation (EU) 2024/3110 establishes the construction DPP system framework in Articles 75-80.

Is it operational today?

Not as the complete mandatory construction DPP system. The Commission must still adopt the Article 75 delegated act setting up the system.

What legislation creates it?

Regulation (EU) 2024/3110 on construction products.

What does the law already establish?

It establishes the system functions, core passport information classes, product-type identity, one-or-more carrier architecture, access differentiation, open/interoperable data requirements, continuity, security, Registry interaction and the post-delegated-act timing mechanism.

What still needs Commission implementation?

The Article 75 delegated act must set up the system and specify detailed actor, access, update, provider, identifier/carrier, Registry and technical arrangements.

What is a product type?

The CPR defines it as the abstract model of individual products determined by intended use and characteristics that do not vary in performance or fulfilment of product requirements, and it is manufacturer-specific.

What information architecture is expected?

At minimum, the CPR names the declaration of performance and conformity, general/use/safety information, technical documentation, label, unique identifiers, other applicable Union-law documentation and carriers for key parts with DPPs.

How are identifiers handled?

The DPP connects to a persistent unique identification code of the product type. ESPR identifier rules apply unless the construction delegated act sets more detailed or alternative rules.

How does the data carrier work?

The DPP connects to one or more carriers and is electronically accessible through the displayed carrier. Final implementation details remain subject to the system act.

Is all construction DPP information public?

No universal all-public rule should be inferred. The CPR requires different access levels and protection of sensitive information while providing free access according to the recipient's rights.

How does it connect to declarations and conformity?

The declaration of performance and conformity and associated documentation are expressly part of the passport information architecture.

What should manufacturers prepare now?

Product-type identity, declarations, technical documents, product/use/safety data, identifier relationships, access control, open export, persistence and Registry-ready system separation.

What remains too uncertain to hard-code?

The exact system act, detailed access matrix, provider rules, final carrier details, credentials, Registry alternatives and exact calendar application dates.

How we know

Construction requires a different evidence vocabulary from developing ESPR categories.

Here the page distinguishes:

ADOPTED FRAMEWORK

Requirements already written into Regulation (EU) 2024/3110.

IMPLEMENTATION PENDING

Details that the Article 75 delegated act and subsequent technical work must operationalise.

NOT ESTABLISHED

Points the current legal evidence does not settle.

This prevents two opposite errors: treating the construction DPP as speculative, or treating every operational detail as already final.

Primary sources

• Regulation (EU) 2024/3110 laying down harmonised rules for the marketing of construction products, especially Article 3(27), Article 22 and Articles 75-80.

  View official source

• European Commission — Digital Product Passport implementation timeline. Current indicative Q2 2027 construction-materials delegated-act milestone.

  View official source

• Regulation (EU) 2024/1781 — Ecodesign for Sustainable Products Regulation (ESPR), particularly Articles 12-14 referenced by CPR Article 79.

  View official source

• European Commission — The Digital Product Passport Registry is now live, 20 July 2026.

  View official source

• European Commission — The DPP Registry. Registry role, identifiers, registration data and high-level metadata.

  View official source

• European Commission — New EU rules on the safety and sustainability of construction products, 7 January 2025. Official implementation context for Regulation (EU) 2024/3110.

  View official source

This is a regulatory information resource, not personalised legal advice. CPR product scope, technical specifications, transitional rules and obligations should be checked for the specific product and economic operator.